This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13704 - Re: The li element (the value attribute) What (other than compatibility with pre-html5 user agents) is the rationale for limiting the value attribute to an integer? The value attribute should be interpreted by user agents as a hint to the user agent about
Summary: Re: The li element (the value attribute) What (other than compatibility with ...
Status: RESOLVED LATER
Alias: None
Product: HTML.next
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
: 14198 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-08 13:01 UTC by contributor
Modified: 2012-09-14 12:17 UTC (History)
12 users (show)

See Also:


Attachments

Description contributor 2011-08-08 13:01:25 UTC
Specification: http://www.w3.org/TR/html5/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Re: The li element (the value attribute)

What (other than compatibility with pre-html5 user agents) is the rationale
for limiting the value attribute to an integer?

The value attribute should be interpreted by user agents as a hint to the user
agent about the human-readable (or human-usable) label for the entry. The
logical, not ordinal, order should be given by the source order; the ordinal
order should be given by the value attribute, not everything that you want to
put into order is ranked numerically, even if they are ordered numerically,
logically.

<p>1998 Medal Winners</p>
<ol>
<li value="gold">Alice</li>
<li value="silver">Bob</li>
<li value="bronze">Carol</li>
</ol>

User Agents could even then style this text in the colors given through CSS
selectors using the values. IDs would not be (directly) usable, because they
might not be able to be kept page-unique (say, a Hall of Fame page with many
years of results).

Interestingly, current reading of the value attribute does not forbid
collisions:

<p>World Ranking</p>
<ol>
<li value="1">Alice</li>
<li value="2">Bob</li>
<li value="4">Carol</li>
<li value="4">Dan</li>
<li value="5">Evan</li>
</ol>

(See http://en.wikipedia.org/wiki/Ranking for more information).

Is that intended? For human-readable labels, this seems acceptable. But if the
desire to have the ordinal values kept as integers is for ease of counting and
comparing, that seems disastrous!

If this is not intended, then unspecified value assignment must be more
complex, requires the entire list to be known prior to any assignments, and
must be re-calculated every time a value is added or removed, which creates
new problems. But it is the only true way to have them simultaneously human-
and user agent-usable.

Also, value="" would be more appropriate for entries that people want
unnumbered, and it would be inappropriate to limit it to one usage per list.

On than note, the current ordering rules can very easily result in collisions
without this being anticipated:

<ol>
<li>	      <!-- value=1 -->The first rule of Fight Club is: you do not talk
about Fight Club.</li>
<li value="0"><!-- value=0 -->In 2007, Premiere magazine selected this as the
27<sup>th</sup> greatest movie line of all time.</li>
<li>	      <!-- value=1 -->The second rule of Fight Club is: you <strong>no
not</strong> talk about Fight Club!</li>
</ol>

I realize that allowing arbitrary values in many ways effectively allows lists
to be constructed as if they were two-dimensional tables, whereas lists are
structurally supposed to be one-dimensional. For example, basic lists are not
appropriate for some things that use pure numbers:

<p>Error codes:</p>
<dl>
 <dt>0<dt>
 <dd>Exited normally</dd>
 <dt>1<dt>
 <dd>No parameters were given</dd>
 <dt>-1<dt>
 <dd>Unspecified error</dd>
</dl>

<p>Tennis Scoring</p>
<table>
<th>
<td>Points</td>
<td>Call</td>
</th>
<tr>
<td>0</td>
<td>Love</td>
</tr>
<tr>
<td>1</td>
<td>15</td>
<tr>
<td>2</td>
<td>30</td>
<tr>
<td>3</td>
<td>40</td>
<tr>
<td>4</td>
<td>Game</td>
</tr>
</table>

On the other hand, they linearize better than tables when they can be
simplified to two dimensions, providing accessibility benefits.


The problem I (was originally) trying to solve:

With legal documents, it's not possible to say: "Appendix AB, Division C,
Section 1, subsection a, part ⅰⅰⅰ"; you can't be sure how a user agent
will render the "numbers". Yes, logically, you know that Division numbered 3
is logically equivalent to one marked "C", but that's apparently not good
enough for a legal document. It's a loss of information; there is information
in the document that you simply can't represent with the language. You can
style it, even with an inline style, but you can't say what it *is*.

(Technically you can never be sure how anything will be rendered, but the
*information* of how to render it is there, which is what is important.)

Up until now, the solution has been to use ul instead of ol, and the put the
text information as part of the li text. This is also lossy, but only for the
User Agent (it can't know that it mustn't interfere with the order); not
typically for the human (behavior is consistent even though it's not
guaranteed). As you can see, there is no good solution under the current state
of things or the current proposal. (If I understand correctly, acknowledgement
of the fact that the value is structure, not content but also not
presentation, is the reason that the value attribute is no longer deprecated
in the first place).

Posted from: 203.59.75.251
User agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0
Comment 1 Tab Atkins Jr. 2011-08-08 16:43:02 UTC
Chopping your message down to the actual problem statement:

(In reply to comment #0)
> With legal documents, it's not possible to say: "Appendix AB, Division C,
> Section 1, subsection a, part ⅰⅰⅰ"; you can't be sure how a user agent
> will render the "numbers". Yes, logically, you know that Division numbered 3
> is logically equivalent to one marked "C", but that's apparently not good
> enough for a legal document. It's a loss of information; there is information
> in the document that you simply can't represent with the language. You can
> style it, even with an inline style, but you can't say what it *is*.

Yes, the fact that list numbering is actually a vital part of the content in legal documents is important.  The CSS Lists module is addressing this directly, so that you can put the list marker inline with the rest of the content, but still style it as a list marker.

Thus, nothing needs to happen here in HTML.
Comment 2 Aryeh Gregor 2011-08-08 17:23:30 UTC
(In reply to comment #0)
> What (other than compatibility with pre-html5 user agents) is the rationale
> for limiting the value attribute to an integer?

Compatibility might be a significant issue here.  Consider the following URL:

data:text/html,<!doctype html>
<script>alert(typeof document.createElement("li").value)</script>

Browsers all alert "number".  Changing a long-established IDL attribute from a number to a string could have significant compatibility impact.  For instance, right now if you have <li value=" 1">, the .value attribute in JavaScript will be 1, not " 1".  Likewise, currently if you have <li value="foo">, browsers will just ignore the value attribute, and it's almost certain there are pages relying on that.  So it's not a good idea to change at this point without compelling reason.

(In reply to comment #1)
> Yes, the fact that list numbering is actually a vital part of the content in
> legal documents is important.  The CSS Lists module is addressing this
> directly, so that you can put the list marker inline with the rest of the
> content, but still style it as a list marker.

What would the markup look like for this?  Overall it sounds like a better idea, because it has much better fallback for legacy UAs, and it allows markup of the item (bold, underline, etc.).
Comment 3 Tab Atkins Jr. 2011-08-08 17:32:03 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Yes, the fact that list numbering is actually a vital part of the content in
> > legal documents is important.  The CSS Lists module is addressing this
> > directly, so that you can put the list marker inline with the rest of the
> > content, but still style it as a list marker.
> 
> What would the markup look like for this?  Overall it sounds like a better
> idea, because it has much better fallback for legacy UAs, and it allows markup
> of the item (bold, underline, etc.).

<ol>
  <li><span class=marker>III</span>...</li>
  ...
</ol>
<style>
ol { list-style: none; }
.marker { position: marker; }
</style>
Comment 4 Marat Tanalin | tanalin.com 2011-09-18 18:53:32 UTC
*** Bug 14198 has been marked as a duplicate of this bug. ***
Comment 5 Ian 'Hixie' Hickson 2011-12-03 02:50:43 UTC
Please limit yourself to one issue per bug. :-)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: If you want more elaborate list items than just numbers, that's more a name-value pair list than a numeric ordered list. So generally I'd recommend using <dl> for that. For example, I'd definitely say <dl> is the right way to go for the gold/silver/bronze example.

As far as multiple list items with the same ordinal number goes, I agree that that's a bit odd. Henri, if you think that that is something we should require, please file a separate bug for it and I'll add it to the spec.
Comment 6 Henri Sivonen 2011-12-05 09:31:16 UTC
(In reply to comment #5)

> As far as multiple list items with the same ordinal number goes, I agree that
> that's a bit odd. Henri, if you think that that is something we should require,
> please file a separate bug for it and I'll add it to the spec.

I think it's not worthwhile to add a conformance requirement for that. It's not a big problem that needs solving and if someone has a use case that your imagination fails to foresee right now, a restriction would be annoying for them.