output attributes on HTML's <input type=file> element

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Native media optimization and (basic) editing support
• Specification or proposal URL: https://discourse.wicg.io/t/proposal-native-media-optimization-and-basic-editing-support/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

Proposal to add various output attributes on HTML's <input> elements that would allow developers to declare some conversions the browser could do to, for example, images and videos.

<input type="file" 
   accept="image/*"
   output="image/jpeg"
   outputDimensions="1:1">

Conversions can include:

• format
• size
• length
• dimensions
• compression
• possibly other things...

This is intended to address the long-tail problem and complexity of converting/editing files by deferring the problem to either the OS or the browser (instead of JS libraries, CDNs, WASM, etc., which, it is argued by those making the proposal, haven't seen adoption in the long tail).

[bholley]

I am sympathetic to the argument that, even if client-side image optimization is technically possible today, it's the sort of complex thing that gets deployed by big sites when optimizing at scale. So this could both empower smaller developers, and nudge the ecosystem in a positive direction.

On the flip side, I'm concerned about runaway complexity. The WICG thread is already talking about options for chroma sub-sampling, and it's not at all clear to me where the feature line should be drawn. Same goes for formats and media types.

[marcoscaceres]

On the flip side, I'm concerned about runaway complexity.

Agree, I also said the same in the thread. I think it should be possible to find a reasonable sub-set however. There is some precedence on iOS around images, for instance, and file size hints... and we could definitely make a case to triage, say, 2-3 things that would give the most return on investment. If those become interoperable, then pick up the next few from there and incrementally build on those across UAs.

[dbaron]

I'm concerned about complexity, and also concerned about inability to hook things up to other APIs the browser has reducing the value. I'd be less concerned about the latter if it output something like ImageData (although that probably has some current issues), and the platform had mechanisms for converting ImageData to various other things. It's also one of those spaces where I'd wonder why there aren't successful javascript libraries if the current state is that it's so hard.

Maybe it makes more sense to start by more directly exposing the existing primitives, e.g., through a conversion of Blob to ImageData or something like that, which could then be usable from the existing input.files but also from other things.

[dbaron]

I think my inclination is to mark this as non-harmful, given that:

• I would be more likely to support prototyping of a proposal that was less inclined towards runaway complexity, and more inclined towards composability with other features
• but it does seem to be addressing real use cases and doesn't seem harmful.

Thoughts?

[annevk]

It would indeed make much more sense to me if this were defined in terms of createImageBitmap() or some such.

The other consideration here is that I think we only mandate conversion to PNG today, though I think implementations support JPEG too.