Define <input capture>, ideally with a hint for which camera to use

[hober]

2023-12-13 summary by @domenic of the work to be done:

We need to upstream https://w3c.github.io/html-media-capture/ into HTML. The core logic is in https://w3c.github.io/html-media-capture/#the-capture-idl-attribute, and needs to be updated to be consistent with the HTML Standard's existing conventions, such as:

• Being located in the right place, i.e. in HTML's definition of HTMLInputElement, the File Upload state, and the "show the picker, if applicable" algorithm.

• Adhering to HTML's editorial style, e.g. defining enumerated attributes using the same table format as other enumerated attributes, using lowercase "must" and "should", etc.

Additionally, some portions of user agent advice that are currently in "security and privacy considerations" need to move into the normative text.

For the examples section, not all of it needs to be ported over, but porting over 1-3 HTML or JS code examples and also the file picker rendering examples to https://html.spec.whatwg.org/#file-upload-state-(type=file) would be good.

Finally, we need to add authoring conformance requirements on the capture attribute. This would be done by modifying all the discussion about "apply" and "do not apply" in https://html.spec.whatwg.org/#the-input-element; use the existing accept attribute as a model. It seems we'll need an additional authoring conformance requirement that the attribute must only be specified if the accept attribute is also specified.

In general, the accept attribute, as another attribute which only applies in the File state, is a good model.

Original post follows:

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.

[domenic]

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.

[hober]

Oh, hey, looks like I need to learn how to use a search engine better. Sorry for the noise.

[annevk]

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.

[anssiko]

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.

[legion80]

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.

[sideshowbarker]

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

[anssiko]

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.

[anssiko]

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

[anssiko]

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 whatwg/sg#62.

[anssiko]

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.

[marcoscaceres]

@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)?

[annevk]

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.

[zcorpan]

What's the status here?

[annevk]

This needs a volunteer. 😀