W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [whatwg] WebIDL and HTML5

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 25 Aug 2008 20:56:05 -0700
Message-ID: <c9e12660808252056j64b0ac09te2732c4b3037d0ec@mail.gmail.com>
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: "Web Applications Working Group WG" <public-webapps@w3.org>

On Mon, Aug 25, 2008 at 12:47 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>> The addition operator results in concatenation when either operand is
>> a string. This results in a calls to the internal ToString, which is
>> what I'm suggesting should be the general rule.
> All I'm saying is that this will require annotating a very large number of
> API methods; possibly larger than an alternate general rule.
>> I agree that loading path + '/null' or path + 'undefined' is not
>> desirable. Any application that relies on this is already broken,
>> arguably, because, contrary to your observations, safari first checks
>> to see if the argument is null or undefined or the empty string
> Indeed.  I mixed up Safari and Opera in my test.  So Opera does undefined ->
> "undefined" and null -> "null" for the first arg of window.open, while
> safari treats them as empty strings.
>>> That can be the default, perhaps.  But I suspect usually null should
>>> become
>>> "", not "null".
>> Why?
> Honestly?  Because that's what Firefox does right now, except in certain

That is not true. Firefox has Spidermonkey. Spidermonkey follows
Ecma-262r3, section 9.2.

| 9.8 ToString
| The operator ToString converts its argument to a value of
| type String according to the following table:
|Input Type        Result
| Undefined        "undefined"
| Null             "null"

> special cases (window.open being one of them, actually), and things aren't
> breaking?  Unless other UAs are doing other things (and hence sites just
> don't rely on any particular behavior at this seems to indicate that
> web compat lies on the side of treating null as "".

Web sites that rely on window.open(null) are already broken. They are
broken because they are relying on non-specified behavior that will
have different results in different browsers.

Firefox' 3.1 (Minefield) implementation window.open() produces a
different result as window.open(undefined). There is no standard for
this, so it is not invalid, however, it is inconsistent with 10.1.3
Ecma-262 r3 (which applies to built-in methods), and somewhat against
the nature of the language. Firefox' behavior should probably be
changed exactly to match what I wrote earlier, and this can be
specified (what Safari does is that if the argument is null,
undefined, or the empty string, a blank window opens). There is no
mapping of null -> "".


> -Boris
Received on Tuesday, 26 August 2008 03:56:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC