This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #24644 +++ <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.
I just checked in Chrome and a <li> inside a <ol> without a content value attribute ends up always having li.value=0 , which agree to be confusing. Curious about thoughts on this.
In what sense is it not DOM accessible? The spec defines exactly what the value is for any <li>, no?
(In reply to Ian 'Hixie' Hickson from comment #2) > In what sense is it not DOM accessible? The spec defines exactly what the > value is for any <li>, no? The rendered value is not the same as the value presented to the developer in .value when no @value attribute is given. I confirmed this in Chrome and Firefox, see http://html5videoguide.net/test/test_ol.html . I believe the spec explains clearly what the browser needs to render as a number (described in the ol and li element sections). It also clearly states that the value IDL attribute must reflect the value of @value. If, however, no @value is present, then the value IDL attribute's value is not defined (FAICT) and ends up being 0, even when the browser renders an actual number. I assume that would be a problem in a JS lib that wants to make use of the rendered value.
li.value is just the IDL attribute reflecting the content attribute; if the content attribute is absent, then it returns 0. If a JS library wants to know the ordinal value of a list item, right now, they have to compute it (we don't have an API that exposes it). The information to compute it is all in the DOM. We could add an API to make this simpler, but what's the use case, exactly? It would save a half-dozen lines of code maybe, so unless it's something that is needed a lot, it doesn't seem worth it.
Please reopen if there's a compelling use case for a dedicated API for getting the ordinal value of a list item.
Copied from comments on bug #24644 per Silvia Pfeiffer at comment 4 on that bug: (In reply to Silvia Pfeiffer) > (In reply to Michael Cordover) > > > > 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();
For the cross-reference case, I think you really want a CSS solution, at least on the long term, because you want to be able to handle things like page numbers too.
If anything this will be done through a CSS API. *** This bug has been marked as a duplicate of bug 17632 ***