- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 31 Dec 2008 14:23:46 +0100
On Wed, Dec 31, 2008 at 4:59 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 31 Dec 2008, Jonas Sicking wrote: >> On Wed, Dec 31, 2008 at 3:17 AM, Jonas Sicking <jonas at sicking.cc> wrote: >> > On Mon, Dec 29, 2008 at 11:37 AM, Ian Hickson <ian at hixie.ch> wrote: >> >> On Fri, 22 Aug 2008, Shannon wrote: >> >>> Either way I would recommend making a decision on minimum and maximum >> >>> integer values an using them consistently. If not I can imagine the >> >>> rapid adoption of 64-bit systems will cause unexpected errors when the >> >>> same code is run on older 32-bit systems. There are valid arguments for >> >>> letting each system use its native integer but if this is the case then >> >>> perhaps the spec should require MIN_INT and MAX_INT be made available as >> >>> constants. >> >> >> >> ECMAScript does define a range, and the limits of that range are exposed >> >> to scripts. Are there cases where there are non-script limits that would >> >> benefit from being exposed? Use cases would be helpful here. >> > >> > I thought ECMAScript defined the value to be a IEEE 754 64bit float. >> >> Ah, sorry, I missed that you didn't have a 'not' in your response :) >> >> There are in fact interop issues given the fact that ECMAScript allows >> for a range bigger than a 32bit integer can fit. For example you could >> do >> >> myInput.maxLength = 5000000000; >> >> This would is within the bounds and precision of ECMAScript, but won't >> work in a 32bit integer implementation. > > WebIDL defines how to handle that, though, right? (Each DOM attribute has > an explicit bit width.) The problem, if there is a problem, would be with > the content attribute alone. So how would something like <input maxlength="5000000000"> be parsed? Is it defined in terms of setting the .maxLength DOM attribute, so that its behavior depends on what WebIDL says? Or something else? / Jonas
Received on Wednesday, 31 December 2008 05:23:46 UTC