Why does the disabled algorithm in option stop on certain elements

[dSalieri]

What is the issue with the HTML Standard?

Based on PR #11721, the disabled algorithm for option has received significant changes.

However, the algorithm may not be entirely clear:

The disabled attribute is a boolean attribute. An option element option is disabled if the following steps return true:

1. If option's disabled attribute is present, then return true.
2. For each ancestor of option's ancestors in reverse tree order:
   1. If ancestor is a select, hr, datalist, or option element, then return false.
   2. If ancestor is an optgroup element, then return true if ancestor's disabled attribute is present; otherwise false.
3. Return false.

Step 2.1 may end the ancestor search early, but why is the list of elements like this: select, hr, datalist, or option? For a web developer, I think this will not be obvious. Could you explain this list? It would also be a good idea to add a note to this step that would explain why these particular elements were chosen.

[zcorpan]

@josepharhar

[annevk]

I'm not sure this needs to be obvious as all of these conditions can only arrive when you're not following the content model restrictions.

[josepharhar]

Some more historical context on this is:

1. I/we chose not to support nested optgroups, at least for now, and not including descendants of nested optgroups follows that decision.
2. I/we wanted to unify some tree traversals in chromium which do things like collect option elements for select.options, collect "list items" to be rendered in native pickers, and calculate disabledness like this algorithm. Figuring out how to represent an option element inside another option or inside an hr element in a native picker is challenging, and excluding them seemed like a logical decision.

(I say I/we since its hard at this point to remember off the top of my head whether each detail was decided in code/spec I originally wrote or code review feedback or spec review feedback)