A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Suggestion - an ordered list nested attribute

rsendek
2017-10-10

Suggestion, add a nested attribute for the ol element to avoid all the CSS needed to create a hierarchical list. For example:

<ol type=“A”>
  <li>First main item
    <ol type=“1” nested>
        <li>First item first sub-topic</li>
        <li>First item second sub-topic</li>
    </ol>
  </li>
  <li>Second main item
    <ol type=“1” nested>
      <li>Second item first sub-topic</li>
      <li>Second item second sub-topic</li>
    </ol>
  </li>
</ol>

To render as:

A. First main item
  A.1 First item first sub-topic
  A.2 First item second sub-topic
B. Second main item
  B.1 Second item first sub-topic
  B.2 Second item second sub-topic

… and maybe also a delimiter attribute to specify what the separator character should be for nested lists, with the default being a “.” For example in the above:

<ol type=“1” nested delimiter=""> would generate A1, A2, etc.

<ol type=“1” nested delimiter="-"> would generate A-1, A-2, etc.

(The reason behind my comment about avoiding CSS is accessibility related. All my searching for ways to get a hierarchical ol list such as A.2.1 involved counters combined with using content: and my understanding (perhaps incorrect?) is that content added using CSS content: presents accessibility problems with screen readers.)

chaoaretasty
2017-10-10

I’m wondering if perhaps rather than introducing changes to lists the problem to be solved really is the CSS content accessibility issue.

It seems there are lots of times that CSS Content seems to solve an interesting use case but fails with accessibility considerations or requires awkward hacks to include and then hide text to be read.

As a starter for 10 either or both of the following attributes that would only apply to ::before and ::after elements

alt: <content> content to be presented as text to assistive technology (useful for eg icons)

assist: include|exclude defaults to exclude, tells assistive technology to consider the content as part of the document (useful for generated content such as lists)

simevidas
2017-10-15

I think, and interesting question is, do we want an HTML version of CSS counters? Would that be better, in terms of code maintainability and developer experience?

Regarding accessibility, I’m not sure your point is valid, since screen readers would have to add support for this HTML version, too, so why couldn’t they just add support for the CSS counters which are already in the standard and supported by browsers. What in the HTML version would entice screen readers to support it as opposed to CSS counters?

rsendek
2017-10-16

Hi @simevidas, thank you for the reply. I’m far from an expert on accessible screen readers, my initial thought about why screen readers may be more enticed to support HTML over CSS counters comes from what I’ve been reading about how screen readers work in the background, for example, https://www.levelaccess.com/csscontentproperty. My main concern, however, is not so much how to get an accessible hierarchical ordered list to work, but just a desire to do so and it crossed my mind that adding a simple HTML “nested” attribute might be an easy way to do it.