Seems like it might be worth briefly explaining how this differs (it does!) from CanvasImageSource or ImageBitmapSource.

Adding @rayankans & @marcoscaceres for visibility

@torgo As ImageResource exists within the Web App Manifest currently, do we need to create an explainer for it or would the repo readme suffice?

Also, it seems like the Status of this document section should be for the Web Apps WG, given that it seems that's where the doc is being developed.

Is there a destined final home (as a section of some other spec, presumably manifest) for this, or will this live on as a separate spec? Curious if there are other struct specs in the pipeline that could be also put into the same spec in that case.

Also, it seems like the Status of this document section should be for the Web Apps WG, given that it seems that's where the doc is being developed.

This request is coming from the Web Apps WG, prior to us graduating this and making the edits necessary to the manifest spec.

Is there a destined final home (as a section of some other spec, presumably manifest) for this, or will this live on as a separate spec? Curious if there are other struct specs in the pipeline that could be also put into the same spec in that case.

We extracted this from the Manifest spec specifically because the same concept is being used elsewhere (e.g., payments and notifications). Our plan is to have it remain independent and get pulled into other specs and extended as necessary (e.g., the manifest spec as a purpose member).

One other thing we discussed during the breakout was the differences between the sizes attribute on link versus img and what definition was being linked to.

Following up afterwards, it looks like the section titles like § 4.8.4.2 Attributes common to source, img, and link elements seem to imply that the attribute is the same for both, though I didn't trace all the definitions. We found very detailed processing rules that apply to these attributes, and found things in the HTML spec that link to that definition, but don't see how this spec links to that definition, since it use the text (twice, with link) "as if it was a sizes attribute" which links to the attribute's description and not to that detailed processing model.

It seems like something in this spec should reference those parsing rules.

@dbaron I'm not sure if that's the right thing to link to. For one thing, what counts as a valid value for the definitions do not overlap.

• https://html.spec.whatwg.org/multipage/semantics.html#attr-link-sizes
• https://html.spec.whatwg.org/multipage/images.html#sizes-attribute

@dbaron is correct. "Validity" is for HTML conformance checkers, not for browsers. The parsing rules are what browsers need to implement.

Ok I see the source of the confusion now, that's the processing rule for the img's sizes attribute instead of the one for link.

https://html.spec.whatwg.org/multipage/links.html#attr-link-sizes-any

The point I was trying to make is that if you want to define how implementations should process something, you should link to the rules for how an implementation processes something, not to the rules describing the semantics or the rules describing the set of valid values for documents. The wording about the semantics of the attributes appears to be different for <img> and <link> (I think -- there's a lot of links to follow), but the implementation processing rules are common.

In particular, § 4.8.4.3.9 Parsing a sizes attribute applies to both img and link since it's linked from update the source set which is linked from select an image source which is linked from:

• § 4.6.6.18 Link type "preload" (for <link>)
• § 4.8.4.3.5 Updating the image data (for <img>)
• § 4.8.4.3.11 Reacting to environment changes (also for <img>)

(Some useful background for understanding that distinction might be Hixie's old blog post on Kinds of statements which is linked from § 10.1 Other resources in the TAG's design-principles document.)

Note "parsing a sizes attribute" for <link> is for the imagesizes attribute, not the sizes attribute. 🙃

Oh well. Maybe I need a summary of what's what, since I've lost track. :-/

In any case, at this point the TAG has reviewed this in rather more detail than we'd normally have reviewed this set of paragraphs had they not moved into their own spec. At the level we'd normally review something, we're happy with this, and don't see a need to leave this issue open.

That said, there's a bit of low-level feedback in this issue on both what to refer to, and a little other stuff that might make the point of the separate spec clearer to readers. If you'd like us to file issues on that stuff, let us know, although you did request feedback in this issue rather than in your own repo.

In any case, thanks for requesting TAG review.