html
html copied to clipboard
whatwg
Define `<input capture>`, ideally with a hint for which camera to use
IIRC <input capture> isn't actually defined in a spec that's being actively maintained, and offhand I don't know why it wouldn't be defined in HTML with the rest of <input>'s attributes. Ideally its value could be taken from VideoFacingModeEnum, (which would be taken as a hint for which camera is preferred). If capture="" has to remain a boolean attribute for compat reasons, I suppose we'll have to mint a new attribute to carry the hint.
I believe it's defined in https://w3c.github.io/html-media-capture/, which may not have the best maintenance but they at least accepted my pull request a few days ago. Maybe it's just stable and "done"?
In general I favor rolling these sorts of things into HTML, but I imagine the politics and process around that are a bit tricky, and some people might argue that a modular design that allows extension in other specs is better.
Tagging in @anssiko who's the current editor.
Oh, hey, looks like I need to learn how to use a search engine better. Sorry for the noise.
I don't think it's noise. If we keep it separate, we should probably reference it from several places, such as the element's definition and the indexes. It's nice to have an overview of all of HTML.
The capture attribute is implemented in Blink https://crbug.com/240252 and WebKit https://webkit.org/b/118465. IIRC, the feature ships in Chrome for Android, and some mobile browsers in the long tail (e.g. BlackBerry, Tizen). The feature was first conceived in Android browser, which predated Chrome.
For new feature requests or hooks to make integration with the HTML spec easier, please feel free to open issues at https://github.com/w3c/html-media-capture/
I'm actively maintaining the spec, even if it may look dormant looking at the commit logs. The spec has just been "done" (and we're stuck at CR mostly because of testing requirements).
If you feel like merging the feature into the HTML, I can ask the group about the process hoops to jump through.
Whichever spec it is in, I'm in support of this. There is one caveat. The proposal turns the IDL from
attribute boolean capture;
to
attribute DOMString capture;
which makes for one backwards incompatible change, which is that disabling capture via JS would no longer work:
document.getElementById("inputFileCapture").capture = false;
I think it's an acceptable tradeoff for a more streamlined flow of capturing with the right camera.
We should get capture into the HTML standard itself. In general, all elements and attributes for the HTML language should be available in the HTML standard itself, even if some or all of the associated requirements for the element or attribute are defined in a separate spec, with the HTML standard referencing that spec.
So let’s please work together on getting capture included in HTML. cc @xfq
Sounds good. I'll work with @xfq and the DAS WG on the logistics.
FWIW, the input[capture] spec now been at Rec for ~2 years, and folding it into HTML would make its maintenance easier.
CfC to integrate HTML Media Capture spec into HTML Living Standard sent to DAS WG, responses due 31 March 2020: https://lists.w3.org/Archives/Public/public-device-apis/2020Mar/0005.html
Update: CfC passed with no concerns.
I asked @wseltzer for advise on how a W3C Host could contribute this feature to HTML LS. I believe the dependency here is https://github.com/whatwg/sg/issues/62.
Ping @wseltzer for an update. I’ve understood this is now being looked at.
Meanwhile, the draft DAS WG Charter now explicitly mentions this:
Since HTML Media Capture extends the HTML Living Standard, the Working Group may propose to W3C to upstream the spec when completed, to the WHATWG HTML LS for maintenance, as anticipated by Section 10.2 of the Memorandum of Understanding Between W3C and WHATWG.
That said, I hope we could resolve this issue before the new DAS WG charter is in effect July 2020.
@annevk, @domenic, when we move this over, do you want just the content attribute? or should we also include the IDL parts (i.e., just transplant everything, including the examples)?
I think the idea is to move all of it over, yes. In general we want attributes and corresponding IDL attributes to be defined in HTML, potentially referencing another document for (part of) the processing model. In this case inlining everything seems easiest.
