Repository navigation
[css-values-4] Serialization of Functional Notations #9720
Description
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.
Activity
fantasai commentedon Dec 18, 2023
Specified vs computed is defined here, fwiw: https://www.w3.org/TR/css-cascade-5/#value-stages
[css-values-4] Define generic serialization for functional notations. w…
svgeesus commentedon Dec 19, 2023
Nice, I'm comparing with the serialization stuff in Color 4 and 5 and Fonts 4 to pick up any differences.
[css-values-4] Define generic serialization for functional notations. w…
[css-values-4] Define generic serialization for functional notations. #…
css-meeting-bot commentedon Jun 24, 2026
The CSS Working Group just discussed
[css-values-4] Serialization of Functional Notations, and agreed to the following:RESOLVED: accept this PR as the start of serialization of functional notation, open new issues based on textThe full IRC log of that discussion
<kbabbitt> fantasai: TabAtkins and I 3 years ago drafted up a PR describing serialization of functional notation<kbabbitt> ... we wanted to review that with the WG
<kbabbitt> ... we serialize each argument according to its individual grammer
<kbabbitt> ... serialize commas with space that follows
<kbabbitt> ... space separated tokens
<kbabbitt> ... one area where we weren't very sure what to do was whether we omit optional values in specified value serialization
<kbabbitt> ... in computed values we do it all the time
<kbabbitt> ... for specified values we're a little inconsistent
<astearns> q+
<kbabbitt> ... because a lot of our specs wrote serialization rules without thinking about specified vs computed
<kbabbitt> ... we're getting better about it but historically have not been good abou tit
<fantasai> https://github.com//pull/9721/changes
<kbabbitt> astearns: would it make sense to choose that we express optional values in specified values and where we can't do that for compat reasons or historical inconsistency add those exceptions?
<kbabbitt> ... seems to me that getting close to what the actual specified value is, is what's intended for specified values
<astearns> ack astearns
<kbabbitt> fantasai: looks like when we drafted this, we serialize computed values by omitting optional compnents, but we don't for specified or declared values
<kbabbitt> ... might need exceptions for compat but thought this was the right direction to go in
<kbabbitt> astearns: chair hat off, I think that sounds right
<kbabbitt> ... we should only omit for computed values
<kbabbitt> ... other opinions?
<fantasai> 2. Append to |s|
<fantasai> the serializations of the arguments of the [=functional notation=]
<fantasai> per their individual grammars,
<fantasai> in the order the grammars are written in,
<fantasai> joining space-separated tokens with a single space,
<fantasai> and following each serialized comma, colon, semi-colon, or slash
<romain> +1
<fantasai> with a single space (U+0020 SPACE).
<kbabbitt> ... sounds like this is a good start towards specifying serialization of functions
<fantasai> When serializing the [=computed value=] or its derivatives
<fantasai> (not [=specified values|specified=] or [=declared values|declared=] values),
<fantasai> omit components when possible without changing the meaning.
<kbabbitt> ... might be good to get this in after 3 years
<kbabbitt> astearns: Proposed resolution is that we accept this PR as the start of serialization of functional notation, open new issues based on text
<kbabbitt> ... objections?
<kbabbitt> RESOLVED: accept this PR as the start of serialization of functional notation, open new issues based on text
<fantasai> Merged! \^_^/