[css-lists] Should option/optgroup be able to set counters?

[tabatkins]

Should one be able to use 'counter-increment'/etc on <option>/<optgroup> (and other replaced-element form-control descendants)?

I think a strict reading of the spec says no - since <select> is replaced, its children don't generate CSS boxes, and things that don't generate CSS boxes can't interact with counters.

However, that text was written with display:none in mind, not necessarily replaced element descendants.

Here's an example: https://codepen.io/kizu/pen/PEJgpr. Apparently this works in Firefox, and pre-chromium Edge, but it does not work in WebKit or Chrome.

[fantasai]

Hmm, yeah. I think that should work. So CSS boxes or other representation in a rendering tree that's capable of holding CSS properties???

[kizu]

Small note: it works in Chrome with multiple attribute :) https://codepen.io/kizu/pen/EowqxX

(Also, a link to the chromium issue)

I'm not sure if I want to push this as something that should work everywhere, but there is no other way right now to use the value of selects in any other way in CSS, so…

Other case tests for which that I remember doing and which had differences in various browsers (but I don't think I created issues for this) — counter-increment inside inline SVG. I imagine there could be other interesting cases, including maybe shadow DOM and so on :D

[tabatkins]

Yeah, svg is also a replaced element, and its descendants don't generate CSS boxes either...

[css-meeting-bot]

The CSS Working Group just discussed Should option/optgroup be able to set counters?.

The full IRC log of that discussion

<dael> Topic: Should option/optgroup be able to set counters?
<dael> github: https://github.com//issues/4004
<dael> TabAtkins: Technically per CSS they are decendent of replaced so don't generate boxes. if continuing the current resolution that counters work on box tree there's no box to let them set or change counter. Howveer FF and previous Edge allow it. Chromium does not
<rachelandrew> I'll take a better look at issue 3846 and see if I have any thoughts from the authoring pov.
<dael> TabAtkins: There are use cases for this and a chromium issue to fix and allow setting of counters.
<dael> TabAtkins: Chrome devs discussing if they should, bbut no conclusion
<dael> TabAtkins: This may effect related issues like if SVG elements can set counters.
<dael> TabAtkins: We need to figure out exact terminology. fantasai prop is go one level up to also things that are like boxes, but not css boxes for layout terms and allow those to host counters.
<dael> TabAtkins: I'm fine with that. prop is allow optin/optgroup and other things that are like boxes outside the css model to effect counters
<dael> astearns: sgtm
<dael> AmeliaBR: Makes sense. I'd like a more explicit definition to what is and isn't like a box
<dael> TabAtkins: I prefer to define a new term other specs could hook and we define what that is for HTML and SVG. Other mockups could say they are that thing even though they don't generate css boxes
<dael> astearns: Other comments?
<TabAtkins> s/mockups/markup languages/
<dael> smfr: Sounds a little confusing for interactions with display:none. If you have optgroup that contributes to counters and you display:none it does it still contribute?
<dael> TabAtkins: I don't think display:none does anything to optin
<dael> smfr: If you have one of these how do you stop contributing to counters
<dael> TabAtkins: You don't set the counter. the display:none wasn't an intentional choice, it was legacy
<dael> smfr: Sounds like it will complicate code to determine what contributes to counters. May be odd interaction with other properties is what I'm saying
<dael> fantasai: I kinda disagree, I would expect diplay:none to have effect on counters. You're processing css properties and counters is one of them. I don't have strong opinion on this
<dael> TabAtkins: If someone with FF or older Edge can check that link I want to see if display has effect in other
<dael> smfr: [missed]
<futhark> Display:none affected in firefox
<smfr> webkit shows the ‘bar’ in the testcase
<futhark> that is, removed from select rendering
<dael> Rossen_: We do not support counters inside of display:none. Only time we did something more interesting is if gCS was called inside and we'd have something to calculate in the sub tree. I think we backed it out because it was fragile
<dael> fantasai: I htink prop is that anything that is a replaced element has nothing to do with counters or we have something represented in render tree and not display:none and they can have counters
<dael> astearns: Either way impl would need to change b/c we're not interop
<dael> TabAtkins: Yeah
<dael> TabAtkins: And we're buckwild with what styles can effect inside a select
<dael> fantasai: If we have an idea we want to do this how aout TabAtkins and I come up with specific wording that deals with the issues brought up here. We can bring it back and htink about how it effects different impl
<dael> astearns: Objections to that path?
<dael> ACTION TabAtkins and fantasai develop spec text for https://github.com//issues/4004
<trackbot> Created ACTION-881 - And fantasai develop spec text for https://github.com//issues/4004 [on Tab Atkins Jr. - due 2019-06-26].

[tabatkins]

Based on testing with http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7019, it looks like:

• Chrome & Safari allow counters to increment on SVG internals, but never on select internals.
• Firefox & old-Edge allow counters to increment on SVG internals, and on displayed option elements, but not on display:none options.

I think my preference right now is to say that SVG boxes can manipulate counters (those exist per spec, I'm pretty sure), but that other replaced-element internals cannot (unless otherwise defined).

[tabatkins]

Ugh, tho, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7022 shows that Chrome does increment counters on option inside of <select multiple>. That's terrible, this is terrible, the web is bad and a mistake.

[AmeliaBR]

So… I was thinking a little more about @kizu's comment about SVG, and wondered if it was specifically about non-rendered SVG elements that aren't technically display: none. And what about <use> copies of SVG elements?

I made a slight variation: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7025

Chrome and Firefox both increment for non-rendered SVG elements, unless they explicitly have display: none. Firefox gets completely lost with the <use> copy (the counter gets reset in the outer scope). Chrome just ignores it (not sure if that's normal for shadow DOM). Old Edge reboots the tab helplessly at this monstrosity of a test; not sure which part is so painful (based on an early version of the test, it had seemed to be incrementing for rendered, non-rendered, and shadow SVG content).

[MatsPalmgren]

I think a strict reading of the spec says no - since <select> is replaced, [...]

It's wrong to say that <select> is a replaced element, because it's not, it's a widget.
I would assume that <option>/<optgroup> are neither replaced elements, nor widgets, since they are not listed in those sections.

... its children don't generate CSS boxes

I tend to disagree with that. We certainly create boxes for <option>/<optgroup> internally in Gecko, albeit with severely restricted styling, and only for its text children etc. (Those limitations are completely artificial, btw. We could support pretty much all of CSS, and arbitrary child content, if the specs allowed it (in fact we did, but then we had to dumb it down to be compatible with other UAs/specs).)

and on displayed option elements, but not on display:none options.

All UAs suppress incrementing counters on all display: none elements. I don't see why <option>/<optgroup> should be special in this respect.

That's terrible, this is terrible, the web is bad and a mistake.

The web is terrible because the CSSWG put that in the spec :-p.

Seriously though, it's 2019 and I still can't do this:

<select>
  <option><img src="Pineapple.png">Pineapple
  <option><img src="Apple.png">Apple
  <option><img src="Lemon.png">Lemon
</select>

Sigh. Now that is truly terrible, because web authors routinely has to work around that in all sorts of terrible ways. It makes me sad because it would be so trivial to support if the specs just allowed it...

[MatsPalmgren]

BTW, this works perfectly fine in Gecko (meaning we create a grid container for it and render its child elements as grid items):

<style>
option {
  display:grid;
  grid-template-columns: 100px auto;
}
</style>
<option><x>a</x><x>a</x>

Chrome also creates a box for it, but not a grid container(?), although its devtools still reports that the computed value is grid-template-columns: 100px 1152px; as if it were a grid container. Hmm.
Safari doesn't create a box at all.

[oliverdunk]

@MatsPalmgren Here's the layout tree in Chrome:

LayoutNGBlockFlow {HTML} at (0,0) size 800x600
    LayoutNGBlockFlow {BODY} at (8,8) size 784x584
      LayoutGrid {OPTION} at (0,0) size 784x20.19
        LayoutNGBlockFlow (anonymous) at (2,0) size 100x19.19
          LayoutText {#text} at (0,0) size 15x18
            text run at (0,0) width 15: "aa"

It looks like Chrome ignores any elements inside of the option element. I saw the same behaviour with divs, for example.

[oliverdunk]

What are the counter arguments to letting an option element be styled? It feels like if as @MatsPalmgren suggested, we allow images in them (which at a high level seems desirable), all CSS (and therefore counters) should work.

whatwg/html/issues/3596 seems relevant here.

[kizu]

Thinking about this, having counters on selects with multiple is probably the most “real” use case they could have — to show stuff like “N out of M options selected”. Counters on options of regular selects still could have viable use-cases (mostly for similar counting/validation help purposes), but as this is not something that was not available at all browsers, developers didn't research this enough.

Talking about if something like that should be present at all, I would confirm that, ideally, options should generate boxes, and developers should have more control over what should be inside the options and how they should be displayed (also: how the option groups should be displayed and styled, but thats completely another issue). Actually, my experiments came from trying to find a way to at least display some extra images (flags for a country input, to be precise) for a selected value. Allowing images inside options would mean so much, and if select styling would be enhanced, I could live without counters on them (but then, if they would generate boxes, they would need to have counters, so… win/win).