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

[whatwg] [wf2] changing the size DOM attribute of <select>

From: Jim Ley <jim.ley@gmail.com>
Date: Sat, 11 Feb 2006 00:30:53 +0000
Message-ID: <851c8d310602101630n6c92a153t253a204cf5d78092@mail.gmail.com>
On 2/11/06, Jim Ley <jim.ley at gmail.com> wrote:
> On 2/10/06, Anne van Kesteren <fora at annevankesteren.nl> wrote:
> > Browsers disagree on what should be selected in such cases. Simple testcase:
> >
> >  <http://webforms2.testsuite.org/controls/select/009.htm>
> >
> > Opera 9 passes that test and I heard Safari nightlies do too. Internet Explorer
> > and Firefox fail the testcase. Personally I would be in favor of changing the
> > specification to be compatible with Opera 9 and Safari given that what they do
> > is sensible.
>
> Why can't this be left undefined? what does it matter to have
> interopable rendering on invalid DOM changes?  Surely forcing code
> changes on anyone is just a waste of implementation time here, not
> updating the page when the DOM is changed to an invalid number is a
> good optimisation?
>
> IE for example simply rejects the update (the size remains at 2), that
> seems like a sensible approach, as does normalizing it to 1.
>
> I simply don't see the value in standardising the error behaviour here.

Oh but if you do, I don't believe the Opera method of having the
appearance of a 1, but a value of a size of 0 or -1 is correct.  If
corrections are made, the DOM should reflect the actual value used -
after all that is the only thing useful to the user.

Mozilla seems to correct -1 to 0 but nothing else.

Cheers,

Jim.
Received on Friday, 10 February 2006 16:30:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:26 UTC