- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 05 Mar 2026 16:40:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] option hover/active styles inside of disabled select listbox`, and agreed to the following:
* `RESOLVED: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons`
<details><summary>The full IRC log of that discussion</summary>
<jarhar> lwarlow: you can have a disabled select and still get hover/active styles on the options<br>
<jarhar> lwarlow: it turns out that option elements get their enabled state from themselves and from parent optgroups, but not from the select element itself<br>
<jarhar> lwarlow: one possible fix here is to add the enabled pseudo-class to the select inside of the styles and then it has to be an enabled select and an enabled option<br>
<astearns> ack masonf<br>
<jarhar> lwarlow: anne pointed out that this is wrong behavior to start with, and options should be disabled when sleect is disabled<br>
<jarhar> lwarlow: does seem to apply to auto appearance<br>
<jarhar> lwarlow: if you hold down on an option in a disabled listbox you get an active style as well<br>
<jarhar> dbaron: i looked into this a few days ago because joey wrote a patch to do this styling, and my impression is that if we can make it so options inherit disabled state from select that would be nice and it seems to make sense<br>
<jarhar> dbaron: the selectors you need to get this all correct combine with all of the weird specificity things you have<br>
<jarhar> dbaron: getting styles for disabled options correct if you have to look at the select disabledness too is a huge mess<br>
<jarhar> dbaron: maybe its not a huge mess if you rewrite all the styles for selects and options to have enabled/disabled, but if you dont do that then its bad, maybe theres a nicer way to write it<br>
<jarhar> dbaron: looking at what the stylesheet looks like today, its not a small change<br>
<jarhar> q+<br>
<masonf> q+<br>
<astearns> ack dbaron<br>
<keithamus> q+<br>
<astearns> ack jarhar<br>
<masonf> jarhar: I posted a few issues about this. About making options disabled when their select is disabled.<br>
<masonf> ...there are problems with the initial selection algorithm.<br>
<masonf> ...in order to not break that, Anne suggested changing the selectors for the options to incorporate the ancestor select being disabled.<br>
<masonf> ...but the other algorithms could still use the "old" disabled.<br>
<jarhar> annevk: yeah we have locally disabled and globally disabled or something<br>
<jarhar> masonf: and locally disabled is only used for this stylesheet?<br>
<jarhar> annevk: other way around. locally just looks at optgropu and option as it does today. then we create a new one that look at the ancestor select in addition, and that one we use for enabled<br>
<astearns> ack masonf<br>
<jarhar> masonf: that was going to be my question for doing that for auto, i assume we dont want to do something different for auto vs base<br>
<jarhar> annevk: what option you show is something we have to preserve<br>
<jarhar> masonf: id be concerned about changing any selector on select matches because theres so many<br>
<jarhar> q+<br>
<dbaron> +1 to trying the global/local thing and changing what :enabled/:disabled do on options<br>
<jarhar> lwarlow: this only applies to listboxes<br>
<jarhar> dbaron: isnt it true that you cant see the options if the select is disabled and its a dropdown?<br>
<jarhar> masonf: that makes me feel better<br>
<astearns> ack keithamus<br>
<jarhar> keithamus: you mentioned that options get their disbaled state from optgroups. im surprised. should we fix this for optgroups too?<br>
<jarhar> keithamus: we could resolve two at once. options should look at their optgroup or select, and optgroups should look at select<br>
<lwarlow> +1<br>
<masonf> +1<br>
<astearns> ack jarhar<br>
<masonf> jarhar: to Mason's point about compat, I imagine it could affect existing appearance:auto UA styles, but we can probably fix it<br>
<masonf> ...or we could add an internal pseudo class or something.<br>
<dbaron> (it also might be that the changes are an improvement!)<br>
<masonf> ...I don't remember how optgroup disabled works, but it probably doesn't do what we just discussed. But we could change it. SGTM<br>
<jarhar> astearns: i did notice the PRs at the end of the issue<br>
<jarhar> astearns: where is the spec with regards to this issue at the moment?<br>
<masonf> annevk: nothing landed yet<br>
<jarhar> proposed resolution: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons<br>
<lwarlow> +1<br>
<dbaron> +1<br>
<masonf> +1<br>
<keithamus> +1<br>
<jarhar> astearns: so these algoriths are not exposed to css?<br>
<jarhar> jarhar: correct<br>
<jarhar> astearns: im concerned that we would have two different answers to the question is this option disabled depending on how you approach getting your answer<br>
<jarhar> astearns: if you get it from the pseudo, sure its disabled<br>
<jarhar> astearns: but if you use this js mechanism to determine which option to be checked, then its not disabled<br>
<zcorpan> https://html.spec.whatwg.org/#selector-disabled<br>
<jarhar> astearns: having two answers seems like a code smell to me<br>
<jarhar> keithamus: the presence of the attribute is another thing<br>
<jarhar> keithamus: from developer perspective theres nuance here<br>
<jarhar> keithamus: in css if you use an attribute selector instead of a pseudo selector you get different answers<br>
<jarhar> annevk: is there a js api?<br>
<jarhar> lwarlow: it changes the algorithm of which option is selected by default, thats a js way you could detect the difference<br>
<RRSAgent> I have made the request to generate https://www.w3.org/2026/03/05-css-minutes.html fantasai<br>
<jarhar> annevk: there is a lot of callers for disabled<br>
<jarhar> masonf: the point of alans question is whether theres an easy js way to check this<br>
<jarhar> lwarlow: options have a disabled property<br>
<jarhar> annevk: that reflects the attribute<br>
<jarhar> masonf: that could be a source of confusion<br>
<jarhar> annevk: it already is because of optgroup<br>
<jarhar> zcorpan: im not sure we should change optgroup. the html spec doesnt have the disabled state for optgroup. theres the disabled attribute, but the disabled state doesnt apply to optgroup itself<br>
<jarhar> annevk: presumably the enabled pseudo class does apply right?<br>
<jarhar> zcorpan: yes, but it looks at the attribute instead of the state<br>
<jarhar> annevk: it doesnt have the disabled state because nothing else uses it<br>
<jarhar> keithamus: it seems confusing to me that you could query for enabled and youd get optgroup in a disabled select<br>
<jarhar> keithamus: and you wouldnt get any of the options<br>
<jarhar> zcorpan: i dont disagree, its strange. im not sure its worth fixing<br>
<jarhar> zcorpan: and risking web compat<br>
<jarhar> annevk: for optgroup theres less risk than option<br>
<jarhar> keithamus: its also whether the spec has a concept for disabled. certainly in firefox it has disabled. it has something that is disparate from select<br>
<jarhar> lwarlow: go with the proposed resolution and come back if theres compat issues?<br>
<jarhar> +1<br>
<masonf> q+<br>
<astearns> ack masonf<br>
<jarhar> lwarlow: if i get the compat concerns id balance them against wanting base appearance to have a sane set of behaviors. like keith mentioned, if you look for enabled descendants and you get optgroups thats pretty weird<br>
<jarhar> masonf: would it reduce the chance of breakage if you change disabled to reflect this as well? option.disabled would return true if its parent<br>
<jarhar> q+<br>
<jarhar> lwarlow: from my perspective thats riskier<br>
<jarhar> lwarlow: disabled is already a reflection than actually reflecting the internal state<br>
<dbaron> I agree with Luke that it sounds riskier.<br>
<jarhar> lwarlow: i would be fine, it makes sense<br>
<jarhar> astearns: we could make it separately<br>
<astearns> ack jarhar<br>
<dbaron> (I think it makes sense for .disabled to continue to be attribute reflection, so I don't think it makes sense...)<br>
<masonf> jarhar: I also don't like changing the disabled IDL, because it's writable. What happens if you set it to true on an inherited disabled option.<br>
<zcorpan> q+<br>
<masonf> ...it should stay.<br>
<masonf> masonf: that's a good point<br>
<astearns> ack Zakim<br>
<astearns> ack zcorpan<br>
<jarhar> zcorpan: if theres use case for reading the actual state like actually disabled<br>
<jarhar> q+<br>
<jarhar> zcorpan: disabled for real<br>
<masonf> .actuallyDisabledV2<br>
<lwarlow> Fwiw that would be fine you'd just do [ReflectSetter] and then a custom getter if we did want to do that<br>
<masonf> jarhar: {missed, sorry}<br>
<jarhar> keithamus: its also not the first thing we have to use matches to query something. for popover you have to use matches<br>
<jarhar> astearns: anne, are you convined that we can change optgroup?<br>
<jarhar> annevk: i think we should do both<br>
<jarhar> proposed resolution: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons<br>
<masonf> +1<br>
<lwarlow> +1<br>
<dbaron> +1<br>
<zcorpan> +1<br>
<jarhar> RESOLVED: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13383#issuecomment-4006350661 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 March 2026 16:40:28 UTC