type attribute is important to content of ordered lists

Brief description of the problem to solve

The value of an ordered list item is important to the meaning of the
content. A list ordered A - Z gives a different connotation and meaning from
a list ordered 1 - 26 or alpha to omega.

If web authors can't control the value of the list element without style
sheets, users accessing a page of un-styled content will get a different
connotation and meaning than accessing the same page with styles. Since the
default list type of an ordered list is uncontrollable by web authors, we
can't even be sure which connotation and meaning the user will get.

Also, lists are often ordered so that they can be referenced in surrounding
content. A countdown of top songs in 2009 might present the list and then
reference #9 in the countdown in a later paragraph. Since ordered values are
not interchangeably understandable (option E is not immediately recognizable
as option 5) we can't count on the default style of a user agent to present
the intended content without a way to specify what that intended content is.


Use case 1: Context sensitive lists

The counter used for the list is used to give context.

A bear for every letter, alphabetically

A. Angry bear
B. Brown bear
C. Crazy bear
D. Dangerous bear
E. Endangered bear
F. Fozzie bear

Ignoring the absurdity of the content (because even bad content deserves
decent markup), that list is not the same as the following

A bear for every letter, alphabetically

1. Angry bear
2. Brown bear
3. Crazy bear
4. Dangerous bear
5. Endangered bear
6. Fozzie bear

Use case 2: Nested ordered lists

Table of Contents, Indexes, Legal Documents, Educational and research
documents
Common expectation for nested ordered lists is that they have different
counters/markers. While the actual counter may not be relevant, it is
important that they be different. This helps users with cognitive
disabilities in addition to meeting user expectation.

1. Main point
: A. further detail
: B. possible solutions
:: i. solution 1
:: ii. solution 2
:: iii. solutions 3 - 9
: C. conclusion
2. Secondary point

This use case appears a lot in table of contents, indexes and other places
where it's important that users be able to reference information
consistently. 1.B.iii is not the same as 1.2.3. As we move more
traditionally printed documents online, losing fixed page numbers, it is
even more important that references stay the same whether the user has
styles on or not.


Potential Workarounds

To ensure the original meaning, we would have to include the
counters/markers in the content of the <li>. To avoid having duplicate
markers, we might make the list an unordered one.

   - A. Angry bear
   - B. Brown bear
   - C. Crazy bear
   - D. Dangerous bear
   - E. Endangered bear
   - F. Fozzie bear

Or make it an ordered list and turn off the list markers with styles. This
still gives somewhat confusing and potentially conflicting content to users
without styles.


   1. A. Angry bear
   2. B. Brown bear
   3. C. Crazy bear
   4. D. Dangerous bear
   5. E. Endangered bear
   6. F. Fozzie bear

Neither of these is really satisfactory because counters are difficult to
maintain manually and all browsers and user agents can do them very well
automatically. The first option has the added negative of presented an
ordered list as an unordered list.

Solution

The least painful solution for web authors would be able to specify type
(or possibly counter, or marker) for ordered lists. This isn't the same as
specifying type for an unordered list because bullets (unlike counters) have
no inherent meaning. Furthermore most user agents automatically change the
list type for un-styled unordered lists even though that is not the case for
ordered lists.

Stylesheets could still change the list type to anything at all but this
would allow web authors to dictate unstyled content.

Conclusion

I hope that you will take this comment as the plea it is intended to be.
Even if type is not added back to the ol attribute list, please provide
recommended HTML 5 solutions for the use cases above.

Sincerely,
Sunshine Lewis

Received on Monday, 12 January 2009 09:26:21 UTC