W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] the impact of <select>.value behavior clearing current selection prior to setting the new selection

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 2 Feb 2012 19:01:45 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1202021854050.13116@ps20323.dreamhostps.com>
On Thu, 2 Feb 2012, Cameron McCormack wrote:
> Ian Hickson:
> > It's my understanding that what you describe as what browsers do is 
> > also what the specs require. The attribute is defined as being of type 
> > "long", so if I'm not misreading the Web IDL spec, the browser will 
> > try to convert the null or string value to a number (and fail) long 
> > before the HTML spec's prose is relevant.
> 
> For the long type, null and strings like "junk" will get converted to 0.
> 
> http://dev.w3.org/2006/webapi/WebIDL/#es-long

Turns out this is actually what specs do, too! I didn't test the null case 
before sending my last reply, but having now tested it, it seems Firefox, 
Webkit, IE10 (thanks to Aryeh for testing that), and Opera all do what the 
specs say to do here.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1321

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 2 February 2012 11:01:45 UTC

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