search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.12k stars 2.67k forks source link

Maybe change <ol>/<li> "ordinal value" to not be affected by CSS #6473

Open zcorpan opened 3 years ago

zcorpan commented 3 years ago

From https://github.com/whatwg/html/pull/4816#discussion_r587928706 by @domenic

Let me know if you have thoughts about ordinal value. Before, we spent effort defining ordinal value based on UA behavior to match the rendered output. Now that UA rendering is defined entirely in terms of CSS (and can, e.g., get out of sync with ordinal value via manually setting various CSS properties), it's not clear how to think of ordinal value's role. It gives a sense of what the semantics of the list are, but is it really OK for those semantics to drift visibly from the rendering? Which would we expect accessibility technology to use?

I replied:

Yeah ordinal value was indeed supposed to match browsers' rendering behavior, but now that mapping to CSS properties can do that, there's not so much of a need for ordinal value to do that. We could take the opportunity to completely decouple the semantic numbering from CSS. That CSS can be used to give a completely different visual compared to the semantics of the HTML is nothing new, and isn't an issue. On the contrary, having author CSS affect underlying semantics is against the spirit of CSS.

ATs generally take CSS into account (e.g. don't expose display: none, do expose generated content), but there are tricky cases (like <td style="display: block"> should still be exposed cells in a data table, while <div style="display: table"> should not be exposed as a data table). For counters, I think users would expect the numbers to match visual rendering.

Ordinal value is defined here:

https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value

So currently, any element with computed value display: list-item has an a list owner and an ordinal value.

The list owner is the nearest ancestor ul, ol, or menu, except if it doesn't produce a CSS box, in which case the nearest ancestor element that does produce a CSS box is the list owner. (This doesn't seem to match WebKit/Chromium when styling the ol with display: contents. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/9064 )

The ordinal value then checks if owner is an ol element, and if so look at the start and reversed attributes. If the list item is an li element, it looks at its value attribute. Then counts up or down as appropriate for all list items owned by owner.

To decouple this from CSS, the minimum change is to remove the check of "CSS box", and only consider li elements (instead of depending on CSS display). Since "ordinal value" is only used for defining rendering for non-CSS user agents, I think having it rely on CSS doesn't really make sense.

cc @whatwg/css

domenic commented 3 years ago

I think the plan you suggest of decoupling from CSS seems like a step in the right direction.

It might be good to also mention (perhaps as an additional example in the li section) that you can use CSS to make the rendering out of sync with the ordinal value, which is likely confusing for readers of your source and is best avoided.