- From: Rich Tibbett <richt@opera.com>
- Date: Fri, 27 Jul 2012 13:43:01 +0200
- To: public-device-apis@w3.org
fantasai wrote: >> On 7/19/12 6:02 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote: >> >>> Hi! >>> I was wondering, how is 'capture' different from 'accept'? It seems >>> to me >>> the >>> following are equivalent: >>> >>> capture accept >>> ---------------------- >>> camera image/* >>> camcorder video/* >>> microphone audio/* >>> filesystem */* >> >> No. accept="image/*" tells you nothing about the desired capture mode, >> which could be either of camera or filesystem. > > So the distinction between the two is that using the 'capture' attribute > indicates that a live capture is preferred? > > In that case, I suggest that the 'capture' attribute be a boolean, > leaving the type-checking to the 'accept' attribute, which already > serves this function. What would happen in the following case (assuming accept and capture are independently optional)? <input type=file capture> It could be nice to be able to invoke the camcorder/camera/microphone directly without having to always specify an accept attribute. The accepted mime types for any input elements that don't have an accept attribute can be inferred from the capture attribute's value precisely because of the equivalence you mention above. <input type=file capture=camcorder> The implication here is that the returned file(s) will be of type 'video/*'. > > Not only would this avoid duplication, it also avoids conflicts like > > <input capture=microphone accept='image/*'> I believe the spec does address this: "The HTMLInputElement interface's accept attribute takes precedence over the capture attribute. That is, if the accept attribute's value is set to a MIME type that is not accepted in a defined capture state, the user agent must act as if there was no capture attribute." - Rich
Received on Friday, 27 July 2012 11:43:33 UTC