[css-lists-3] Compute non-existent `list-style-type` <counter-style> to `decimal`?

[fantasai]

In https://lists.w3.org/Archives/Public/www-style/2016May/0076.html @upsuper wrote:

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 replied

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.

Any other opinions, or should we update the spec to match Gecko?

[emilio]

I don't think Gecko does that anymore?

document.body.style.listStyleType = "Foobar"
document.body.style.listStyleType // "Foobar"
getComputedStyle(document.body).listStyleType // "Foobar"

[upsuper]

I think the behavior was changed in bug 1524328.

So I guess maybe we should say the computed value of list-style-type is unspecified... It would probably be the easiest...

[tabatkins]

I don't see why we should go with unspecified, if we can settle on an answer. That's only really something we do if we have multiple incompatible impls and no good way to find consensus between them.

As I said before, I don't think there's any particularly good reason to choose one way or the other, so we should do whatever is easiest. Looks like leaving the style around in computed style works best, as it lets Firefox delay having to resolve that style until later in the pipeline. I imagine Blink would benefit similarly (tho right now we don't implement @counter-style at all, so it's just an invalid declaration right now).

[css-meeting-bot]

The CSS Working Group just discussed Compute non-existent `list-style-type` <counter-style> to `decimal`?, and agreed to the following:

• RESOLVED: No change re computed value of list-style-type

The full IRC log of that discussion

<AmeliaBR> Topic: Compute non-existent `list-style-type` <counter-style> to `decimal`?
<AmeliaBR> github: https://github.com//issues/4210
<AmeliaBR> TabAtkins: fantasai discovered this when cleaning up lists spec. Issue is what should computed style be if you set the list-style-type to a custom ident that doesn't currently exist.
<AmeliaBR> …The used style is decimal. But computing that eagerly (as Firefox used to do) can be problematic, since @-rule could be added later.
<AmeliaBR> …I don't think any other browsers yet implement custom idents; they reject at parse time. I think best to follow current Firefox. Computed value is the custom ident.
<fantasai> s/cleaning up/doing archaeology for the/
<AmeliaBR> astearns: There are Firefox folks in thread pointing out that current behavior wasn't really intentional.
<AmeliaBR> TabAtkins: That's OK. It's still good behavior. Let's spec it properly.
<AmeliaBR> dbaron: If Emilio's OK with it, I'm OK with it.
<AmeliaBR> TabAtkins: He wrote the current Firefox behavior, so I hope so.
<AmeliaBR> astearns: And this will just be no-change to current spec.
<AmeliaBR> RESOLVED: No change re computed value of list-style-type