Комментарии 13
Надо отдать должное, в этот раз к черновику добавили ватермарки "unofficial draft", чтобы лучше это подчеркнуть.
Но зачем они добавляют свои "идеи" в стандартный объект navigator – непонятно. Завели бы отдельный window.chrome и делали бы там что хотели.
С флагами фичу на живых пользователях сложно проверить, обычные пользователи ни в какие флаги не полезут.
Поэтому желание внедрить фичу без флагов как раз понять можно.
С флагами фичу на живых пользователях сложно проверить, обычные пользователи ни в какие флаги не полезут.
В том то и дело, что идут стандартным проторенным путём с флагами в 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 реализации становится эталонной реализацией.
И, в итоге, мы получаем очередные "вендорные префиксы", от которых, в конце концов, отказались.
И снова возвращаемся во время "браузер А запилил фичу 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 и уже находится во вполне работоспособном состоянии. Когда фича будет доступна всем пользователям спрогнозировать сложно, остаётся только ждать.
Contact Picker API, или как поделиться своими контактами с браузером