The design of <dl> tag is possibly flawed. Here are two points that describe the possible flaw:
dl designed to be independent of ul and ol implies that dl is neither unordered nor ordered.
The spec for dl does not provide a method for defining whether a dl is unordered/ordered. Even if it does, the purpose of the method would overlap with the purposes of ul and ol.
Wouldn’t it make more sense that <dt> and <dd> tags be in ul and ol elements instead so that when we want to write an unordered and an ordered description lists, we would write the following two pieces of code?
While the idea itself probably makes some sense, the only difference between ordered and unordered lists in practice is that ordered-list items have indices instead of bullets in visual browsers. Both UL and OL in fact have a certain order — document order.
Hmm. I have always assumed that the order of <dl>s are ambiguous because they don’t require a visual representation of the order, unlike <ul>s and <ol>s. What does the developer gain from having <dt>s and <dd>s be declared “unordered” or “ordered” in markup?
Can you give a use-case of when the order of a definition list matters? AFAIK, definition lists are built as key-value pairs where the order would never matter. If the developer cares that much about the order of a definition list, they can always just insert the list items in the desired order directly in the HTML markup. AT technology will read it in whatever order the elements appear in the DOM.
<ul> and <ol> are necessary to visually show to the user either bullet points (for <ul>) and numbers (for <ol>) to the left of their contents. <dl> does not have that–I believe this is exactly what @MT was illustrating when he said the following:
I’ll leave this up to the rest of the group to discuss this further with you but you still haven’t yet described a large enough benefit of why <dl> isn’t sufficient for its uses or “flawed”, as you say.
And the point to show either bullets or numbers to users is to let users know whether the order matters or not, right? <dl> does not have that so there is no method to define whether a <dl> is unordered/ordered, and that has been described in my original post.
Those points have been described in my original post.
Document order is how elements (and nodes in general) are ordered relative to each other in the document/DOM.
Item order may be not important, but it always exists because HTML document is not a database, and characters and elements it consists of always have certain order.
You are probably right that there is some semantics in whether exact item order in a specific list is important, I just doubt such semantics is essential in HTML:
AT naturally read document contents in document order, while lists in HTML documents are unlikely used as a source of data for conventional databases where having or not having specific item order could really matter.
They were introduced when HTML was first invented. We are not designing a new language from scratch here. Introducing a new element has a cost that needs to be weighed against the benefit. “Wouldn’t it make sense…”, on its own, is not enough to make a change.
Those lists also have distinct default rendering, numbers vs. bullets. dl doesn’t have those currently and I am not aware of any examples where CSS is used to add bullets or numbers to dl, which suggests to me that it is not a desired rendering.
@zcorpan This thread does not suggest any new element. And as described before, the design of dl currently made users unable to know whether a description list is unordered/ordered so it isn’t just a thing of “Wouldn’t it make sense…”
IMHO, when a rendering is beneficial to users, it is a desired rendering. Making <dt> and <dd> inside ul and ol allows bullets and numbers to inform users whether a description list is unordered/ordered. In that case, bullets and numbers would be desired renderings.
Can you provide an actual case where this is beneficial? Typically, ol and ul are targeting a different use-case than dl. So far it is just “feeling” it could be better but no real case is provided. Very few people want to put effort into changing such long-standing things on the technical side unless there is a real benefit somewhere. So far, no benefit is provided simply suggested. It needs to be remembered that eventually even if the spec does change based on a suggestion we still need to encourage browser vendors to implement the change. None will without a specific set of cases where the change provides a benefit that is otherwise not achievable (or very difficult) with the existing landscape.