Pull to refresh

Comments 13

Тут в соседнем посте habr.com/ru/post/486500 justboris как раз о подобных штуках и говорит. Я склонен поддерживать его точку зрения и поэтому предлагаю переименовать ссылку «Черновик спецификации» в «Черновик идеи»

Надо отдать должное, в этот раз к черновику добавили ватермарки "unofficial draft", чтобы лучше это подчеркнуть.


Но зачем они добавляют свои "идеи" в стандартный объект navigator – непонятно. Завели бы отдельный window.chrome и делали бы там что хотели.

Ну или пошли бы стандартным проторенным путём с флагами в chrome://flags

С флагами фичу на живых пользователях сложно проверить, обычные пользователи ни в какие флаги не полезут.


Поэтому желание внедрить фичу без флагов как раз понять можно.

С флагами фичу на живых пользователях сложно проверить, обычные пользователи ни в какие флаги не полезут.

В том то и дело, что идут стандартным проторенным путём с флагами в chrome://flags и тестированию на обычных пользователях это так же особо не мешает т.к. для этого и сделали Origin Trials. По сути Origin Trials это токен, который включает необходимый флаг на конкретном сайте.


Для примера YouTube ещё в процессе перехода на Custom Elements v1 и как минимум с середины 2019 года у них на страницах имеется Origin Trials токен на Custom Elements v0, которые в свою очередь в флагах по умолчанию выключены.


Но зачем они добавляют свои "идеи" в стандартный объект navigator – непонятно.

По сути они заранее пишут свою идею как кандидат в стандарты, сразу завязанный на имеющихся стабильных API иначе пришлось бы после Proof of Concept реализации в движке и принятия спецификации как стандарта переписывать эту самую реализацию Proof of Concept.


Т.е. в данном случае они по мимо спецификации (сухого описания как и что) предоставляют ещё Proof of Concept реализацию для возможности сбора фидбека в процессе стандартизации. По итогу конечный вариант Proof of Concept реализации становится эталонной реализацией.

Спасибо за наводку, не знал про Origin Trials.

И, в итоге, мы получаем очередные "вендорные префиксы", от которых, в конце концов, отказались.
И снова возвращаемся во время "браузер А запилил фичу 123, а остальные XYZ браузеры ушли лесом", а при стандартизации и, вероятно, переимплементации этой фичи придется поддерживать несколько ее версий.
Но да, в роли браузера А теперь не ИЕ, а хром.

Переименовал в «черновик предложения», «идея», мне кажется, это что-то абстрактное, а тут есть реализация в браузере. Спасибо за уточнение! Я не специально :)

Не понял почему отсутствие явного пермишена это хорошо

Сайт ничего не может сделать с контактами без явного разрешения пользователя, даже если пользователь ранее уже предоставлял доступ к какому-либо контакту. Каждый раз, когда сайт будет просить что-то ему предоставить из контактов пользователя, по сути, это и будет явный пермишн: «Сайт n получил доступ к выбранным контактам», выбери и нажми «Готово». Ещё один промежуточный пермишн (как у остальных API) тут будет лишним, плюсом, он ни от чего не обезопасит: тут нет никакого «сохранения последующего доступа» к контактам.


Ну а хорошо это потому что пользователю нужно меньше тыкать, а разработчику меньше обрабатывать :) основной посыл этого комментария в том что в данном случае ничего плохого в этом нет.

Не понятно зачем нужно было менять воркфлоу запроса прав для конкректно этого апи.

Этот API даже не учитывается в списке прав (соответственно ни как не относится к воркфлоу запроса прав). Как выше указали данный API использует по сути внешний интерфейс (на уровне браузера).


В данном случае нет необходимости в запросе постоянных прав (до отмены через интерфейс браузера) на доступ к API т.к. воркфлоу API уже подразумевает единоразовую выдачу права (каждый вызов является единоразовым запросом) пользователем через взаимодействие с интерфейсом браузера (подтверждение выбора = право предоставлено, отмена действия = право не предаставлено).


К слову это не единственный API с подобной реализацией (единоразовый доступ):


  • Contact Picker API (доступ к контактам — пользователь сам выбирает каким)
  • File API (доступ к содержимому файлов — пользователь сам выбирает каким, одно из первых API с подобным воркфлоу)
  • Native File System API (доступ на изменение файлов/директорий — пользователь сам выбирает каких)
  • Web Authentication API (доступ к ключу — опять таки пользователь выбирает к какому)
  • Payment Request API (доступ к платёжной информации в т.ч. Google/Apple/Samsung/etc. Pay — аналогично)
  • Web Share API (вызов/доступ к внешним приложениям — снова пользователь выбирает)

В этот же список можем добавить ещё:


  • Install Banner API (запрос на добавление PWA, отличается от выше перечисленных автоматическим вызовом)
  • User Activation API (как пример влияет на воспроизведение аудио/видео на мобильных — только после взаимодействия пользователя со страницей)

В данных случаях запрашивать постоянное разрешение не целесообразно (усложнаем жизнь пользователю) т.к. каждый вызов будет единоразовым запросом.


Единственное все эти API со временем можно интегрировать с User Activation API в случае злоупотребления ими как со всплывающими окнами. Т.е. если во временном окне вызова API пользователь не взаимодействовал со страницей (клик), автоматически отказывать в доступе.


Есть ещё API с альтернативной выдачей разрешения:


  • SMS Receiver API (доступ к содержимому следующего входящего SMS — вызов = запросу, разрешение = содержимое SMS содержит ссылку на страницу, запрет не предусмотрен = бесконечный Promise пока не придёт SMS подходящее под критерий разрешения. Я видел вариант с дополнительным запросом разрешения по типу как у Install Banner API)

По поводу User Activation API к сожалению пока это API только Chromium-based браузеров и доступен как navigator.userActivation, однако технически в других реализациях (только internal use only) имеется в Safari и Firefox для тех же изначально нужд по авто воспроизведению медиа контента.

UPD: Внезапно, данное API без объявления войны было имплементировано за флагом в iOS 14.5 beta 2 и уже находится во вполне работоспособном состоянии. Когда фича будет доступна всем пользователям спрогнозировать сложно, остаётся только ждать.

Only those users with full accounts are able to leave comments. Log in, please.