Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marcoscaceres opened this issue Dec 24, 2019 · 2 comments
Open

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

marcoscaceres opened this issue Dec 24, 2019 · 2 comments
Labels

Comments

@marcoscaceres
Copy link
Collaborator

@marcoscaceres marcoscaceres commented Dec 24, 2019

Request for Mozilla Position on an Emerging Web Specification

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

@marcoscaceres marcoscaceres added the wicg label Dec 24, 2019
@bholley

This comment has been minimized.

Copy link

@bholley bholley commented Dec 25, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

@marcoscaceres marcoscaceres commented Dec 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.