-
Notifications
You must be signed in to change notification settings - Fork 636
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
[css-images] image-set: should we serialize options with unsupported type? #8495
Comments
I'm not sure I understand - an unsupported image type absolutely does something, namely it removes the url from consideration. Could you give an explicit example of what you're thinking of? |
Right, that probably wasn't clear. If I have something like this: image-set(url("img.png") type("image/png"), url("img.unsupported") type("image/unsupported")) Which of these should it serialize to?
My point about omitting the unsupported type was that the image that is chosen by the engine will be the same in either serialization. |
Ah, ok. Hm, the intention of the text was to invoke the "shortest serialization principle" (the bullets under step 2 of https://drafts.csswg.org/cssom/#serializing-css-values). That generally means things like omitting values that are equivalent to defaults, not dropping entire meaningful units. But we do drop things like that sometimes, and I'm happy to specify it more clearly either way, honestly. |
I'm learning now while trying to write a test that omitting unsupported types leads to non-round-trippable serializations if the set ends up empty. image-set("img.png" type("image/unsupported")) would serialize to (something like) Since type isn't supposed to determine the validity of the |
That's what I'd lean towards, so 👍 |
I think option 1 in my example fits the intention you pointed out. While the outcome is unchanged, the validity of the serialized value is changed. Thanks! |
In the serialization section of css-images-4 it says:
(emphasis mine)
I read that as omit unsupported types since the meaning of the image-set is unchanged from the perspective of the engine. That is, if an unsupported image type were left out of the image-set the result would be unchanged.
Is that a good reading? Should the prose be explicit for this case?
The text was updated successfully, but these errors were encountered: