RE: Question about HTML Media Capture specification

> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
>
> Le mardi 05 juillet 2011 à 12:58 +0200, Jimenez, Ernesto, VF-Group a écrit :
> > Maybe we should review what the use cases are. Given the current
> > options, it seems the different capture options don't provide any new
> > besides whether you want fresh or saved content.
> 
> I think characterizing this as "nothing new but fresh vs saved" is missing the
> key part of this: the point is that for the user, using a file picker or a camera
> are two very different operations, and it's likely that the developer would
> like to be able to influence which operation will be presented to the user;
> see a related discussion in
> public-html:
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0519.html

> 

Sorry, my wording probably wasn't the appropriate. What I mean is that the capture attribute right now is only useful to specify if you want the default UI to be in capture (camera, camcorder or microphone) or filesystem.

The options right now seem to be:
<input type="file" accept="image/*" capture="camera">
<input type="file" accept="video/*" capture="camcorder">
<input type="file" accept="audio/*" capture="microphone">
<input type="file" accept="[anything]" capture="filesystem">

The question I'm asking myself is: what is the benefit of having a capture attribute with four options versus having a single attribute with two options?
(Example with placeholder text, I'm not suggesting these are the best names for the attribute and the options)
<input type="file" accept="[anything]" source="capture">
<input type="file" accept="[anything]" source="filesystem">

This solution covers the same use cases as what is currently specified and doesn't have issues with conflicting attributes like <input type="file" accept="audio/*" capture="camera">. 

That's why I was asking the use cases that justify the different capture attributes depending on the accept attribute :)

> That's what the Android implementation does, but as you note, that's not
> what the specification states. The end goal would be to align with the
> specification if doable, or to revisit it if not.
> 

Agreed

> > As an example, if we want the capture element to be a hint on the
> > *preferred* source, I would specify that UA's might use the capture
> > attribute to select a source by default and they must allow the user
> > to select another source.
> 
> That's what the current spec says, as far as I can tell.
> 

In my opinion the spec implies that, but it doesn't explicitly state it.

My point is that, as a developer, consistency in this area is very important to me and I would like the spec to clearly state that UA's must provide the user with the choice to select an existing file even when I have stated that I want the camera UI.

Then the implementer can choose how to design the UX to provide that option. E.g.: iOS usually shows a dialog with the buttons 'Take a Photo'/'Choose existing'/'Cancel', another browser might show a more complex button like the ones Josh was talking about earlier in this thread, another might enter in the camera UI and have a button in the UI to open the gallery, etc.

Best, 
Ernesto

Received on Tuesday, 5 July 2011 14:46:02 UTC