[cssom] Spec no longer defines the general "shortest serialization" principle

[tabatkins]

Back in the 2011 WD, there was a set of "serialization principles", giving general guidance about how to select the correct serialization of a CSS property. In particular, it gave guidance about how to order re-orderable values (use the grammar order) and how to omit omittable values (do so whenever it wouldn't change the result of reparsing, unless it would leave you with an empty value). The CSSWG still refers to and understands these principles as a general "shortest form" idea.

However, that no longer seems to be present in the current draft. In particular, it's missing from the following 2013 WD. This, or something like it, needs to be reinstated so as to actually give some guidance about how to serialize property values.

(We obliquely refer to this principle in the note at the end of Align's baseline section, and dbaron requests a link to the principle we're alluding to in #1415.)

[foolip]

I've run into this in web-platform-tests/wpt#8548 (see @dbaron's comments) and in web-platform-tests/wpt#8602 wrote a test that showed that all browsers except Chrome serialize the text-decoration shorthand to something more compact than the spec suggests. I'm going to revert the pass condition of the test and make it a tentative tests assuming that the spec will come to agree with the 3 instead of the 1.

[MatsPalmgren]

Can someone make the necessary edits here please? It seems to cause a lot of confusion about the correct serialization [1] [2] because this important principle isn't written down in a spec.

[tabatkins]

Ugh, we don't have an editor for the spec anymore. I'll do it soon if nobody else does.

[dbaron]

I'd note that it's probably worth making it clear that the principles are principles and probably not normative text. In particular, I probably wouldn't want to see an implementor follow the principles to change something that's currently interoperable to be non-interoperable, but I would like to see the principles drive decisions for new features, and (within the constraints of web compatibility) for existing features that aren't currently interoperable.

I'd also note that some other principles for serialization are:

• serialization should always produce syntax that is valid when reparsed
• the composite function of serialize(parse()) should be idempotent, that is, reparsing and reserializing the result of serialization should produce the same thing you got from the first serialization

[tabatkins]

In the second bullet point, to be clear, S(val) should be the same as S(P(S(val)); just taking an arbitrary CSS string and passing it thru S(P(str)) won't necessarily reproduce the same string.

[css-meeting-bot]

The Working Group just discussed [cssom] Spec no longer defines the general "shortest serialization" principle, and agreed to the following resolutions:

• RESOLVED: add serialization principles to cssom

The full IRC log of that discussion

<dael> Topic: [cssom] Spec no longer defines the general "shortest serialization" principle
<dael> github: https://github.com//issues/1564
<dael> fantasai: main issue is we need someone to make edits. There's no active editor. This keeps coming up as some editor is confused as to why FF serializes different and it's because this isn't in the spec.
<dael> fantasai: Can we assign somebody to do the edits?
<dael> astearns: There's the edits to re-introduce the shortest serialization and the other preinciples dbaron mentioned.
<dael> fantasai: Yes, they should all be in the spec but no one is owning them.
<dael> astearns: I would love to have an editor for CSSOM. I've been trying to recruit one. Anyone on the call willing to volunteer.
<dael> TabAtkins: I can do particular issues, but not the new general editor
<dael> astearns: Can we tasks you to add the principles in the issue? Just this edit.
<dael> TabAtkins: Absolutely.
<dael> tantek: Not volunteering. Do we have a label for something like PR desired where there isn't someone assigned but we'd welcome someone to do a PR for this item?
<Chris> "Good first issue"
<dael> astearns: We don't but it would be good. A first issue tag for easy thigns would also be good for someone new.
<dael> florian: We have edits needed, but doesn't distinguish.
<dael> tantek: This is a callout to a volunteer stepping forward instead of saying this is the a to do list.
<dael> tantek: This is a good example where it's non-normative text where it's a easy first edit.
<dael> fantasai: This isn't non-normative
<dael> tantek: Reading dbaron text it sounded like it's non-normative
<dael> TabAtkins: This is in the guideline of things where we really want to say it normative but there's too many variations. THis needs an experienced editor
<dael> florian: The principle of tantek ask is sound
<dael> fantasai: Spec is normative and will say there are exceptions. For properties should should be able to apply these and get correct serialization
<dael> tantek: I think enough text is in there that a new person culd do a decent PR. This is the kind of edit I'd welcome someone taking a shot at. Anyway. Didn't mean to sidetrack
<dael> astearns: It would be good to have a tag saying outside submissions welcome and a tag that says this is unassigned and we don't have an editor.
<dael> TabAtkins: Agree to both
<dael> action TabAtkins to make the edits in https://github.com//issues/1564
<trackbot> Created ACTION-867 - Make the edits in https://github.com//issues/1564 [on Tab Atkins Jr. - due 2018-02-21].
<dbaron> I think this is the sort of edit where I'm likely to have substantive disagreements with draft text by Tab, and Tab would be likely to have substantive disagreements with draft text by me.
<dael> action astearns to come up with new tags for new edits
<trackbot> Created ACTION-868 - Come up with new tags for new edits [on Alan Stearns - due 2018-02-21].
<krit> +present
<dael> astearns: objections to putting these principles into cssom?
<dael> RESOLVED: add serialization principles to cssom

[FremyCompany]

Just want to make sure that the text we add back does mention that these general principles can be overriden in specifc instances due to web compat or ease of use of an api. Sometimes authors expect one easy-to-parse format over another that would be shorter (rgba(0, 0, 0, 0) vs transparent) and sometimes new values are added to a property and those new values would allow a shorter form than before, but that would not be web-compatible.

[dbaron]

Serializing to the form that's been specified longer is another general principle that should be documented, and generally overrides the principle of trying to be shorter. (Though at some point we decided to break that for transparent, with Gecko being the last implementation to switch.)

[FremyCompany]

@dbaron We haven't switched yet in Edge on transparent
However we serialize the way the author specified so someone using rgba would get rgba.

[tabatkins]

Okay, done. I ended up replacing the whole algorithm; it was full of overly-specific and flat-out wrong details (some preserved from Anne's older draft, some new). It now represents the "shortest serialization" principle of Anne's older draft, while being correct overall. It also normatively notes that some properties must serialize differently than this algorithm due to backwards-compat.

There are still a number of details to fix about serializing individual component values, but that'll be addressed by a separate issue.

[tabatkins]

@dbaron @FremyCompany Please review?