W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] Treatment of negative values for li

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 16 Nov 2010 02:55:14 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1011160250380.26618@ps20323.dreamhostps.com>
On Thu, 12 Aug 2010, Aryeh Gregor wrote:
>
> The HTML5 spec doesn't say UAs should treat <li value="-1"> different 
> from a negative value specified for any long.  For example, a get on the 
> reflected attribute li.value should return "-1".  In this test case:
> 
> <!doctype html>
> <script>
>     var el = document.createElement("li");
>     el.setAttribute("value", "-1");
>     alert(el.value);
> </script>
> 
> Chrome dev, Safari 5, and Opera 10.60 all alert "-1" as expected, but 
> Firefox 4.0b3 and IE8/9 (all modes) alert "0".  In fact, Firefox and IE 
> clamp all negative values to 0.  Does anyone think this behavior is 
> valuable, or should Firefox and IE change to match the spec?  I don't 
> see any reason to treat negative values specially, if the author goes 
> out of their way to specify them.
> 
> Relatedly, only Opera seems to handle markup like
> 
> <!doctype html>
> <ol>
>     <li value="-2">...
>     <li value="-1">...
>     <li value="0">...
>     <li value="1">...
> </ol>
> 
> correctly.  IE8 and WebKit give 1, 2, 3, 1 (treating nonpositive value 
> attribute the same as if it were missing), and Firefox gives 0, 0, 0, 1 
> (clamping negative values to 0).  Opera gives -2, -1, 0, 1 as expected.  
> Again, I think the spec is correct here, but since browsers disagree so 
> widely, I'm asking for opinions before I file bugs against browsers.

On Thu, 12 Aug 2010, Tab Atkins Jr. wrote:
> 
> CSS implicitly states that negative list-marker values are allowed, as 
> negative numbers are discussed in the Lists module.  Opera's behavior 
> should be the correct one here.

On Thu, 12 Aug 2010, Boris Zbarsky wrote:
> 
> Just as a note, Gecko's code to imposing a lower bound of 0 on <li 
> @value> goes back to the initial implementation of attribute parsing in 
> September 1998 or so.  I doubt there was any particular reason for it 
> other than Netscape or IE compat.

Yeah, this was a conscious choice when writing this part of the spec, 
IIRC. The browsers vary wildly, as Aryeh describes, and it's not clear 
that there's a compat reason for any particular behaviour, so I specced 
the simpler and saner behaviour. I don't recall if I studied common values 
of value="" and start="" on <li> and <ol>. (If I did then presumably they 
weren't very common.)

I'm happy to change it if there are any compat constraints here (which 
would presumably be discovered pretty quickly once browsers move towards 
implementing this, since it affects the rendering in a pretty obvious way).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 15 November 2010 18:55:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC