RE: [html-media-capture] ACTION-432: Make a proposal for ISSUE-116 and ISSUE-117

> -----Original Message-----
> From: Jimenez, Ernesto, VF-Group
> Sent: 17 August 2011 12:04
> To: public-device-apis@w3.org
> Subject: [html-media-capture] ACTION-432: Make a proposal for
ISSUE-116
> and ISSUE-117
> 
> Hello,
> 
> Here is my input for ACTION-432: Make a proposal for ISSUE-116 and
ISSUE-
> 117
> 
> ISSUE-116: HTML Media Capture doesn't make sense if accept=image and
> capture=microphone
> ISSUE-117: Should HTML Media Capture have options for front/user
camera
> as in getUserMedia

Kind post-summer reminder, does anybody have feedback on this? :)

> 
> First of all, some context.
> 
> This proposal relates to the HTML Media Captures spec. This spec
outlines
> how to enhance the <input type=file> element to capture data from the
> camera or microphone rather than a regular file.
> 
> The current solution involves 2 attributes for <input type=file>:
>   - accept: Set to [image|video|audio]/* to specify what kind of
content you
> want to capture.
>   - capture: An _optional_ attribute that _hints_ the User Agent which
UI the
> developer would like to be presented to the user: camera, video
camera,
> microphone or filesystem.
> 
> This solution with the capture attribute presents some issues:
>   - The capture attribute can contradict the accept attribute. E.g.:
<input
> type="file" accept="image/*" capture="microphone">
>   - It doesn't cover the use cases where the developer would like to
hint the
> browser about which camera to use by default. It's usual in some
devices
> having two cameras, one facing to the user and another facing to the
> environment, and an app developer could be interested in hinting the
UA
> which camera to use. E.g.: an app for food reviews could hint the UA
to use
> the environment camera in the review form and the user-facing camera
in
> the form asking for the user's profile picture.
> 
> My current proposal is covers the following use cases:
> # Food reviews web app
> Alice is developing a mobile web app for food reviews has two forms
with
> input type=file, the review form where the user is invited to upload a
picture
> from the food and a profile form where the user can upload his profile
> picture.
> 
> Rather than having the user quitting the web app to take the pictures
and
> then get back to select them, Alice would like to use HTML Media
Capture to
> allow the user to take the pictures from within the app and hint the
UA that
> by default it should show the "capture picture" UI with the
environment
> camera for the food review form and the user-facing camera for the
profile
> picture.
> 
> Bob is one of Alice new users and is filling his profile. When he
clicks on the
> button to select a profile picture and is prompted by default with the
> "capture picture" UI by the UA. However, he already has his usual
avatar in
> his phone so he decides to use the filesystem UI to upload his usual
avatar
> instead of taking a new picture.
> 
> After the success of her mobile web app Alice decided use some CSS
media
> queries to adapt the web app to desktop browsers. When working on the
> new mobile & desktop version of her web app, she realizes that most
> computers don't have an environment camera, just a user-facing one.
Rather
> than having the UA showing the "capture image" UI with the user-facing
> camera when no environment camera is available, she hints the UA to
use
> the filesystem as her second option.
> 
> Requirements:
>   - Developers should be able to specify which is their preferred
input UI (file
> picker UI or capture UI) and capture source (user or environment)
>   - Developers should be able to specify what are their preferred
fall-backs
>   - Users should be able to override developer's preference and have
control
> on what to upload
>   - Developers should be able to rely on a consistent implementation
of the
> features across different compliant implementations.
>   - User agents should have control over the UX to allow the user to
control
> which file to input
> 
> Initial proposal (to be discussed, polished and edited):
> 
> The capture attribute may be added to the input element to provide
user
> agents with a hint of that by the default a file picker should be in
media
> capturing mode.
> 
> When the capture attribute is present, user agents:
>   - MUST ignore the attribute if the accept attribute is not present
>   - MUST ignore the attribute if the accept attribute is not image/*,
video/* or
> audio/*
>   - MAY use the capture attribute to decide which UI to present to the
user
>   - when user agents use the capture attribute, user agents MUST allow
the
> user to use another input UI or source
> 
> The capture attribute is an ordered set of unique comma-separated
tokens
> that can take one of the following values: user, environment,
filesystem
> (ASCII case-insensitive).
> 
> The different UIs a user agent might implement are:
>   - camera UI using a user-facing camera
>   - camera UI using a camera facing the environment
>   - camcorder UI using a user-facing camera
>   - camcorder UI using a camera facing the environment
>   - audio recording UI using a microphone for the user
>   - audio recording UI using a microphone for the environment
>   - file picker UI
> 
> The UA should use the capture attribute following these steps:
>   1. Let _accept_ be the value of the accept attribute
>   2. Let _tokens_ be the ordered set of tokens in the capture
attribute
>   3. Let _position_ point to the first token in the set
>   4. Let _token_ be the token in _tokens_ with position _position_
>   5. If _accept_ is "image/*", _token_ is "user" and the UA implements
a
> camera UI using a user-facing camera: show that browser UI and stop
the
> algorithm
>   6. If _accept_ is "image/*", _token_ is "environment" and the UA
> implements a camera UI using a camera facing the environment: show
that
> browser UI and stop the algorithm
>   7. If _accept_ is "video/*", _token_ is "user" and the UA implements
a
> camcorder UI using a user-facing camera: show that browser UI and stop
the
> algorithm
>   8. If _accept_ is "video/*", _token_ is "environment" and the UA
> implements a camcorder UI using a camera facing the environment: show
> that browser UI and stop the algorithm
>   9. If _accept_ is "audio/*", _token_ is "user" and the UA implements
an
> audio recording UI using a microphone for the user: show that browser
UI
> and stop the algorithm
>   10. If _accept_ is "audio/*", _token_ is "environment" and the UA
> implements an audio recording UI using a microphone for the
environment:
> show that browser UI and stop the algorithm
>   11. If _token_ is "filesystem" and the UA implements a file picker
UI: show
> that browser UI and stop the algorithm
>   12. If _position_ is not pointing to the last token, increment
position and go
> to step 4
>   13. Otherwise, show the user agent's default UI for input
type="file"
> 
> I think this solution addresses the requirements I described. One
small
> concern I have is that the name of the capture attribute sounds to me
quite
> imperative. '<input type="file" accept="image/*" capture="user">'
sounds
> to me like the capture is a requirement, not a hint.
> 
> Let me know what you think about the solution.
> 
> Best,
> Ernesto

Received on Wednesday, 14 September 2011 14:59:33 UTC