Loirooriol
commented
3 years ago Some common patterns:
Open tabatkins opened 3 years ago
Loirooriol
commented
3 years ago Some common patterns:
cdoublev
commented
2 years ago If I may, what is the rationale for pattern 1 (remove optional component values)? It is always extra work, for what purpose?
EDIT: from reading multiple related issues, serialization to an older syntax, which may me shorter or longer, can help back-compat. I wonder what would be the conditions/scenarios where this backward compatibility requirement might be useful, though.
tabatkins
commented
2 years ago It brings the value closer to what humans would likely write, which makes it easier to read.
cdoublev
commented
2 years ago I had figured it that too, but it seems less important than back-compat. And for shorthand (eg. animation), the shorter meaning the more human-friendly, may be subjective.
cdoublev
commented
1 year ago I do not know if math functions generally fall into the "weird case" category but the SSP is currently applied inconsistently with them.
For example, Serialization in CSS Images 3 requires omitting components when possible without changing the meaning:
For example, a gradient specified as:
Linear-Gradient( to bottom, red 0%,yellow,black 100px)must serialize as:
linear-gradient(red, yellow, black 100px)
(The same section in CSS Images 4 serializes red, yellow, black, to rgb(), which makes me wonder if it applies to specified values though.)
Chrome/Firefox omit to calc(180deg) (same as to bottom) in <linear-gradient()> but math functions usually seem to be preserved elsewhere. And they do not omit components in the color stop list. You cannot know 75% can be omitted in linear-gradient(red 50%, blue 0%, 75%, green) without applying color stop "fixup", which is meant to resolve used values.
Obviously color stop list is a "weird case" but I think there are many cases similar to the first. Eg. Chrome/FF do not serialize specified border-radius: 1em calc(1em) to border-radius: 1em.
I guess browsers do not try too hard to resolve values until they know it is required for rendering, which makes me think that not applying the SSP for specified values (except for backward-compatibility) would be way more simple.
cdoublev
commented
1 year ago I did an in-depth specific research on serialization of optional numeric values, or optional keyword values mapping to a numeric value, in Chrome and Firefox.
They usually only seem to be omitted when they are strictly equal to a default value or an initial longhand value, without applying any resolution before the comparison (presumably with serialized strings):
[0,360)Two numerics with a value of 0 but of a different type or with a different unit are usually not considered equal, except 0px and 0 when it matches <length> (it is presumably normalized to 0px at parse time).
Serialization of computed values is generally governed by applying the shortest-serialization principle to the computed value. It's a bit handwavey, and there are some exceptions, but overall it works.
But specified values do not seem to serialize according to the SSP in general; instead, they seem to usually retain more details of what the author originally wrote. Sometimes it's literally the original text, sometimes some light modification is done. (For example, Chrome sorts the 'contain' keywords specified, but doesn't combine them into shorthands like it'll do for computed values.)
I suspect there's a lot of non-interop around this, but we should have more details at least on general principles, even if we don't have all the weird specifics.