Re: Media Capture

Hi

I have a number of questions/points, some for you, and some to refresh my memory of HTML points.

1) The acceptability of parameters to MIME types belongs, as I understand, with the MIME type owners and not with the W3C.  Though, as you say, the HTML spec. disallows parameters here, so any apparent pseudo-parameters cannot be ones belonging to the MIME type, but only ones from the W3C specs, I am concerned that *if* a MIME type had a parameter "capture", the number of people who would understand accept="image/somethingstrange;capture=whatever" as using the W3C's capture parameter, and not the one that belongs to somethingstrange, as very small.

2) I am puzzled *why* the HTML spec disallows parameters.  Saying accept="video/mp4;codecs=\"mp4a,mp4v,h263,samr\"" would seem useful to me (an indication of what codecs are acceptable).

3) Is it not a hint to the UA that the user is expected to be able to take a picture to satisfy this input, and that without it, the user is expected to find a file?  That is, wouldn't a UA be allowed in either case to offer the other ("please select a file, or click here to take a new picture", or "please click the shutter button, or click here to choose a pre-existing file").

To me, the capture attribute would be a better hint that new capture is more expected than choosing a file (and its absence a hint that choosing a file is more expected that new capture).  Perhaps.


On Dec 8, 2010, at 8:56 , Robin Berjon wrote:

> Dearest of HTML WGs,
> 
> a few months back there was a discussion on this list about the value of having some form of a capture parameter to input type file that would hint to the user agent that audio/video/still capture is what's intended so that it could present a more direct and straightforward UI. After some discussion, agreement was reached that such a hint was indeed useful.
> 
> Since then, the DAP WG has been editing a simple draft[1] matching the discussion, as planned. There is, however, some hesitation on one crucial, if somewhat bikeshed-shaped, point: syntax. Furthermore, irrespective of the solution, coordination with the HTML WG is required since we're essentially spawning an army of bug-eyed blood-thirsty deranged mutant killer monster goons that will pillage your Unicode repertoire until you're left with but an angle bracket to cry on to the tune of Lady Gaga karaoke. Oh wait. That came out wrong. I meant: since we're either slightly touching the syntax of the input element's accept attribute values, or alternatively adding an attribute.
> 
> The choice is this:
> 
> Option 1)
> This is the option that's in the draft, as well as the one that's implemented in Android. Each media type (or pseudo-media type) in the accept list can take a ;capture={camera,microphone,etc} parameter. That changes the syntax, and requires a processing model tweak to ignore other parameters (since it's unlikely much useful can be done with them) but the implementation feedback from Google is that that's pretty much nothing. It's tempting to go with this if only because it's implemented already. However, it's probably not widely implemented enough yet that it's too late to change tack.
> 
> Option 2)
> Some people have voiced concerns that this would be better captured (HA!) by adding a capture attribute with said values to the input element. My understanding is that the thinking here is that this is less of a hack, and also less intrusive to HTML since adding an attribute is actually a smaller and more easily ignored modification than changing the syntax of a value.
> 
> On this therefore we would like to solicit your opinion so that we can move forward with our evil plans.
> 
> Thanks!
> 
> 
> [0] http://lists.w3.org/Archives/Public/public-html/2010Jul/0145.html
> [1] http://dev.w3.org/2009/dap/camera/
> 
> -- 
> Robin Berjon - http://berjon.com/
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 8 December 2010 15:46:01 UTC