[whatwg] WebIDL and HTML5
On Tue, May 6, 2008 at 4:04 AM, Ian Hickson [EMAIL PROTECTED] wrote:
heycam -- see at the end for a request for WebIDL.
On Mon, 25 Apr 2005, Brad Neuberg wrote:
True, but having prototypes on DOM objects can be extremely useful and
provide all sorts of very powerful options. Mozilla allows manipulation
of the prototype object on DOM objects (except for removing the original
native methods and attributes, for security reasons). Unfortunately, IE
doesn't support this, so this ability can't really be used in practice.
Nor should it be. For any environment. It is a good way to create bugs
and confuse programmers. Anyone who says that this is misfortunate
ought to say why he thinks this is so.
WebIDL now requires this.
Requires what?
On Thu, 11 May 2006, Dean Edwards wrote:
At the moment, DOM objects are specified in a language neutral way.
That's fine. However, this makes these objects uninteresting and
cumbersome to script with.
Mozilla has a more integrated programming environment. It exposes DOM
objects as native JavaScript objects. That means I can do things this
like this:
Object.prototype.foo = bar;
alert(document.body.foo);
== bar
A trivial example but it demonstrates that the DOM and JavaScript are
not totally separate on a Mozilla platform. This is very cool. 8-)
WebIDL now requires this.
Can you elaborate on that statement?
It would be great if NodeLists were subclasses of JavaScript Array
It wouldn't really make sense to do that.
objects (especially with the introduction of Mozilla's Array Extras
[1]). This makes iteration over DOM queries more flexible.
No, it doesn't. What are you trying to accomplish?
You can assign the Array methods to the NodeList prototype, they're
generic.
Was there any thought that went into that statement?
This is horrible advice for several reasons:
1) Modifying host objects with new properties is a good way to create
bugs and confuse developers.
2) NodeList is an interface and should not have any implementation.
Even in browsers that expose a NodeList object, it cannot be
guaranteed
3) You answered a question for which no need was demonstrated, and
provided no example.
4) Calling any of the array methods on a NodeList would obviously
fail. We can take a look at push, for example:-
javascript:try{ alert(Array.prototype.push.call(document.childNodes));
} catch(ex){alert(ex.message);}
Should err out in step 7 of push attempting to set the length property.
| 15.4.4.7 Array.prototype.push([ item1[, item2 [,...]]])
|
| The arguments are appended to the end of the array,
| in the order in which they appear. The new length of the array
| is returned as the result of the call.
|
| When the push method is called with zero or more arguments
| item1, item2, etc., the following steps are taken:
|
| 1. Call the [[Get]] method of this object with argument length.
| 2. Let n be the result of calling ToUint32(Result(1)).
| 3. Get the next argument in the argument list; if there are no more
|arguments, go to step 7.
| 4. Call the [[Put]] method of this object with arguments ToString(n)
|and Result(3).
| 5. Increase n by 1.
| 6. Go to step 3.
| 7. Call the [[Put]] method of this object with arguments length
|and n.
| 8. Return n.
We could also see how easily [[put]] method would not work as Array
[[Put]]. For example, setting a 2 property:-
javascript:alert(document.childNodes[2] = 1);
will add a new property with name 2
javascript:alert(document.childNodes[2]);
and will not update the length.
javascript:alert(document.childNodes.length);
Modifying host objects is a very bad idea. NodeList is an Interface.
An interface should have no implementation. Even if you really wanted
to follow Ian's advice, it wouldn't work.
This is probably what led up to the dojo.NodeList and may have
influenced Ian in his Web Forms 2.0. Modifying NodeList.prototype is
not advisable.
(more top posts)
On Sun, 21 May 2006, Dave Hodder wrote:
[snip]
More...
On Sat, 2 Jun 2007, Anne van Kesteren wrote:
For .innerHTML = null Opera and Internet Explorer act as if the literal
string null was used. Firefox acts as if was used.
For .innerHTML = undefined Opera, Firefox and Internet Explorer act as
if the literal string undefined was used.
On Mon, 4 Jun 2007, Jonas Sicking wrote:
I'd really dislike having to have this one property behave differently
than other text properties in the DOM. How do opera/ie deal with other
text properties like .src, .id, .textContent?
On Mon, 4 Jun 2007, Michael A. Puls II wrote:
For .src and .id, IE and Opera set null.
Opera does the same for textContent.
For .src, this obviously means that IE and Opera will then return the
directory of the page + null where as FF will return the URI to the
page.
The way IE and Opera do null doesn't seem to be just limited to
innerHTML.
On Tue, 5 Jun 2007, liorean wrote:
Seems to me like they are simply using the ECMAScript ToString
algorithm, unless
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: I already expressed my opinion, agreeing with Liorean. For domstring arguments, call the internal ToString on the input would be the general rule, unless otherwise stated. This would seem to cover the majority of cases. window.open is one of the cases when things are not covered, and that's what we were talking about, no? -Boris
Re: [whatwg] WebIDL and HTML5
On Mon, Aug 25, 2008 at 10:20 AM, Boris Zbarsky [EMAIL PROTECTED] wrote: Garrett Smith wrote: I already expressed my opinion, agreeing with Liorean. For domstring arguments, call the internal ToString on the input would be the general rule, unless otherwise stated. This would seem to cover the majority of cases. window.open is one of the cases when things are not covered, and that's what we were talking about, no? That's the example Ian posted up. I think Ian may be a bit off in his observations. undefined and null don't convert to the empty string in window.open. For example:- window.open(); If the first argument is null or undefined or the empty string, no uri is loaded and an blank/empty window is displayed. There seems to be no mapping though Ian has requested documenting such mapping. Are there other examples for if the argument is null or undefined...? There are probably others but I can't think of them. I think the majority of the time that strings will want to go to ToString, booleans will want to go to ToBoolean. I can see no reason for special-casing innerHTML = null.. Any application that uses such technique is arguably already broken. Garrett -Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: window.open(); Which should be equivalent to window.open(undefined) (and isn't in some UAs), right? What should window.open(null) do? If the first argument is null or undefined or the empty string, no uri is loaded and an blank/empty window is displayed. This is not the case in Firefox, Opera, or Safari. Safari and Firefox treat null as null. Opera treats it as . Opera treats undefined as , while Safari and Firefox treat it as undefined. This is for window.open's first argument. There seems to be no mapping though Ian has requested documenting such mapping. No mapping of what? +null is null. +undefined is undefined. Those are basically what Firefox and Safari do. That doesn't seem like the right thing to do here, necessarily. Are there other examples for if the argument is null or undefined...? Sure. A lot of the namespace-relatd DOM methods, as well as all sorts of DOM0 stuff. There are probably others but I can't think of them. I think the majority of the time that strings will want to go to ToString, booleans will want to go to ToBoolean. That can be the default, perhaps. But I suspect usually null should become , not null. -Boris
Re: [whatwg] WebIDL and HTML5
On Mon, Aug 25, 2008 at 11:28 AM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
window.open();
Which should be equivalent to window.open(undefined) (and isn't in some
UAs), right?
What should window.open(null) do?
If the first argument is null or undefined or the empty string, no uri
is loaded and an blank/empty window is displayed.
This is not the case in Firefox, Opera, or Safari. Safari and Firefox treat
null as null. Opera treats it as . Opera treats undefined as , while
Safari and Firefox treat it as undefined.
This is for window.open's first argument.
There seems to be no mapping though Ian has requested documenting such
mapping.
No mapping of what? +null is null. +undefined is undefined.
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.
Those
are basically what Firefox and Safari do. That doesn't seem like the right
thing to do here, necessarily.
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, and,
if that is true, then no uri is loaded. Example:
!DOCTYPE HTML
html lang=en
head
titlewindow.open()/title
/head
body
a href=javascript:void(window.open());open()/a
a href=javascript:void(window.open(null));open(null)/a
a href=javascript:void(window.open(undefined));open(undefined)/a
a href=javascript:void(window.open(0));open(0)/a
/body
/html
Result in Safari:
window.open(0), loads can't find that page.
all others load blank window
Result in Firefox:
open() open('') open blank window
all others load can't find that page
Ian and others, you may use this and any other test case I post up.
Are there other examples for if the argument is null or undefined...?
Sure. A lot of the namespace-relatd DOM methods, as well as all sorts of
DOM0 stuff.
There are probably others but I can't think of them. I think the
majority of the time that strings will want to go to ToString,
booleans will want to go to ToBoolean.
That can be the default, perhaps. But I suspect usually null should become
, not null.
Why?
Garrett
-Boris
Re: [whatwg] WebIDL and HTML5
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 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 all), this seems to indicate that web compat lies on the side of treating null as . -Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: There are probably others but I can't think of them. I think the majority of the time that strings will want to go to ToString, booleans will want to go to ToBoolean. That can be the default, perhaps. But I suspect usually null should become , not null. Why? Note that 'null' is generally a valid value for DOMString. This doesn't seem to be explicitly called out in the definition for DOMString. However there are lots of functions that takes a DOMString and describes what to do when the argument is null (as opposed to null). So for a function like bool doStuff(in DOMString arg); if null is passed there should be no need to call .toString() or any other type of conversion is needed at all. However most functions in the DOM spec does not define behavior for the null value, so we have chosen to treat it as the the empty string as that seems like the most sensible behavior. / Jonas
Re: [whatwg] WebIDL and HTML5
On Mon, Aug 25, 2008 at 12:47 PM, Boris Zbarsky [EMAIL PROTECTED] 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 TypeResult | Undefinedundefined | 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 - . Garrett -Boris
Re: [whatwg] WebIDL and HTML5
On Mon, Aug 25, 2008 at 6:07 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: There are probably others but I can't think of them. I think the majority of the time that strings will want to go to ToString, booleans will want to go to ToBoolean. That can be the default, perhaps. But I suspect usually null should become , not null. Why? Note that 'null' is generally a valid value for DOMString. This doesn't seem to be explicitly called out in the definition for DOMString. However there are lots of functions that takes a DOMString and describes what to do when the argument is null (as opposed to null). So for a function like bool doStuff(in DOMString arg); There is no DOM method calld doStuff. Can you provide a concrete example? Boris couldn't think of one either. Let us first investigate some implementations. if null is passed there should be no need to call .toString() or any other No, but there should be a need to call ToString. type of conversion is needed at all. However most functions in the DOM spec does not define behavior for the null value, so we have chosen to treat it as the the empty string as that seems like the most sensible behavior. It is not something that can or should be generally relied upon because it is not standardized and indeed works differently in implementations. Please also review the example I provided earlier, assigning an object as a css property value. Considering your argument for serializing null - being the most sensible, I disagree. Ecma-262 r3, Section 9.8 ToString states clearly that null is mapped to null. This is how the language was designed. I do not agree that it's a bug or mistake. We've been over that before. Here: http://lists.w3.org/Archives/Public/public-webapi/2008May/0457.html Garrett / Jonas
