[css-lists][css-counter-styles] Compute list-style-type to 'decimal' if the specified counter style does not exist

[tabatkins]

On May 8 2016, Xidorn Quan said:

Hi,

Recently, there is a behavior change in Gecko which makes
list-style-type be computed to 'decimal' when the specified counter
style doesn't exist, rather than keeping the specified nonexistent one.
This change helps us save a string for common cases, and simplify some
code. None of which is a big deal, though.

I'm not completely sure what does the spec say for this case. It seems
to me the old behavior is more conformant, but I guess the new behavior
might be perferable, since it makes the computed value match the used
value. So I propose changing the spec to this behavior.

What do you think?

[tabatkins]

(Copied from my response in the original email thread)

I'm fine with this if others are; I don't see any particular reason to keep the non-existent type in computed style. Whichever way is more convenient for implementations is ok with me.

[css-meeting-bot]

The CSS Working Group just discussed CSS Counter style issues., and agreed to the following resolutions:

• RESOLVED: No change.
• RESOLVED: No change to CR; revert the change to the Editor's draft.

The full IRC log of that discussion

<iank_> Topic: CSS Counter style issues.
<astearns> https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611
<glazou> argl
<fantasai> https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611#issue-7
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0076.html
<iank_> fantasai: This is about a counter style which hasn't been created, its kept around and defaulted to decimal
<fantasai> s/about a/about using a/
<iank_> astearns: Seems fine.
<fantasai> fantasai^: Proposal was to compute it to decimal, not keeping around the name
<iank_> fremy: Why would you want to do that in the first place,
<iank_> Rossen: Simplifies code, xidorn also said this wasn't a big issue.
<iank_> fremy: It would for use require a lot of code.
<iank_> fremy: Need some code which would replace the computed style.
<iank_> fantasai: Computed style isn't just used in the om
<iank_> fantasai: I'm not sure why it would be harder to switch unknown values to decimal.
<fantasai> s/om/om, also has to inherit/
<iank_> fremy: In edge you don't need a computed value, if you have a specified value.
<fantasai> s/need/need to store/
<iank_> fremy: When the style is being defined you need to it is going to change the computed style a bunch, you need to invalidate all the styles on the page.
<iank_> Rossen: Going back to the issue,
<fantasai> Basically what François is saying is that if you use an undefined counter style, and the UA computes it to decimal, and then we append an @counter-style rule defining the counter style, this invalidates the computed styles
<iank_> Rossen: xidorn didn't sound too insistent on it, TabAtkins said whatever, which ever way is more consistent.
<iank_> Rossen: At least 1 impl, which will require more cycles to support this, can we live without the simplification?
<iank_> Rossen: I'm mostly interested in moz folks.
<iank_> fantasai: you need to hear from mozilla, and anyone else who is going to impl this.
<iank_> Bert: Is it possible for an unresolved name to define later in the tree.
<iank_> fantasai: No its global scope,
<iank_> Rossen: Since fantasai is looking for resolution, can we resolve to not simplify? Anyone objecting?
<iank_> dbaron: Would be good to hear for xidorn ....
<iank_> Rossen: He didn't think it would be a big deal....
<iank_> RESOLVED: No change.
<fantasai> ACTION TabAtkins revert change in ED
<trackbot> Created ACTION-853 - Revert change in ed [on Tab Atkins Jr. - due 2017-08-09].
<dbaron> RESOLVED: No change to CR; revert the change to the Editor's draft.
<dbaron> github: https://github.com//issues/1616