[css-lists] canonical property order of list-style.

[emilio]

list-style-type accepts an arbitrary identifier via <counter-style>, and thus should be last, since it can overlap with values of list-style-position.

Otherwise serializing the property and reparsing could generated different results.

[carlosame]

Hi Emilio,

list-style-type accepts an arbitrary identifier via <counter-style>, and thus should be last, since it can overlap with values of list-style-position.

It is a bit confusing. A counter-style name is a custom identifier, and custom identifiers are defined like "if it can mess with other identifiers, it is invalid". There is the following at:

https://www.w3.org/TR/css3-values/#identifier-value

Note: When designing grammars with <custom-ident>, the <custom-ident> should always be "positionally unambiguous", so that it’s impossible to conflict with any keyword values in the property.

Then, at:

https://www.w3.org/TR/css-counter-styles-3/#at-ruledef-counter-style

you have this:

Note: Note that <custom-ident> also automatically excludes the CSS-wide keywords. In addition, some names, like inside, are valid as counter style names, but conflict with the existing values of properties like list-style, and so won’t be usable there.

So inside is a valid counter-style name, but is "not usable" in the shorthand. That sounds a lot like an invalid <custom-ident>. The "Counter Styles" specification should be changed to declare inside and outside invalid counter-style names.

[emilio]

Hmm, the problem with that kind of thing is that it prevents you from adding keywords to list-style-position without potentially breaking code...

Plus now you need to also make it invalid in the longhand, or then not serializing it in the shorthand.

Seems strictly worse and more complicated than swapping the values to me...

FF definitely allows you to write list-style-type: inside, and similar. Seems like Blink / WebKit don't implement the <counter-style-name> bits, does any other browser?

cc @upsuper

[carlosame]

Hmm, the problem with that kind of thing is that it prevents you from adding keywords to list-style-position without potentially breaking code...

But inside and outside are there since the beginning of the shorthand, and counter-styles are a less established feature AFAIR.

Seems strictly worse and more complicated than swapping the values to me...

Not mutually exclusive. Your proposal make things a bit more deterministic, but still potentially confusing to users. I do not have a strong opinion in favour or against it (like if that mattered), but still think that banning those two values would be a good idea.

[carlosame]

Seems like Blink / WebKit don't implement the bits, does any other browser?

Apparently not, according to browser compatibility table at:

https://developer.mozilla.org/en-US/docs/Web/CSS/@counter-style

And my latest Chrome does not support the demo at:

https://mdn.github.io/css-examples/counter-style-demo/

[carlosame]

So far, I have been thinking here in terms of problems when parsing an author-specified shorthand, however when it concerns serializing:

Otherwise serializing the property and reparsing could generated different results.

Serialization should involve a sanity check of the individual values, that's what I do in my code (admittedly not for all shorthands) and I was assuming that browser people does the same. For example, in tests with real-world sites I found frequent cases where url() PNG images were set to background-color properties, which then bombs a blindly-produced shorthand. So my code checks for those cases.

FF definitely allows you to write list-style-type: inside, and similar.

That should not be a problem if you do not produce a shorthand with it (you could produce a shorthand plus the problematic property:value, or keep all the longhands in the serialization). Perhaps that should be the first thing to check out here.

[upsuper]

So, we have a precedent for putting <custom-ident> at the end of shorthand to avoid conflicting with other keywords, which is animation. That case is also mentioned in the note of css-values spec as an example of designing "positionally unambiguous" grammar with <custom-ident>.

Given that, I tend to think we should change css-counter-styles to remove that note and change the canonical order of list-style shorthand.

cc @tabatkins

[faceless2]

(@emilio , thanks for the cross-reference, somehow I missed this issue when I opened #2724)

The example I filed in the other issue I think is worth reproducing here for clarity

@counter-style inside {
...
}
@counter-style outside {
...
}
ul { list-style: inside outside } /* ambiguous */
ol { list-style: inside none } /* ambiguous */
ol { list-style: outside } /* ambiguous */

I'd be against reordering of the list-style shorthand as a solution.

It's currently defined as <list-style-type> || <list-style-position> || <list-style-image>, which allows free reordering of the terms.

If you want to change it to remove the ambiguity introduced by allowing list-style-type to match "inside" or "outside", you're still going to have to allow any order except when the type is called "inside" or "outside". So "list-style: decimal inside" will remain valid, but "list-style: outside inside" where the counter is called "outside" is not.

First, the grammar is going to more complicated then necessary; something like [<list-style-style-type-except-inside-outside> || <list-style-position> || <list-style-image>] | [<list-style-position || <list-style-image>] [inside | outside]?, and that's discounting the special handling that will be required to interpret "none" correctly.

Second, even with an unambiguous grammar it will remain confusing. An author seeing "list-style: inside outside" will have no idea what is going on without consulting the spec.

Given so few browsers implement @counter-style at this stage, personally I feel the best solution is disallowing "inside" and "outside" as counter names. We already do it with "none" so there's precedent. Prevent authors from shooting themselves in the foot.

The second best solution would be not allowing them to be referenced from the list-style shorthand property. As pointed out above, there is no ambiguity except in the list-style shorthand property.

[upsuper]

I've mentioned before, there is precedent. The syntax of animation is

<time> || <timing-function> || <time> || <single-animation-iteration-count> || <single-animation-direction> || <single-animation-fill-mode> || <single-animation-play-state> || [ none | <keyframes-name> ]

which should allow free reordering of the terms, but <keyframes-name> is always parsed the latest, and thus something like ease ease is not ambiguous.

[faceless2]

There are plenty of property shorthands that restrict ordering: font: italic 300px bold is referencing a font called "bold", there's no ambiguity.

But if that is going to be the solution for list-style then it has to be done without breaking the existing syntax, which allows the list-style-type as the first item in the list.

[upsuper]

FWIW, Firefox has been shipping the feature using this syntax for several years, and I don't think I heard any breakage caused by this change.

[upsuper]

By "this syntax", I mean <list-style-position> || <list-style-image> || <list-style-type> for the shorthand, and thus we propose to change the spec to adopt this canonical order.

[tabatkins]

font isn't a particularly relevant example; it has to have a font-family in it, and that value has to be last, so it's generally "positionally unambiguous".

(There are exceptions to this; if the font-family is "Bold New Font", then font: italic 300px Bold New Font could potentially be parsed as a bold version of "New Font" or as a normal version of "Bold New Font". But it's usually true, unlike the animation example.)

FWIW, Firefox has been shipping the feature using this syntax for several years, and I don't think I heard any breakage caused by this change.

I'm extremely convinced by this argument and thus am fine with it. ^_^