W3C home > Mailing lists > Public > public-html@w3.org > December 2010

Re: Media Capture

From: Robin Berjon <robin@berjon.com>
Date: Wed, 8 Dec 2010 17:07:46 +0100
Cc: HTML WG <public-html@w3.org>, Frederick Hirsch <Frederick.Hirsch@nokia.com>, Dominique Hazael-Massieux <dom@w3.org>, Thomas Roessler <tlr@w3.org>
Message-Id: <9BE87E53-4141-4812-9B3B-975E15AA4DAB@berjon.com>
To: David Singer <singer@apple.com>
Hi David,

thanks for your feedback.

Just for everyone's convenience, the section under discussion is http://dev.w3.org/html5/spec/number-state.html#attr-input-accept.

On Dec 8, 2010, at 16:45 , David Singer wrote:
> 1) The acceptability of parameters to MIME types belongs, as I understand, with the MIME type owners and not with the W3C.

Actually in this context I believe that it makes sense. In at least a large plurality of cases, it will be difficult at best for user agents to filter the picker based on what parameters state.

> 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.

The argument that there is a potential clash is certainly acceptable. I wonder if one potential work around is to only accept the capture parameter on {audio,video,image}/*. (Just a thought.)

> 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).

I think that the issue with that is that the UA would have to inspect every video file in a given directory to know whether to present it to the user. That's assuming it's even implementing the file dialog itself  native file dialogs typically support filtering on some (possibly rough) equivalent of the media type, but I am not aware of one that goes into sufficient detail to support the sort of query you're describing.

> 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").

It's definitely a hint and the UA is perfectly allowed (I would say encouraged) to offer alternatives in all situations. That being said the hint is useful as it allows the UA to provide a smoother UI when it has additional information.

> 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.

So I'm hearing +1 for a capture attribute.

BTW, it would be nice to have something like this in Mobile Safari. It's frustrating that file inputs are just disabled :)

-- 
Robin Berjon - http://berjon.com/
Received on Wednesday, 8 December 2010 16:08:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:07 UTC