The patch to commit is: #891112-57: Replace theme_item_list()'s 'data' items with render elements
- theme_item_list() uses a completely custom, awkward syntax/structure for all items that 1) need list item attributes, and/or 2) nested lists.
- Harmonize theme_item_list() with current core practices.
- Change theme_item_list() support 1) a simple string value or 2) a render array as item.
- To specify custom list item attributes, use the custom
#wrapper_attributesproperty, which has been discussed in a range of other issues in the past already.
- To avoid having to specify the full theme/render properties all over again for nested lists, implement a theme variable preprocess function that takes over the properties of a parent list to nested child lists.
The documentation for theme_item_list() shows that the 'data' element of each item passed into the items variable must be a string. Considering the push to make D7 chock full of render elements, its a bit of a WTF that the most commonly used theme hook (theme_item_list) to create a generic-ish container (unordered list of items) will not accept a render element in its data element.
I know its extremly late in the d7 cycle, but since a plain string is also a valid render element, even if we make this change, it won't break any modules that have been ported; the plain strings will continue to work as usual. But we'll have added the ability to include complex-markup-as-render-element with this theme hook, instead of the considered-bad complex-markup-as-plain-string that we are currently forced to endure by theme_item_list()'s current implementation.
I'll leave it up for discussion about whether this is too late for d7, or if, because of the inherit backwards-compatibility of the patch that this is acceptable to fix a WTF for an often-used theme function.