You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tab and I noticed that we don't rigorously define the serialization of functional notations, so we're proposing to add a generic definition to CSS Values L4.
The non-controversial aspects are:
Serialize the arguments per their individual grammars.
Commas serialize with a following space.
Space-separate adjacent tokens (except between a value and a following comma or closing parenthesis)
The one area where we have very little agreement is
Whether to omit optional values in specified value serialization.
Generally-speaking, we omit optional components in computed values. This is an important principle of CSSOM serialization for computed values. But we are very inconsistent for specified values--this is extra confused by the fact that multiple "serialization" sections in our specs don't distinguish between specified and computed values and just assume there's only one serialization.
The text was updated successfully, but these errors were encountered:
Tab and I noticed that we don't rigorously define the serialization of functional notations, so we're proposing to add a generic definition to CSS Values L4.
The non-controversial aspects are:
The one area where we have very little agreement is
Generally-speaking, we omit optional components in computed values. This is an important principle of CSSOM serialization for computed values. But we are very inconsistent for specified values--this is extra confused by the fact that multiple "serialization" sections in our specs don't distinguish between specified and computed values and just assume there's only one serialization.
The text was updated successfully, but these errors were encountered: