- Issue created by @ressa
- πΊπΈUnited States apmsooner
I don't think this is a bug but rather perhaps a preference. The thing is, we're using 'item_list' as the #theme function and it behaves differently depending on the theme. In Olivero, it doesn't output the wrapper
<div class="item-list">
as in your example where as with Claro, it does use the wrapper. I could I suppose not use the theme function and hardcode the html into a template but then might cause issues with modules like fences that and change or remove wrappers so I'm kinda on the fence with this one to be honest with you. - π©π°Denmark ressa Copenhagen
Thanks again for a fast response. I would just think, that if we were to approach this "semantically" -- that since "Tables" are using rows for fields, and each sub-field is a cell, that a "HTML List" should behave the same way, and treat each field as a field item (
<li>
) and maybe even treat the sub-field content as a list. This current state seems inconsistent to me ... But let's maybe see if anyone else has an opinion about this? - πΊπΈUnited States apmsooner
It actually is behaving the exact same as table in that regard. The
<li>
is being output just like the<tr>
in the sense that its wrapping the subfield which can technically have a wrapper around the entire subfield, around the value and label but all of these wrappers can be changed or removed in the 'styles' section of the individual subfield formatter settings. I think with the ability to manipulate the subfield wrappers, theres alot of flexibility to minimize html. I also think the use cases for this 'Html list' and the 'Inline' formatter types are probably not common and would defer to the 'Default' formatter as the general preference. We can document these as well to steer users based on example use cases. - π©π°Denmark ressa Copenhagen
Thanks for elaborating. Actually, it's all right how it is, I can use the current format.
I mostly created an issue, since it seemed to me like the levels were one off. And you're probably correct that it is performing as expected, and outputting the correct format, it just seems off by one level to me. Or maybe you don't agree?
But out of curiosity, I'd just like to make sure we are talking about the same thing, with a simplified example. Because as I see it,
tr
andli
are not on the same level, but they ought to be. Also, other users may also expect that the grouping element for "HTML list" is the field, not sub-fields?Say, you have a custom field "Journal" with three sub-fields, this is what you get with "Table" display (all
td
's,div
's etc. not included):<table> <tr>name | link | description</tr> item #1 <tr>name | link | description</tr> item #2 </table>
Currently with "HTML list":
<ol> <li>name</li> item #1 <li>link</li> item #1 <li>description</li> item #1 </ol> <ol> <li>name</li> item #2 <li>link</li> item #2 <li>description</li> item #2 </ol>
Structure I would expect:
<ol> <li>name | link | description</li> item #1 <li>name | link | description</li> item #2 </ol>
And yes, documentation is always nice -- having the steps outlined in the documentation how to achieve the structure in the last example would be great :)
- πΊπΈUnited States apmsooner
Thank you for the resilience as I see exactly what you mean now and would indeed consider this a bug. I will work on a solution to fix this indeed!
- π©π°Denmark ressa Copenhagen
Sounds good, thanks! I felt like we were talking past each other, and great we got to the bottom of this.
- πΊπΈUnited States apmsooner
Reworked the output. See if this works for you.
- π©π°Denmark ressa Copenhagen
Beautiful work @apmsooner, I no longer get the
li
wrappers at the sub-field level, but item/field-level, as expected:<ol> <li>name | link | description</li> item #1 <li>name | link | description</li> item #2 </ol>
Thank you so much :)
-
apmsooner β
committed 3588a932 on 3.1.x
Issue #3515307 by apmsooner, ressa: HTML list display operates on sub-...
-
apmsooner β
committed 3588a932 on 3.1.x