[css-images] image-set: should we serialize options with unsupported type?

[rreno]

In the serialization section of css-images-4 it says:

To serialize any function defined in this module, serialize it per its individual grammar, in the order its grammar is written in, omitting components when possible without changing the meaning, ...

(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?

[tabatkins]

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?

[rreno]

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?

'image-set(url("img.png") 1dppx type("image/png"), url("img.unsupported") 1dppx type("image/unsupported"))'
'image-set(url("img.png") 1dppx type("image/png"))'

My point about omitting the unsupported type was that the image that is chosen by the engine will be the same in either serialization.

[tabatkins]

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.

[rreno]

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) image-set() which is not a valid image-set, even though it was valid as written.

Since type isn't supposed to determine the validity of the image-set itself maybe it's best to serialize as-written (so option one above).

[tabatkins]

That's what I'd lean towards, so 👍

[rreno]

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!