theme_item_list() came about from a developer's perspective: OL and UL markup is nearly structurally the same, so providing a single function with the type argument came about from a code efficiency standpoint. However, from a semantic HTML perspective, we do not use a singular 'list' element with an attribute to indicate whether it is ordered or unordered, we have two different elements. Semantically, OL and UL represent different information. Therefore, we should provide a separate templates for OL and UL, even though they contain nearly identical markup.

This idea came out of the principles in the Twig conversion is "Organization should be driven by meaning and semantics over technical convenience."

Related to this principle (and the principle of Visibility), names and locations of templates should be self-evident. Consider where a newcomer might expect to override markup. Example: Someone looking to override a menu isn't going to look for a item_list template, even if a menu is structurally identical. So we should not simply have a menu use an item list, nor should we simply include an item list from a menu template. Themers want to see markup in templates, not abstraction.

Comments

droplet’s picture

droplet CreditAttribution: droplet commented

and DL ?

c4rl’s picture

c4rl CreditAttribution: c4rl commented

Sure, right now that isn't accommodated by theme_item_list() so I suppose that's a feature request for a separate issue.

jenlampton’s picture

jenlampton
she / her
CreditAttribution: jenlampton commented
Title: Deprecate theme_item_list to use theme_ol and theme_ul » Update theme_item_list to call theme_ol or theme_ul

Updating this issue, since we decided that we'd still always call item_list, and item_list would be responsible for calling OL or UL, respectively, depending on the type. This facilitates having ULs within OLs, or vice versa.

Also, dl's are being added over here:
#54898: Add a description-list.html.twig template (ex. definition list)

steveoliver’s picture

steveoliver CreditAttribution: steveoliver commented

I think this is over-complicating item lists. We already have render arrays as items, which allow us to deal with nested lists of different types just fine. See theme_item_list()'s $items variable are either strings or render arrays now. I just don't see the point in splitting things out like this. A big -1 from me.

However, from a semantic HTML perspective, we do not use a singular 'list' element with an attribute to indicate whether it is ordered or unordered, we have two different elements.

If we had mixed ol/ol and dl together, this would be the argument I'd use for splitting such a function. But they're OL, and UL, exactly the same structurally except for one single letter. c'mon! :) Someone please close this.

c4rl’s picture

c4rl CreditAttribution: c4rl commented
Status: Active » Closed (won't fix)

Okay, here's my renewed perspective here.

Let's approach this from a theme component library perspective and not a semantic meaning perspective. The latter tends to push us toward creating theme callbacks for every granular piece of HTML.

In a discussion in IRC with psynaptic, jenlampton and steveoliver from a few weeks ago, we agreed that theme_item_list is useful (and a drupal convention) as something that has the following pattern:

* wrapper
* possible title
* list of stuff

Lots of things fall into this category, especially menus. Hopefully we'll be looking to clean-up a lot of the menu theme callbacks to leverage such a pattern.

Marking this as won't fix for now.

jenlampton’s picture

jenlampton
she / her
CreditAttribution: jenlampton commented

I think it might be worthwhile to revisit this later (D9?)

...since we can still achieve what we are after (in the comment above) by keeping theme_item_list and having it call either ol.html.twig or ul.html.twig as discussed at badcamp. Having separate templates for those things will make more sense for theme devs. When they are looking to override all OL markup they may not want to also override all UL markup, so combining them this way (for developer convenience) seems a bit silly. However, I agree that module devs might still want to call theme_item_list so I would like to keep it around, and also so we can switch freely between OL and UL for nested lists.

For now though, we convert. Bikeshed later :)

EvanLovely’s picture

EvanLovely CreditAttribution: EvanLovely commented

I, as a front end developer, like the idea of having separate twig template files for each list style type.