This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(Apologies if this should have been filed against HTML.next) <li> children of <ol> (and less significantly <ul>) may have a list marker rendered next to them. For children of <ol> the value of this marker can be set explicitly with the value attribute. When the value is not set (including because it is not a child of <ol>) the user agent will automatically determine and render a marker, if applicable in accordance with the CSS rules applied to the element. The automatically determined (or rendered) value is not DOM-accessible. I propose that the DOM interface for li elements be expanded to include a new property: readonly attribute Node? renderedValue; This would return an Element or Text node, being the automatically calculated value for that li (or null if no list marker is rendered). In the alternative, this could be only available for li children of ol elements: readonly attribute long ordinalValue; being the ordinal value <http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#ordinal-value> of the li element. My suggestion is that the value is readonly to simplify implementation. The most obvious use case for this property is cross-referencing in documents, for example where paragraphs are numbered.
really interesting! I think that the "best way" for you to get the number of a LI is by verifying which nth-child it is from its parent, although it is not very trustful once the list may start in a different value. Also, in case there is any (not valid) text node inside the ol, not inside any li, it would interfere with this number! I would even propose an increment to that. The LI elements could offer on its API two properties, one for the actual index of the list(1, 2, 3, ... n) and other to the rendered value(1, 2, 3...or I, II, III, IV, or A, B, C...etc).
(In reply to Michael Cordover from comment #0) > > The most obvious use case for this property is cross-referencing in > documents, for example where paragraphs are numbered. Michael, could you explain your use case in a bit more detail? In the discussion in bug 24645 the suggestion was to compute the ordinal value of a list item from all the information available in the DOM. It's only a few lines of code (basically: ol.childNodes and then count only those with tagName="LI"). Why would that not be sufficient for you?
(In reply to Silvia Pfeiffer from comment #2) > (In reply to Michael Cordover from comment #0) > > > > The most obvious use case for this property is cross-referencing in > > documents, for example where paragraphs are numbered. > > Michael, could you explain your use case in a bit more detail? > > In the discussion in bug 24645 the suggestion was to compute the ordinal > value of a list item from all the information available in the DOM. It's > only a few lines of code (basically: ol.childNodes and then count only those > with tagName="LI"). Why would that not be sufficient for you? There are a couple of issues I have with this. One is that it's not quite that simple: you need to also take into account ol.start at least, plus ol.reversed and any other innovations in future specs. To get the rendered value you also have to consider the style. I also don't think it's the responsibility of the content author to replicate work already done by the UA. Most importantly though the information presented by the UA has semantic value. That's the basis for the distinction between ul and ol. I think that semantic information should be DOM-accessible as a matter of principle. In terms of use case, I'm thinking about cross-referencing in documents e.g. "refer to clause X" scenarios. For example: HTML: <ol> <li>A legal clause</li> <li id="c">Another legal clause about copyright</li> <li>Except in accordance with <a class="xref" href="#c">the copyright clause</a>...</li> </ol> JS: var x = document.getElementsByClassName("xref")[0]; x.textContent = "clause " + document.getElementById(x.href.substring(1)).ordinalValue.toString();
Michael, would you mind getting involved in the discussion in bug 24645 and copy your reply there? I think your use case is compelling enough to reopen the bug and have another go at the discussion. Thanks!
HTML5.1 Bugzilla Bug Triage: Incubation needed This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3]. [1] https://github.com/w3c/html#contributing-to-this-repository [2] https://www.w3.org/community/wicg/ [3] https://wicg.github.io/admin/intent-to-migrate.html