Design Review #490

#490: Image Resource

Opened Mar 25, 2020

Hello TAG!

I'm requesting a TAG review of Image Resource.

The specification defines the concept of an "image resource" and a corresponding WebIDL ImageResource dictionary. Web APIs can use the ImageResource dictionary to represent an image resource in contexts where an HTMLImageElement is not suitable or available (e.g., in a Worker).

Specification URL: https://w3c.github.io/image-resource/
GitHub repo: https://github.com/w3c/image-resource
Primary contacts (and their relationship to the specification):
- Aaron Gustafson (@AaronGustafson), Microsoft
- Rayan Kanso (@rayankans), Google
- Marcos Càceres (@marcoscaceres), Mozilla
Organization(s)/project(s) driving the specification: Web Apps WG
Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/w3c/image-resource/issues
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): n/a

Further details:

I have reviewed the TAG's API Design Principles
Relevant time constraints or deadlines: We would like to move this to FPWD soon.
The group where the work on this specification is currently being done: Web Apps WG
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
Major unresolved issues with or opposition to this specification: None
This work is being funded by: Google, Microsoft, Mozilla

You should also know that this proposed spec is an extraction of Image Resource from the Web App Manifest.

We'd prefer the TAG provide feedback as a comment in this issue and @-notify @marcoscaceres @aarongustafson @rayankans

Discussions

2020-04-06

Minutes

[ran out of time; push out one week

2020-04-13

Minutes

Rossen: This seems quite straightforward. David had some questions unaddressed.

David: Not sure if it makes sense to go in to the technicalities, this is effectively a struct

Rossen: The sizes part of this spec is a bit strange, do we have other cases that provide an interface that should be matched for consistency?

My question is - if a specific size fails, should it throw or try to fall back to a default size?

David: There is a section in the HTML spec about parsing (shares link)

Rossen: But this doesn't match up with what the spec says. The spec has a hard throw if it fails, which doesn't look possible in the HTML spec parsing.

Peter: Explainer?

Sangwhan: Doesn't exist but not sure if it's worth picking the figh

2020-04-20

Minutes

David: Propose closing it - we spent a lot of time on this given its small size. I think we've given them a lot more feedback than those 3 paragraphs would have gotten had they stayed in their original spec.

Ken: I am OK with that.

David: Defer to plenary whether we will close or not.