Request for value attribute with the <listitem> tag

[albert-github]

When looking at the tag <orderedlist> we have a.o. the attributes: numeration and startingnumber and these correspond with the attributes type and start of the HTML tag <ol>.
An item in HTML is given by means of the <li> tag and here we have the attribute value, the docbook equivalent of the HTML tag <li> tag is the <listitem> tag but here there is no value or similar tag present.

Request: would it be possible to add an attribute similar to the value attribute of the HTML <li> tag to the docbook <itemlist> tag?

Note: I'm not sure whether or not this is the right place for this request, in case this is not the case please point me to the right place.

[bobstayton]

Hi, This already exists.  The @OverRide attribute on a DocBook orderedlist/listitem element will cause the DocBook XSL stylesheet to output a @value attribute on the corresponding HTML <li> element. Bob Stayton ***@***.***

…

On 10/2/2021 2:19 AM, albert-github wrote: When looking at the tag |<orderedlist>| we have a.o. the attributes: |numeration| and |startingnumber| and these correspond with the attributes |type| and |start| of the HTML tag |<ol>|. An item in HTML is given by means of the |<li>| tag and here we have the attribute |value|, the docbook equivalent of the HTML tag |<li>| tag is the |<listitem>| tag but here there is no |value| or similar tag present. *Request*: would it be possible to add an attribute similar to the |value| attribute of the HTML |<li>| tag to the docbook |<itemlist>| tag? Note: I'm not sure whether or not this is the right place for this request, in case this is not the case please point me to the right place. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/docbook/docbook/issues/222>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6W3QLPO6NEA6VXESSESOLUE3FCHANCNFSM5FGF6J2A>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[albert-github]

When I have this in XMLMind this override does not show up in the XML editor part, though when converting the result to HTML or PDF I do see the right value. I think this might be a small omission in the XMLMind Docbook viewer.
Previously support from XMLMind told me that there was nor something like it...

Thanks for your help.

[albert-github]

After consultation with support of XMLMind some things were pointed out to me about the override specification

override (NMTOKEN)

override

Specifies the keyword for the type of mark that should be used on this item, instead of the mark that would be used by default

1. The override requires a NMTOKEN and can be anything, whilst the value attribute requires an integer
2. The override attribute is "for this item", this I interpret as just for 1 item, whilst with the value attribute it says: "The following list items will increment from that number"
3. The override speaks about "the type of mark", it is a bit unclear what this means

From these points I don't think the translation of the override attribute to a (HTML) li tag value attribute is correct.

[ndw]

You can put numbers in override, and you can use a custom schema to or Schematron rules to assert that only (non-negative) integer values are provided. Having numeration continue from that number would be a stylesheet issue, I think.

The reference to type of mark is a consequence of the fact that listitem is used in both ordered and itemized lists. And variable lists, come to that. I'll see if I can clarify that part in the next version of The Definitive Guide.

[albert-github]

I think indeed that some clarification would be in place.

Currently the definition of override states: ...for this item... (I made the word this bold), I think that this is in contradiction with your statement "Having numeration continue from that number would be a stylesheet issue, I think.

[ndw]

I'm moving this issue to the Definitive Guide repo because (I think) we've agreed it's a documentation issue.