Этот документ является неофициальным переводом исходной английской версии HTML Media Capture. Обратите внимание на то, что оригинальная версия документа существует только на английском языке. Данный перевод может содержать неточности и ошибки. Перевод выполнил Кирилл Топольян, 2018.

HTML Media Capture

Рекомендация W3C от

Эта версия:
https://www.w3.org/TR/2018/REC-html-media-capture-20180201/
Последняя опубликованная версия:
https://www.w3.org/TR/html-media-capture/
Последний редакторский черновик:
https://w3c.github.io/html-media-capture/
Набор тестов:
https://w3c-test.org/html-media-capture/
Отчет о реализации:
https://www.w3.org/2009/dap/wiki/ImplementationStatus
Предыдущая версия:
https://www.w3.org/TR/2017/PR-html-media-capture-20171128/
Редакторы:
Anssi Kostiainen, Intel
Ilkka Oksanen, Nokia (до 10 мая, 2012)
Dominique Hazaël-Massieux, W3C (до 10 мая, 2012)
Участие:
public-device-apis@w3.org
GitHub w3c/html-media-capture
GitHub w3c/html-media-capture/issues
GitHub w3c/html-media-capture/commits

Пожалуйста, проверьте страницу исправлений, чтобы узнать о любых ошибках или проблемах, о которых сообщили после публикации.

Также смотрите переводы (база данных переводов больше не пополняется — прим. переводчика).


Аннотация

Спецификация HTML Media Capture определяет расширение HTML, которое облегчает доступ пользователя к механизму захвата медиа, такому как камера или микрофон, изнутри элемента управления загрузкой файлов.

Статус Документа

Данный раздел описывает статус этого документа на момент публикации. Другие документы могут заменять этот документ. Список текущих публикаций W3C и последнюю ревизию его технического отчета можно найти в индексе технических отчетов W3C по адресу https://www.w3.org/TR/.

Предлагаемая Рекомендация HTML Media Capture была опубликована 28 ноября 2017, с того момента не было сделано никаких нормативных изменений. Опечатки для данного документа записываются в качестве вопросов. Отчет о реализации, выпущенный для этой версии, демонстрирует наличие двух независимых совместимых реализаций.

Этот документ был опубликован Рабочей Группой Девайсов и Сенсоров в качестве Рекомендации. Комментарии по поводу документа приветствуются. Пожалуйста, отправляйте их на public-device-apis@w3.org (подписка, архивы) или откройте вопрос на GitHub.

Пожалуйста, посмотрите отчет о реализации Рабочей Группы.

Этот документ был рассмотрен Участниками W3C, разработчиками программного обеспечения, другими группами W3C и заинтересованными сторонами, и одобрен Директором в качестве Рекомендации W3C. Это стабильный документ, и он может использоваться в качестве справочного материала или цитироваться другими документами. Роль W3C в создании Рекомендации заключается в привлечении внимания к спецификации и содействии ее широкомасштабному развертыванию. Это повышает функциональность и совместимость Сети.

Этот документ был подготовлен группой, действующей в соответствии с Патентной политикой W3C. W3C поддерживает публичный список раскрытий патентов, сделанных в связи с результатами работы группы; эта страница также содержит инструкции по раскрытию патента. Лицо, имеющее фактическое знание патента, которое, по мнению физического лица, содержит существенные требования (претензии), должно раскрывать информацию в соответствии с разделом 6 патентной политики W3C.

Данный документ регулируется Документом процесса W3C от 1 марта 2017.

1. Введение

Данный раздел не является нормативным.

Спецификация HTML Media Capture расширяет интерфейс HTMLInputElement атрибутом capture. Атрибут capture позволяет авторам декларативно запросить использование механизма захвата медиа, такого как камера или микрофон, изнутри элемента управления загрузкой файлов, для захвата носителя на месте.

Это расширение специально разработано простым и декларативным, и охватывает подмножество функций захвата медиа-данных веб-платформы. В частности, расширение не обеспечивает подробный авторский контроль над захватом. Случаи, требующие более точного контроля авторов, могут быть достигнуты с использованием другой спецификации, Media Capture and Streams [MEDIACAPTURE-STREAMS]. К примеру, доступ к медиа-потокам в реальном времени с хост-устройства выходит за рамки этой спецификации.

2. Соответствие

Как и разделы, обозначенные как ненормативные, все рекомендации авторам, диаграммы, примеры и примечания в этом описании являются ненормативными. Всё остальное в этой спецификации является нормативным.

Ключевые слова MUST, MUST NOT и SHOULD следует интерпретировать, как описано в [RFC2119].

Эта спецификация определяет критерии соответствия, которые применяются к одному продукту: агенту пользователя, который реализует интерфейсы, которые она содержит.

Реализации, которые используют ECMAScript для реализации API, определенных в этой спецификации, должны реализовывать их в соответствии с ECMAScript Bindings, определенными в спецификации Web IDL [WEBIDL-1], так как данная спецификация использует эту спецификацию и терминологию.

3. Терминология

Элемент input, его атрибут type, интерфейс HTMLInputElement, атрибут accept, состояние Загрузки Файла, перечислимый атрибут, отсутствующее значение по умолчанию, недопустимое значение по умолчанию и reflect определены в [HTML51].

Расширенный атрибут [CEReactions] WebIDL определен в [custom-elements].

Перечисление VideoFacingModeEnum определено в [MEDIACAPTURE-STREAMS].

Интерфейс FileList определен в [FILE-API].

В данной спецификации, термин тип управления захватом относится к специализированному типу управления средством выбора файлов, который оптимизирован для пользователя для непосредственного захвата носителя типа MIME, указанного в атрибуте accept, использующем механизм захвата медиа в своем предпочтительном режиме просмотра.

Термин механизм захвата медиа относится к локальному устройству захвата данных устройства, например, к камере или микрофону.

Предпочтительный режим просмотра — это подсказка для направления используемого механизма захвата данных устройства.

4. Вопросы безопасности и конфиденциальности

Данный раздел не является нормативным

Реализациям пользовательского агента рекомендуется спрашивать разрешения пользователя перед началом захвата контента с помощью микрофона или камеры. Это может быть обязательным для соответствия нормативным, юридическим и передовым требованиям, связанным с приватностью данных пользователя. К тому же, реализации пользовательского агента советуется предоставлять пользователю индикатор, когда устройство ввода включено, и давать возможность пользователю на прекращение такого захвата. Схожим образом, пользовательским агентам рекомендуется предлагать элементы контроля, например, чтобы позволить пользователю следующее:

Данная спецификация опирается на безопасность и защиту персональных данных, предоставленные спецификациями <input type="file"> [HTML51] и [FILE-API]; в частности, ожидается, что любое предложение начать захватывать контент пользовательским устройством потребует конкретного взаимодействия пользователя с HTML-элементом, который полностью контролируется агентом пользователя.

Разработчики должны позаботиться о том, чтобы предотвратить утечку конфиденциальных данных с записанных медиа. К примеру, вложение местоположения пользователя в метаданные записанных медиа (например, EXIF) может передавать больше личных данных, чем ожидает пользователь.

5. Атрибут capture

Когда атрибут type элемента input находится в состоянии File Upload, и его атрибут accept указан, могут применяться правила из данного раздела.

partial interface HTMLInputElement {
    [CEReactions]
    attribute DOMString capture;
};

Атрибут capture является перечислимым атрибутом, чье состояние определяет предпочтительный режим просмотра для механизма захвата медиа.

Ключевыми словами атрибута являются user и environment, которые сопоставляются с соответствующими состояниями user и environment. Семантика состояний user и environment отражает названные схожим образом перечислимые значения, определенные в VideoFacingModeEnum.

К тому же, есть третье состояние, состояние implementation-specific.

Отсутствующее значение по умолчанию является implementation-specific состоянием. Некорректное значение по умолчанию также является implementation-specific состоянием.

Заметка

Если пользовательский агент не может поддерживать предпочтительный режим просмотра, он может вернуться к режиму просмотра по умолчанию для данной реализации, что соответствует implementation-specific состоянию, которое указывает, что реализация должна действовать в соответствии со своим поведением по умолчанию.

IDL атрибут capture должен (MUST) отражать соответствующий атрибут контента с тем же именем.

Когда атрибут capture указан, пользовательский агент должен (SHOULD) вызвать средство выбора файла определенного типа управления захватом.

Когда атрибут capture указан, пользовательский агент не должен (MUST NOT) сохранять захваченные медиа в какое-либо хранилище, локальное или удаленное.

Заметка
Когда скрипты получают доступ к файлам, выбранным из средства выбора файлов (представленным объектом FileList), они могут использовать различные механизмы для хранения захваченных медиа. Эти механизмы не входят в рамки данной спецификации.

Если значение атрибута accept установлено к типу MIME, у которого нет ассоциированного типа управления захватом, пользовательский агент должен (MUST) действовать так, как если бы не было атрибута capture.

A. Примеры

Данный раздел не является нормативным.

Следующие примеры демонстрируют, как давать подсказки, что пользователю предпочтительно захватывать медиа определенного типа MIME с использованием возможностей захвата медиа-данных устройства. Представлены как простой декларативный пример с использованием HTML-формы, так и более продвинутый пример, включающий скрипты.

Когда атрибут accept элемента input установлен к image/* и атрибут capture указан как в Примере 1 или Примере 4, средство выбора файла можно отобразить, как показано ниже:

A File picker control in the Image Capture state.

Когда атрибут не указан, средство выбора файлов можно отобразить, как показано ниже:

A File picker control in the File Upload state.

B. Ссылки

B.1 Нормативные ссылки

[custom-elements]
Custom Elements. Domenic Denicola. W3C. 13 октября 2016. Рабочий проект W3C. URL: https://www.w3.org/TR/custom-elements/
[HTML51]
HTML 5.1 2nd Edition. Steve Faulkner; Arron Eicholz; Travis Leithead; Alex Danilo. W3C. 3 октября 2017. Рекомендация W3C. URL: https://www.w3.org/TR/html51/
[MEDIACAPTURE-STREAMS]
Media Capture and Streams. Daniel Burnett; Adam Bergkvist; Cullen Jennings; Anant Narayanan; Bernard Aboba. W3C. 3 октября 2017. Предлагаемая Рекомендация W3C. URL: https://www.w3.org/TR/mediacapture-streams/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. Март 1997. Лучшая современная практика. URL: https://tools.ietf.org/html/rfc2119
[WEBIDL-1]
WebIDL Level 1. Cameron McCormack. W3C. 15 декабря 2016. Рекомендация W3C. URL: https://www.w3.org/TR/2016/REC-WebIDL-1-20161215/

B.2 Информационные ссылки

[FILE-API]
File API. Marijn Kruisselbrink. W3C. 26 октября 2017. Рабочий проект W3C. URL: https://www.w3.org/TR/FileAPI/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Живой Стандарт. URL: https://html.spec.whatwg.org/multipage/
[WEBIDL]
Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 декабря 2016. Редакторский черновик W3C. URL: https://heycam.github.io/webidl/