Html: 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.

[dstorey]

I'm fine with this, and semantically speaking (from the AT side at least), OL and UL have exactly the same accessibility API mappings. So the difference in meaning there is just from the generated content of the marker being read out, and would work out of the box in this case (you wouldn't lose the number or letter being read out when it is an UL)

This should also be pretty easy to implement in Edge I believe as menu/ul/ol inherit from the same base class.

[dstorey]

Presumably we'd want to move the type IDL attribute back out of the deprecated partial into the main interface too?

[dstorey]

The reason this doesn't work in Edge is that we only respect and reflect square, disc, and circle for type on UL/HTMLULListElement. If we were to stop this from being deprecated, should these three values still be deprecated? None of these have any semantics. I guess you could just reset it by removing the attribute or setting to empty string.

[domenic]

Fascinating. So, the type IDL attribute is currently specced to just do string reflection; it's not limited to known values or anything. But the user agent stylesheet has entries for ul[type] of none, disc, circle, and square.

We would have to keep those UA stylesheet rules, and then I guess add more. Let me whip up a quick PR so we can have a more concrete discussion of what's being proposed.

[domenic]

Also of note, Firefox supports start on ul, but not reversed...

[domenic]

I put up #4036 to give a concrete idea of the changes. In this thread, I'd like to discuss between three possible models:

• (A) Only support type=""
• (B) Support type="" and start="" (closest to Firefox; this is what #4036 currently specs)
• (C) Support type="", start="", and reversed="" (i.e. exactly the same as <ol>)

What are peoples' thoughts?

[tabatkins]

I think we should either do Ⓐ or Ⓒ. Ⓑ seems needlessly different; I'd be very surprised if it wasn't just an accident of implementation in Firefox.

[sideshowbarker]

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.

It doesn’t seem to me at least like this proposal would ever lead to the distinction ever going away, or even eroding significantly, because the elements would continue to have the separate meanings and separate utility they both have now — given that rendering of ol and ul without any attributes will remain just as now: ol without any attributes would be still be rendered as a 1-N numbered list, while a ul without any attributes would still be rendered as a bulleted list.

The proposal wouldn’t change that default behavior — instead developers/authors who want to opt into the different behavior for ul would need to add an additional attribute (or attributes) to get that.

[sideshowbarker]

I think we should either do Ⓐ or Ⓒ. Ⓑ seems needlessly different; I'd be very surprised if it wasn't just an accident of implementation in Firefox.

I agree.

[Yay295]

Since these are supposed to be unordered lists, I don't think it makes sense to have a start, or to be able to reverse them.

[annevk]

If you have list of use cases, an interruption, and then continue the list of use cases, it might make sense to have start. Harder to imagine a case for reversed though.

[prlbr]

If one uses an implicit start value of 1 or an explicit start value given by a start attribute and then relies on automatic numeration, one is relying on the _order_ of list items for the labelling to be correct. Why not simply use an _ordered_ list then?

If the list shall be an _unorded_ list where the order of items explicitly does not matter, but the label does, it would seem appropriate to give every <li> element a value so that the label would not change even if the order would. A start value is superfluous then.

[prlbr]

I am aware that we are talking about different levels here. The order could matter on a semantical level, on the level of the human language used to express the semantics, on the level of the HTML code for the labelling to be correct and maybe even on more levels. The order may matter on one level and not matter on another level at the same time. In the example given above the order does not matter on a semantical level, but it matters on the level of the human language in which the semantics are expressed. Whether it matters on the HTML level for the labelling to be correct depends on whether value attributes are used or not. Certainly we expect browsers not to change the order on their own even if it is an unordered list.

I think you’re overthinking this unnecessarily by distinguishing between one level and others, using <ul> because you feel the order does not matter on a semantical level but at the same time writing the list in a way where you rely on the order for automatic labelling to be correct or for the human language used in it to make sense. It’s certainly possible to do this, but the benefit seems little (at least it has not been demonstrated in this thread) and the potential for confusion is there.

[domenic]

it would seem appropriate to give every <li> element a value so that the label would not change even if the order would. A start value is superfluous then.

start="" is just a simpler, easier-to-maintain way of assigning values. They go together.

The order could matter on a semantical level, on the level of the human language used to express the semantics

This is the level encompassed by the definition of <ol> in the specification. I encourage you to read it in more detail, especially the examples, which are clarifying in this regard.

[prlbr]

The order could matter on a semantical level, on the level of the human language used to express the semantics

This is the level encompassed by the definition of <ol> in the specification.
I encourage you to read it in more detail, especially the examples, which are clarifying in this regard.

Then the sole example provided in favor of this issue does not support the proposal made in this issue.

The example in the spec for the <ul> element shows that the items could be reordered without changing the meaning. This is not possible in @tabatkins’s example. Again, note how item _b_ starts with word “Likewise”, referring to the item before it, hence the order matters. Swapping items _a_ and _b_ would make the word “Likewise” refer to the paragraph above the list, which would be wrong. So <ol> seems fine.

I can think of more convincing examples myself and is not my goal to prevent this change. My impression is just that some people involved in this thread may not have yet seen how subtle the <ol>/<ul> choice can be and that it can be a matter of taste. Until now there was a rather clear line between <ol>/<ul> imposed by the rendering. It may not be exactly the line that the current version of the spec intends, but it is what it has been for a long time since these elements existed. If the rendering distinction gets lifted, it will become more subtle. Often, it’s possible to argue in either direction as demonstrated on @tabatkins’s example, so <ul> and <ol> will become somewhat interchangeable in practice.

If you are aware of that and still think it’s good to make the change … fine, do it.

[tabatkins]

The items in my example can absolutely be re-ordered without changing their meaning in any way; my use of connectives to segue between the cases doesn't change that. In other words, the first item being first is not important; it could be second, third, or fourth without changing the meaning of the list at all. I would just have to slightly reword things to segue between the items in their new order, and change the labels in the following table to match up with the new labels.

"Can be reordered without changing their meaning" is not equal to "perfectly okay to randomly shuffle them in the DOM at a whim".

[travisleithead]

My 2c: From https://github.com/whatwg/html/issues/3979#issuecomment-421438676, prefer (A) or (B), since reversed doesn't seem semantically relevant to a <ul>

[chrisdavidmills]

Documentation need recorded on MDN content roadmap — https://trello.com/c/i9CpU8D4/131-html-ul-element