- From: <bugzilla@jessica.w3.org>
- Date: Mon, 08 Aug 2011 13:01:26 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13704
Summary: 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
Product: HTML WG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: HTML5 spec (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
public-html@w3.org
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
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 8 August 2011 13:01:27 UTC