Make option and optgroup actually disabled inside disabled select

[josepharhar]

This PR makes option:disabled and optgroup:disabled match when either are inside disabled select elements, without changing the behavior of other algorithms like the selectedness setting algorithm when options are inside disabled selects.

• At least two implementers are interested (and none opposed):
  • Chrome
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.git.corp.google.com/c/chromium/src/+/7624129
• Implementation bugs are filed:
  • Chromium:https://issues.chromium.org/issues/490082172
  • Gecko: …
  • WebKit: …
• Corresponding HTML AAM & ARIA in HTML issues & PRs: Not needed
• MDN issue is filed: not needed
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/semantics-other.html ( diff )

[lukewarlow]

Lgtm

[annevk]

I think some more blame research is required here. We check disabled state of ancestor optgroup but not select. Why is that? Perhaps an oversight?

[josepharhar]

I think some more blame research is required here. We check disabled state of ancestor optgroup but not select. Why is that? Perhaps an oversight?

This was added in chromium and webkit here, which references the spec:

• https://chromium.googlesource.com/chromium/src/+/7d888d6ff7f3da638167dd57c0bd00db73afadc7
• https://bugs.webkit.org/show_bug.cgi?id=92833

I blamed the spec, and I got to 80aba5d which didn't seem to cite any reasons.

I'll see what tests fail if I make options become disabled when they are in a disabled select, but I anticipate that more changes would be needed to make this work, if we can at all.

[lukewarlow]

When did listbox get added to the spec? One thought I had was perhaps option doesn't look at select because the assumption was you won't see the picker when select is disabled.

I can't see this being a behaviour people are relying on?

[annevk]

I think list boxes are about as old as the select element itself. It at least had size and multiple since its introduction to HTML in 3.2. https://www.w3.org/TR/html401/interact/forms.html#disabled suggests that the intent of <select disabled> was that it would disable the subtree. I strongly suspect this is an oversight.

[josepharhar]

I took a closer look at implementing behavior where options become disabled inside disabled selects. Consider the following:

<select disabled>
  <option disabled>disabled option</option>
  <optgroup disabled label=optgroup>
    <option>option in disabled optgroup</option>
  </optgroup>
  <option>option in disabled select</option>
</select>

In current behavior, at least in chromium, "option in disabled select" gets selected by default. It could be fairly complicated to preserve this behavior, but we could try. I'd be afraid of breaking sites by changing how this currently works. Does this still seem preferrable to making the change in this PR?

[annevk]

Thanks for looking into it! My inclination would be to distinguish explicitly disabled and disabled and make the pseudo-class use the latter concept. (There might even be precedent for this.)

[josepharhar]

We resolved on this here, which I think matches Anne's last comment: w3c/csswg-drafts#13383 (comment)

[josepharhar]

Ok, I replaced the UA stylesheet changes with a change to "actually disabled" which should make option:disabled match inside a disabled select and should otherwise not change how the option's disabled state is used in other algorithms.

[lukewarlow]

The tests checkbox is checked but it links to a chrome cl and it's abandoned?

Also need to update the top of the PR description for the committ message to be right.

[annevk]

Should we fix this at the same time?

[josepharhar]

Done

[annevk]

Do we need the same definition for ancestor select that we have for option? We probably want to exclude the same set of intermediate elements, no?