Allow type attribute on <ul>

[fantasai]

<ol> represents an “ordered list”., whereas <ul> represents an unordered list. But frequently, one wants an unordered list with labels (1, 2, 3, or A, B, C). The options here are to either use a <ol> anyway (which falsely marks the list as ordered), or to use <ul> with CSS (which means the referencing system is CSS-dependent).

It would be great if HTML would allow the type attribute on <ul> to solve this problem.

Note: Firefox already implements the requisite functionality, and Chrome already handles it for <li> inside <ul> (just not for <ul> itself). Testcase

[Yay295]

I don't really understand this use case. You want an unordered list, that has ordered labels?

edit: Something like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl?

[tabatkins]

Use-case: in https://drafts.csswg.org/css-sizing-3/#percentage-sizing, we have an unordered list of cases. We want to refer to them easily in the table below the list, but the only reliable way to get labels on the list items (rather than identical bullets) is to use an <ol type=a>. This pattern is extremely common in both formal and informal documents; any time anyone wants to refer to items in a list more easily/concisely than "the third bullet point" (which doesn't scale to more than 6-7 bullet points, as the reader then has to manually count down the list).

[domenic]

I have to say, I was skeptical, but that use case is rather convincing. At this point I'm in favor of making this work.

In particular I'd be interested in adding this sort of example to the spec, and spelling out the difference between a labeled list and an ordered list, and how type="" only implies labeling.

Any thoughts from others on a semantics/document conformance perspective, before we start asking implementers whether they're willing to change? Safari and Edge behave like Chrome right now, so this would be a change for 3/4.

[Yay295]

And why doesn't list-style-type: lower-latin work? You say that makes it CSS dependent, but why is that a problem? Doesn't your proposed solution make it "HTML dependent"? Why is CSS dependence undesirable?

edit: So after a bit more thinking I'm guessing the use case is for people who disable stylesheets.

[prlbr]

I predict that the distinction between ol/ul will become meaningless in practice, if this change is made. In a few years we will have a situation where they are basically used a synonyms.

Sometimes it's clear which semantics fit better. For example, the order of instructions in a cooking book does usually matter, whereas the order of things in a buying list usually does not matter … or maybe it does in the latter case, if they were deliberately ordered as they are to be found in a well-known shop, which makes fetching them quicker then?

Often the choice between ol/ul is subtle and could be a matter of taste. @tabatkins gave an example where the order of items does not matter, spec-wise. On the other hand that example is written in a way that does not allow a spimple reordering of items, because the second item starts with the word “likewise”, referring to the first item. Swapping these items would result in confusion. So is ol a good choice there after all?

People do care about meaning, but they often express it in and derive it from looks (for instance, the text editor here at github I’m using right now offers buttons to “Add bold text“ and “Add italic text“, but translates this to HTML <strong> and <em> elements). If two semantically related mark-up options also look the same, they will probably used interchangably.

(I neither mean to support nor oppose the proposal with these musings.)

[sideshowbarker]

Use-case: in https://drafts.csswg.org/css-sizing-3/#percentage-sizing, we have an unordered list of cases. We want to refer to them easily in the table below the list, but the only reliable way to get labels on the list items (rather than identical bullets) is to use an <ol type=a>. This pattern is extremely common in both formal and informal documents; any time anyone wants to refer to items in a list more easily/concisely than "the third bullet point" (which doesn't scale to more than 6-7 bullet points, as the reader then has to manually count down the list).

I have to say, I was skeptical, but that use case is rather convincing.

I agree.

Any thoughts from others on a semantics/document conformance perspective

I don’t think there’s any issue with semantics as long as the semantics are specced properly; that is:

spelling out the difference between a labeled list and an ordered list, and how type="" only implies labeling

Specifically, I don’t think it would be an abuse or distortion of the semantics of ul.

And there’s no problem with supporting it in the HTML checker.

I think it would be a good win for developers if the spec allowed this and defined how UAs must handle it (and support for it were implemented interoperably in UAs).

[tabatkins]

Note that we already have implementor interest, in the form of Firefox having implemented it for a long time. ^_^

[domenic]

Per https://whatwg.org/working-mode, multiple implementer interest is needed

[domenic]

@tkent-google @cdumez @dstorey any thoughts on this feature? Summary:

• Allow type="" to work on <ul>, not just <ol>, in particular with regard to rendering behavior.
• This already is the case in Firefox, so we have a 3 vs. 1 interop issue at the moment anyway.
• The use case is for "labeled but not ordered" lists; an example was given upthread.