- From: <bugzilla@jessica.w3.org>
- Date: Sun, 23 Oct 2011 14:03:43 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14548
Summary: Grouping Content: algorithm for incrementing value
(OL->LI @value) does not match any current user agent
Product: HTML WG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: HTML5 spec (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: theimp@iinet.net.au
QAContact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
public-html@w3.org
Created attachment 1036
--> http://www.w3.org/Bugs/Public/attachment.cgi?id=1036
Initial post in HTML markup due to heavy pseudo-markup and tables
When I went to investigate this, I tested how a lot of user agents currently
handle their numbering rules, and none of them match the current spec. (and
very few come close to the spec. or each other, and no major ones match each
other exactly).
Results:
* Lynx comes the closest to what the HTML5 spec. currently says, but is the
only browser that performs incorrectly on the (invalid) initial positive sign
symbol (U+002B PLUS SIGN).
* Only Opera and Lynx support negative numbers at all (except through unhandled
overflows).
* IE and Webkit do not support the value 0.
* An empty string is treated according to the spec. by Gecko, Webkit, Presto
and Lynx. It always returns 0 for w3m and Dillo. It always returns 1 for IE.
* There's a three-way split between how invalid values that begin with valid
characters, are currently interpreted. Gecko ignores the entire value, treating
it as if no value was specified (incrementing the previous value by 1). IE
ignores the whole value but returns an absolute value of 1. The rest, per the
spec., read all valid characters up to the first invalid character, and use
that.
* As a special case of the above, all browsers will use a value that is
invalid, due to containing a whitespace character as the first invalid
character (that is, contains valid digits and then one or more whitespace
characters and then any other non-whitespace characters), using the characters
up to the first invalid character as above.
* As a special exception of the above, Gecko, if the first invalid character is
a period (U+002E FULL STOP) but there are valid numeric digit characters after
it, will use those digits as a number, ignoring the period.
* Presto, w3m and Dillo will treat invalid values as a 0. IE will treat invalid
values as a 1. All others treat invalid values as an increment of the previous
value.
Sample Ordered List Value Attributes
Markup HTML5* IE Gecko Webkit Presto Lynx w3m Dillo
<li ></li> 1 1 1 1 1 1 1 1
<li value="0" ></li> 0 2 0 2 0 0 0 0
<li value="1" ></li> 1 1 1 1 1 1 1 1
<li value="3a" ></li> 3 1 3 3 3 3 3 3
<li value="3b" ></li> 3 1 4 3 3 3 3 3
<li value="2 "></li> 2 2 2 2 2 2 2 2
<li value="2 1"></li> 2 2 2 2 2 2 2 2
<li value="2.1"></li> 2 2 2 2 2 2 2 2
<li value=".2" ></li> 3 3 2 3 0 3 0 0
<li value="-3" ></li> -3 3 0 4 -3 -3 0 0
<li value="+3" ></li> 3 3 3 3 3 -2 3 3
<li value="-3" ></li> -3 4 0 4 -3 -3 0 0
<li value="" ></li> -2 1 1 5 0 -2 0 0
<li ></li> -1 2 2 6 1 -1 1 1
<li value="" ></li> 0 1 3 7 0 0 0 0
<li value="4" ></li> 4 4 4 4 4 4 4 4
<li value="5" ></li> 5 5 5 5 5 5 5 5
<li ></li> 6 6 6 6 6 6 6 6
<li value="c" ></li> 7 1 7 7 0 7 0 0
*The current HTML5 algorithm
Details:
IE
* By default, the value is an automatic increment of the previous number
* Values greater than 2147483647 return 2147483647
* Values less than 0 return an automatic increment of the previous number
* An empty string returns 1
* A string not beginning with any numeric characters (including U+002B PLUS
SIGN, U+002D HYPHEN-MINUS) returns 1
* Note: automatic increments of the previous value are 1 if there is no
previous value, but overflow to -2147483648 if the previous value was
2147483647
Webkit
* By default, the value is an automatic increment of the previous number
* Values greater than 2147483647 return an automatic increment of the previous
number
* Values less than 0 return an automatic increment of the previous number
* An empty string returns an automatic increment of the previous number
* A string not beginning with any numeric characters (including U+002B PLUS
SIGN, U+002D HYPHEN-MINUS) returns an automatic increment of the previous
number
* Note: automatic increments of the previous value are 1 if there is no
previous value, but overflow to -2147483648 if the previous value was
2147483647
Gecko
* By default, the value is an automatic increment of the previous number
* Values greater than 2147483647 return an automatic increment of the previous
number
* Values less than 0 return 0, unless it's also less than -2147483647, in which
case it returns an automatic increment of the previous number
* An empty string returns an automatic increment of the previous number
* A string not beginning with any numeric characters (including U+002B PLUS
SIGN, U+002D HYPHEN-MINUS) returns an automatic increment of the previous
number
* Note: strings beginning with U+002E FULL STOP ignore that character
* Note: automatic increments of the previous value are 1 if there is no
previous value, but overflow to -2147483648 if the previous value was
2147483647
Opera
* By default, the value is an automatic increment of the previous number
* Values greater than 536870911 return 536870911
* Values less than -536870912 return -536870912
* An empty string returns 0
* A string not beginning with any numeric characters (including U+002B PLUS
SIGN, U+002D HYPHEN-MINUS) returns 0
* Note: automatic increments of the previous value are 1 if there is no
previous value
Dillo
* By default, the value is an automatic increment of the previous number
* Values greater than 2147483647 return 2147483647
* Values less than 0 return 0
* An empty string returns 0
* A string not beginning with any numeric characters (including U+002B PLUS
SIGN, U+002D HYPHEN-MINUS) returns 0
* Note: automatic increments of the previous value are 1 if there is no
previous value
Lynx
* By default, the value is an automatic increment of the previous number
* Values greater than 2147483647 return 2147483647
* Values less than -29997 return -29997
* Note: This behavior is documented:
http://lynx.isc.org/current/lynx2-8-8/lynx_help/Lynx_users_guide.html#Lists
* An empty string returns an automatic increment of the previous number
* A string not beginning with any numeric characters (including U+002D
HYPHEN-MINUS) returns an automatic increment of the previous number
* Note: automatic increments of the previous value are 1 if there is no
previous value
w3m
* By default, the value is an automatic increment of the previous number
* Values greater than 2147483647 return 2147483647
* Values less than 0 return 0
* An empty string returns 0
* A string not beginning with any numeric characters (including U+002B PLUS
SIGN, U+002D HYPHEN-MINUS) returns 0
* Note: automatic increments of the previous value are 1 if there is no
previous value
Notes:
* Versions of user agents included the latest versions, all commonly-used
versions, and many others, including extremely old versions (for example, IE
was tested between versions 3 and 9). Occasional variations exist only in
extremely old versions (for example, IE version 2 has different behavior to all
other versions), however, no other browsers, or old versions of browsers, seem
to be worth reporting on due to the small number of active deployments.
* The value 2147483647 is the highest value that can be stored in a signed
32-bit integer. The value -2147483648 is the lowest value that can be stored in
a signed 32-bit integer. In principle, software compiled using a different int
width may have different, corresponding limits; although in practice this is
very rare.
* Also, note that the current HTML5 algorithms is slightly inconsistent with
CSS (which explicitly allows U+002B PLUS SIGN to indicate positive integers). I
don't know if mapping this attribute to CSS is a concern.
***
Personally, I don't have a solution to propose; this is purely informative.
--
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 Sunday, 23 October 2011 14:03:45 UTC