Re: [csswg-drafts] [css-lists] Should option/optgroup be able to set counters? (#4004)

The CSS Working Group just discussed `Should option/optgroup be able to set counters?`, and agreed to the following:

* `RESOLVED: leave undefined for now and add a note explaining why`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Should option/optgroup be able to set counters?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4004#issuecomment-506906199<br>
&lt;dael> astearns: We left it at fantasai and TabAtkins suggesting we punt on replaced elements for now<br>
&lt;TabAtkins> Yes<br>
&lt;dael> fantasai: Dug into issue a little. Seems like figuring out what's going on for form controls is a mess. To get spec to reflect reality we figured fine for spec to leave it undefined.<br>
&lt;dael> fantasai: Want to check with WG if really want to dig into the issue<br>
&lt;dael> heycam: I think need to do at some point, but okay undefining it for now. At some point need to consider alt presentations of certain elements like select and what it means to allow UAs to have CSS based and nonCSS based preso.<br>
&lt;dael> heycam: Make sure counters and anything else makes sense in presence of presenting these in different ways<br>
&lt;dael> astearns: Given we have 1.5 impl that reset counters and option/optgroup are the most list-like would it make sense to def those and leave reset?<br>
&lt;dael> fantasai: Could. Want to move to a world with more styling rather than less. Makes sense elements with some visual rep can handle counters. No reason they can't manipulate counters. I don't feel strongly this is important to solve right now. Happy to leave undefined and let impl merge toward more things being countable<br>
&lt;dael> AmeliaBR: Specific behavior for option/optgroup the inconsistancies with counters are related to other styling inconsistancies. Getting a proper model for explaining how option/optgroup and selects in general work for display trees wuld be useful. Special rules for counters without whole model might make more complicated<br>
&lt;dael> heycam: Counters are special because can effect thigns without. Sep from general stylability in that way. Seems we could solve counter issue independent in terms of should be obserable outside the select so counters increment<br>
&lt;dael> heycam: Am I right that if counters increment inside you can see it outside?<br>
&lt;dael> fantasai: Yeah<br>
&lt;dael> astearns: IN some browsers it has effect, in others it does not<br>
&lt;dael> heycam: Agree with fantasai might not be super important. Does seem like a discussion we can have about if it's acceptable to make UAs that don't have CSS based and therefore boxes should do something else to inc. counters<br>
&lt;dael> fantasai: I think cases where this shows up is test cases. I can imaging using counters within select box but not ref outside. Given not sure how this impacts impl arch. I'm leaning to undefined and let them converge. I don't think we should spend effort getting impl to align. If there's a use case later we can add it. That's why I advocate leave undefined. What impl doing is prob fine for now<br>
&lt;dael> astearns: What is resolve to undefine at this level and add a note we're doing this b/c no interop and don't have a use case guiding to the right direction<br>
&lt;dael> fantasai: More no use case to spend engineering effort to align. Right direction for authors is honors counters. That's what they would expect and it's reasonable. Don't think it matters in this strange case<br>
&lt;dael> astearns: Just having anote why we're leaving undef.<br>
&lt;dael> fantasai: I can have a note that there's no interop and we don't think it's important to get interop so we're leaving it undefined<br>
&lt;dael> astearns: Any further arguments to not leave undefined<br>
&lt;dael> tantek: Can we live with this being a compat issue where we have to compat with whatever Chrome does?<br>
&lt;dael> astearns: Are you aware of any Gecko bugs currently?<br>
&lt;dael> tantek: I don't. I believe that us leaving undef in the long term means it'll end up being a compat issue with Chrome. If we can live with what Chrome does eventually spec may have to spec.<br>
&lt;dael> AmeliaBR: Given it's lack of feature in dominant browser I don't know if that argument is that strong. I don't think people will rely on counters not working in optiongroups. There might be a zombie CSS issue if it ever works but that's not major web compat arg.<br>
&lt;dael> TabAtkins: Okay<br>
&lt;dael> s/tab/tantek<br>
&lt;dael> astearns: Proposal is leave undefined for now and add a note explaining why<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: leave undefined for now and add a note explaining why<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4004#issuecomment-508287146 using your GitHub account

Received on Wednesday, 3 July 2019 23:28:48 UTC