[css-syntax] "Serializing <an+b>" doesn't match what Firefox or Safari do

[jyc]

The "Serializing <an+b>" matches what Chrome does, but not what Safari or Firefox does. This section is referred to by the "Serializing Selectors" section of CSS OM.

Firefox just writes n when a is 1, while Safari separates fields with spaces.

With the following page, here are some example serializations given by Firefox, Chrome, and Safari:

<style type="text/css">
  :nth-child(X){}
</style>
<script type="text/javascript">
console.log(document.styleSheets[0].cssRules[0].cssText);
</script>

:nth-child(X)	Firefox	Chrome	Safari
1n - 0	n	1n	1n - 0
n + 1	n+1	1n+1	n + 1
-n - 5	-n-5	-1n-5	-n - 5
+1	1	1	+1
-1n-5	-n-5	-1n-5	-1n-5*
-1n -5	-n-5	-1n-5	-1n -5*

* Does this mean Safari doesn't add spaces if you don't add them, but keeps one if you add one or more?

[dbaron]

I have two thoughts on this:

• The relevant section of syntax should be clearer about what data type A and B are. If it's clear that they're integers then the section would be clearly defined, but it's not particularly clear that they are. (This makes it clear, for example, that the difference between "2" and "+2" is not retained, or the difference between "+0" and "-0", or the difference between "n" and "1n".)
• I think the inclusion of the "1" in "1n" goes against the general principle that CSS serialization serializes to the minimal form. On the other hand, including it is simpler.

[Manishearth]

WPT seems to align with Firefox's behavior, FWIW. I think it expects it to be as simple as possible.

Serialization is generally "simplest way of re-specifying the thing" so I prefer Firefox's behavior here wrt making a optional.

[Manishearth]

What do the browsers do for nth-child(+1)? Do they serialize to 1 or +1?

[jyc]

Adding that to the table! Firefox does 1, Chrome does 1, and Safari does +1.

[tabatkins]

The relevant section of syntax should be clearer about what data type A and B are.

A and B are defined as integers in the definition of the <an+b> type already.

I think the inclusion of the "1" in "1n" goes against the general principle that CSS serialization serializes to the minimal form.

I agree, I should drop the 1/-1. It looks like Chrome already does drop it for -1, according to @jyc's table.

[jyc]

Oops, sorry. Double-checked, my mistake about that. Updating the table.

[tabatkins]

Ah, kk. Well still, the spec is clearly violating the "shortest form" rule, so I should change that.

[tabatkins]

By which I mean, Firefox's results are the most correct as I intended, and I'll fix the spec to match that.

• Does this mean Safari doesn't add spaces if you don't add them, but keeps one if you add one or more?

Probably they're serializing what you put in, so if a whitespace token shows up, they write out a space.

[tabatkins]

Agenda+ for approval to make this change (don't serialize the "1" when A is 1 or -1).

[FremyCompany]

Edge matches Firefox in this case. I think not serializing the "1" is more elegant indeed. You anyway need an exception for 0n so it's not like one can really defend purity anyway.

[css-meeting-bot]

The CSS Working Group just discussed "Serializing <an+b>" doesn't match what Firefox or Safari do, and agreed to the following resolutions:

• RESOLVED: Drop the 1 or -1 on an+b serialization

The full IRC log of that discussion

<dael> Topic: "Serializing <an+b>" doesn't match what Firefox or Safari do
<dael> github topic: https://github.com//issues/1504
<dael> TabAtkins: If the a value is 1 or -1 you write the digit in serialization. This violates general shortest form rule. FF and edge agree on not printing the 1 digit. I'd like to change the spec to match that.
<fantasai> sgtm
<dael> astearns: makes sense to me. Objections?
<dael> RESOLVED: Drop the 1 or -1 on an+b serialization