Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: 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. A quick search through the DOM Level 3 Core gives: The generic statement # Applications should use the value null as the namespaceURI parameter # for methods if they wish to have no namespace. In programming # languages where empty strings can be differentiated from null, empty # strings, when given as a namespace URI, are converted to null So here is clearly treated as null, while null is distinct from the two of them. Same thing in the hasFeature function which states # a DOM Level 3 Core implementation who returns true for Core with the # version number 3.0 must also return true for this feature when the # version number is 2.0, or, null The function DOMStringList.item returns a DOMString with the value null when the index is = the length. It seems unexpected to return null here, though it's not explicitly clear. NameList similarly returns the DOMString null from getName and getNamespaceURI under some conditions. The function DOMImplementation.createDocument accepts null as value for namespaceURI and qualifiedName to indicate that no documentElement should be created. I would expect that passing null for those parameters would create an element with localname null in the namespace null. Effectively null xmlns=null without the xmlns attribute. It further states that an exception should be thrown if qualifiedName has a prefix but namespaceURI is null, but seems to allow qualifiedName having a prefix and namespaceURI being null. The attribute Document.documentURI returns the DOMString null under certain conditions. It also states # No lexical checking is performed when setting this attribute; this # could result in a null value returned when using Node.baseURI Which seems to indicate that you can set it to null. The attribute Document.inputEncoding is of type DOMString and returns null under certain conditions. The attribute Document.xmlEncoding is of type DOMString and returns null under certain conditions. The attribute Document.xmlVersion is of type DOMString and returns null under certain conditions. A lot of functions on the Document interface for creating nodes state that nodes are created with localName, prefix, and namespaceURI set to null, such as createElement. All these properties are DOMStrings. Further, the namespace-aware functions, such as createElementNS say to throw an exception if the qualifiedName parameter has a prefix but namespaceURI is null. It makes no such statement if the namespaceURI is null. I'm actually going to stop here. There are plenty of references in the spec to DOMStrings having the value null. So while it's not specifically clear in the definition of DOMString it seems clear to me that null is a valid value for DOMString. So no conversion using any conversion operator is needed. Thus I don't think talking about what ToString does is relevant to the discussion. Further, many of functions in the DOM Level 3 Core spec treat null as , not as null. All the namespace aware factory functions on the Document interface does so, DOMImplementation.hasFeature does so, Element.getAttributeNS does so. 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. In your example, if I understand it correctly, you are passing it something that is not a valid DOMString. In that case I absolutely agree that using ToString to convert it to a string is the right thing to do. However when null is passed that is not the case. / Jonas
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: 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. The Spidermonkey part is irrelevant for purposes of this discussion, except in places where JS_ValueToString is used (basically DOM0 special-cases). What matters is the XPConnect glue layer which converts JS function calls into C++ function calls in the general case. In fact, the relevant code for Gecko 1.9 is right here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcconvert.cpprev=1.129mark=743-751#731 and http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/xpcprivate.hrev=1.283mark=932-934#922 It converts a JSVAL_NULL into an empty nsAString with the IS_VOID bit set. Firefox' 3.1 (Minefield) implementation window.open() produces a different result as window.open(undefined). Indeed, because the latter goes through XPconnect, which converts undefined to undefined for some odd reason. -Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote:
There is no DOM method calld doStuff. Can you provide a concrete
example? Boris couldn't think of one either.
Uh, what? You never said, I don't understand that this applies to all
DOM methods that take a DOMString, so I'd like to have some specific
examples.
In any case, here's a simple example:
javascript:try { alert(document.createElement(null).localName); }
catch(e) { alert(e) }
In some UAs that alerts null, in some it throws an exception because
createElement() is not valid. Just try it.
No, but there should be a need to call ToString.
The thing is, ToString is lossy. Once called, there is no way to tell
apart null and null. However, there are DOM methods which require
different behavior for the two (e.g. createElementNS and so forth, which
I did explicitly mention earlier, contrary to your counldn't think of
one either business).
Similarly, there are DOM methods that require different behavior for
null and . Specific examples include the proposed DOM style set APIs,
DOMImplementation.createDocument. There are also cases where returning
null and returning are not equivalent. inputEncoding is an example.
It is not something that can or should be generally relied upon
because it is not standardized and indeed works differently in
implementations.
Yes. The whole point is to standardize it.
Considering your argument for serializing null - being the most
sensible, I disagree.
It's sensible in the context of the large number of DOM methods that
treat the two as equivalent (again, all the *NS methods in DOM3 Core).
-Boris
Re: XDomainRequest Integration with AC
On Fri, 08 Aug 2008 20:44:04 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The big worry I have though is if there is any possibility to puny encode the same origin in multiple ways (other than with or without default port). This could lead to different UAs encoding the same origin in different ways, which could lead to interoperability issues if sites rather than echoing the 'Origin' header always send out a static value for the Access-Control-Allow-Origin header. Is that possible? I don't think it is. Domain names follow a strict set of normalization rules. (That would also mean the Origin header could contain different values depending on the implementation, which is not the case.) In general, I don't think it's a lot of work to require a strict same-origin check. All browsers should have such an algorithm implemented anyway. True, but if we can make things simpler that seems better. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Proposal
On Tue, 15 Jul 2008 01:02:58 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: Since implementations need answers to various open issues soonish and I'm leaving on vacation roughly two days from now I'll propose various solutions here and try to integrate them in drafts later on: I made the changes to the Access Control for Cross-Site Requests specification as described below. From discussion it seemed that everyone could agree to this fortunately. (Although there was some discussion on whether or not the Access-Control-Allow-Origin value syntax needed changing.) HEADER NAMES Access-Control-Origin - Access-Control-Allow-Origin Access-Control-Credentials - Access-Control-Allow-Credentials HEADER SYNTAX Parsing Access-Control-Allow-Origin will have a check to ensure that path is empty. If it is non-empty the network error steps will be applied. We keep the separate header for credentials to keep the origin concept orthogonal from the credentials flag. This changed to become a simple string comparison. Effectively, between the value of Origin and Access-Control-Allow-Origin. CROSS-SITE POST We limit the amount of Content-Type header values people can set for the simple cross-site POST request to those you can use with HTML forms today. This list will not become a fixed list until we work out how Access Control for Cross-Site Requests will work together with HTML5 forms. I have not yet made this change to XMLHttpRequest Level 2, but the Access Control specification does support the architecture required for it: XMLHTTPREQUEST API FLAG The XMLHttpRequest interface will gain a withCredentials boolean DOM attribute. The value of that attribute is used during send() and stored in memory when send() is invoked so an event listener dispatched between send() being invoked and the request happening cannot change it. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] WebIDL and HTML5
On Tue, Aug 26, 2008 at 5:38 AM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
There is no DOM method calld doStuff. Can you provide a concrete
example? Boris couldn't think of one either.
Uh, what? You never said, I don't understand that this applies to all DOM
methods that take a DOMString, so I'd like to have some specific examples.
I did ask. Here's what I wrote:
| 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.
In any case, here's a simple example:
javascript:try { alert(document.createElement(null).localName); } catch(e) {
alert(e) }
In some UAs that alerts null, in some it throws an exception because
createElement() is not valid. Just try it.
Using ToString, the following result would be obtained:
// ERROR
document.createElement();
// create a null element.
document.createElement(null);
// Create an a element.
document.createElement( { toString: function(){ return a; }} );
document.createElement( new String(div) );
To simulate the ToString effect, use String( arg ); (do not use new
String(arg));
No, but there should be a need to call ToString.
The thing is, ToString is lossy. Once called, there is no way to tell apart
null and null. However, there are DOM methods which require different
behavior for the two (e.g. createElementNS and so forth, which I did
explicitly mention earlier, contrary to your counldn't think of one either
business).
After the method createElement(null) is called, there will be no need
to tell apart null and null. I see that. Why is that a problem?
You said that null - null is lossy. I don't think that's a valid
argument. null - is even more lossy.
Similarly, there are DOM methods that require different behavior for null
and . Specific examples include the proposed DOM style set APIs,
DOMImplementation.createDocument. There are also cases where returning null
and returning are not equivalent. inputEncoding is an example.
null and are not equivalent. Setting a style to have the value null
should probably convert the value to null
document.body.style.color = null;
However, such applications that are already expecting such behavior
are already broken because they are relying on non-standard behavior
which is known to not work cross-browser. Setting style values to
invalid values will result in script errors in Internet Explorer.
document.body.style.color == null
Internet Explorer is more strict in that it requires a string value,
and won't call ToString. It would be useful to have the method call
ToString, because that way an object with a toString method could be
used for setting values:
script
var colorObject = {
r : 16, g: 255, b: 16,
toString : function() {
return rgb( + this.r + , + this.g + , + this.b+); }
}
document.body.style.backgroundColor = colorObject;
/script
It would seem somewhat expected that the colorObject's toString would
be called. The object's toString method would be called from the
internal ToString method.
It is not something that can or should be generally relied upon
because it is not standardized and indeed works differently in
implementations.
Yes. The whole point is to standardize it.
Considering your argument for serializing null - being the most
sensible, I disagree.
It's sensible in the context of the large number of DOM methods that treat
the two as equivalent (again, all the *NS methods in DOM3 Core).
That would be a poor design choice, because it is inconsistent with
programmer expectation. Considering that string objects are objects
and not domString, new String(div) is an object. div is a string
value.
document.createElement( new String(div) );
- is not standardized. This would seem to create a div element,
but can't be expected to. Nor is:-
document.createTextNode(0)
Should this create a textNode 0 or ?
I would argue that the former is a little more intuitive. And if the
programmer explicitly uses:-
document.createTextNode(null)
should probably create a text node with the value null. It is harder
to debug null to but null to null is easy to debug.
Null is not the same as no value. Null is a type, having one value:-
null. The value null is a primitive value in EcmaScript. It is the
only member of the Null type.
Generally, a domstring argument could go through some sort of string
conversion to get a string value. The conversion that it should go
through is the standard one defined by EcmaScript internal ToString.
Garrett
-Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: Using ToString, the following result would be obtained: Yes, I know what you get with ToString. After the method createElement(null) is called, there will be no need to tell apart null and null. I see that. Why is that a problem? There are other methods where you DO need to tell them apart, of course. All the *NS methods, for example. You said that null - null is lossy. I don't think that's a valid argument. null - is even more lossy. Yes, which is why we need a way in IDL to specify exactly what happens to null in different cases. We need a one-to-many mapping here, and just doing a single-input-single-output function like ToString doesn't cover all cases. null and are not equivalent. Setting a style to have the value null should probably convert the value to null document.body.style.color = null; I'd be fine with that (though I'd worry about compat issues), but that doesn't address the fact that in some cases null does need to be converted to , or treated just like . That would be a poor design choice Which? And on whose part? document.createTextNode(0) Should this create a textNode 0 or ? Or throw a typeError? Null is not the same as no value. Null is a type, having one value:- null. The value null is a primitive value in EcmaScript. It is the only member of the Null type. Yes, yes. We all know that, and you've repeated it multiple times. I sort of feel like we're talking in circles here. One last time, the facts: 1) There are DOM methods that accept DOMString arguments or return DOMString values. 2) In general, such methods need to be able to tell apart null and all string values (including and null). 3) The behavior of null is almost always either that of or that of null. Which one depends on the exact DOM method. Therefore, the proposal is to annotate DOM DOMString arguments to DOM methods with some indication of whether null should be treated as or as null, or as some value not equal to any string. One of these three options can be the default; the other two then require explicit annotation. Are we on the same page so far? -Boris
Re: [whatwg] WebIDL and HTML5
On Tue, Aug 26, 2008 at 9:22 AM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
Using ToString, the following result would be obtained:
Yes, I know what you get with ToString.
After the method createElement(null) is called, there will be no need
to tell apart null and null. I see that. Why is that a problem?
There are other methods where you DO need to tell them apart, of course.
All the *NS methods, for example.
You said that null - null is lossy. I don't think that's a valid
argument. null - is even more lossy.
Yes, which is why we need a way in IDL to specify exactly what happens to
null in different cases. We need a one-to-many mapping here, and just doing
a single-input-single-output function like ToString doesn't cover all cases.
null and are not equivalent. Setting a style to have the value null
should probably convert the value to null
document.body.style.color = null;
I'd be fine with that (though I'd worry about compat issues), but that
doesn't address the fact that in some cases null does need to be converted
to , or treated just like .
That would be a poor design choice
Which? And on whose part?
document.createTextNode(0)
Should this create a textNode 0 or ?
Or throw a typeError?
A TypeError might seem technically correct for a native method,
however, most dom methods raise a dom exception.
An implementation that created a text node with value 0 would be non-standard.
Null is not the same as no value. Null is a type, having one value:-
null. The value null is a primitive value in EcmaScript. It is the
only member of the Null type.
Yes, yes. We all know that, and you've repeated it multiple times. I sort
of feel like we're talking in circles here.
It is primary point of my argument. However, considering your claim, I
am not certain that everyone here knows that and the discussion seems
to give good indication. I can find further indication in WebIDL[1]:-
| A scoped name that resolves to a boxed valuetype is
| used to refer to a type that corresponds to the set of
| values for the type being boxed, plus the special value null,
| which indicates no value.
Null isn't a special value. The value null is of Type Null. null in
EcmaScript is not the same as null in Java.
One last time, the facts:
1) There are DOM methods that accept DOMString arguments or return
DOMString values.
Fact.
2) In general, such methods need to be able to tell apart null and all
string values (including and null).
They need to determine value type so that they can either throw or
handle. null, 0, undefined, new String('x'), are all not strings.
3) The behavior of null is almost always either that of or that of
null. Which one depends on the exact DOM method.
That is false. null has no behavior. Methods have behavior. For
example, EcmaScript's internal ToString has a behavior of converting
null to null. That is a behavior.
There are (currently) 5 non-string value types: Object (which includes
String object), or any of other 4 primitive types (null, undefined,
number, boolean). How do you want to map all of these? Exception for
number? Exception for Object would be OK, but is somewhat against what
programmers want and expect[2]. What about String Objects? Throwing on
a String object would confuse Java programmers who are dabbling in web
scripting.
1. Specifying null to be interpreted as is inconsistent with
EcmaScript's string conversion ToString.
2. Debugging null - is difficult. Programmers that pass null to
objects such as createElement, et c, are using non-standard behavior
that doesn't work consistently across current implementations. Such
programs are buggy.
3. There are many value types that may be passed to DOM methods. The
DOM methods that require domstring should either require a string
value, or should allow conversion to a string value.
4. Creating special cases for mapping/converting non-string values
would introduce complexity.
Methods that accept a domstring could:
1) raise exception for null/undefined
2) convert the argument that is not a string to a string,
3) raise exception if the argument is not a string
4) 1 and 2.
Consideration:
Option (1): Would make bugs more apparent.
Option (2): Could be made to be consistent with EcmaScript ToString,
for consistency.
Option (3): Would make bugs more apparent, but would go against
programmer expectation[2]
Option (4): Would make some bugs more apparent, but would also allow
programmers to pass an object where a string was required.
The options that you seem to favor is (2), and I don't have a problem
with that. What I do have a problem with is making up a new string
conversion mapping and calling null a string with no value. That's
just wrong. The downside to making up a new string conversion mapping
is that it introduces complexity, doesn't account for other primitives
or objects, and conflicts with a perfectly good existing standard,
EcmaScript's ToString.
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote:
In some UAs that alerts null, in some it throws an exception because
createElement() is not valid. Just try it.
Using ToString, the following result would be obtained:
// ERROR
document.createElement();
// create a null element.
document.createElement(null);
// Create an a element.
document.createElement( { toString: function(){ return a; }} );
document.createElement( new String(div) );
To simulate the ToString effect, use String( arg ); (do not use new
String(arg));
Exactly, this shows that converting null to null is undesirable for
some functions.
No, but there should be a need to call ToString.
The thing is, ToString is lossy. Once called, there is no way to tell apart
null and null. However, there are DOM methods which require different
behavior for the two (e.g. createElementNS and so forth, which I did
explicitly mention earlier, contrary to your counldn't think of one either
business).
After the method createElement(null) is called, there will be no need
to tell apart null and null. I see that. Why is that a problem?
Not sure what you are saying here.
You said that null - null is lossy. I don't think that's a valid
argument. null - is even more lossy.
Both conversions are lossy yes. The correct solution is to do no
conversion. As I've stated many times, null is a valid value for
DOMString and so no conversion is needed in the general case.
However for some function *implementations* treating giving null and
as an input argument will yield the same result, such as createElement.
Similarly, there are DOM methods that require different behavior for null
and . Specific examples include the proposed DOM style set APIs,
DOMImplementation.createDocument. There are also cases where returning null
and returning are not equivalent. inputEncoding is an example.
null and are not equivalent. Setting a style to have the value null
should probably convert the value to null
What do you base that on? Can you point to any specs that state that
that is the correct thing, or any webpages that expect that behavior?
Internet Explorer is more strict in that it requires a string value,
and won't call ToString. It would be useful to have the method call
ToString, because that way an object with a toString method could be
used for setting values:
script
var colorObject = {
r : 16, g: 255, b: 16,
toString : function() {
return rgb( + this.r + , + this.g + , + this.b+); }
}
document.body.style.backgroundColor = colorObject;
/script
It would seem somewhat expected that the colorObject's toString would
be called. The object's toString method would be called from the
internal ToString method.
I agree it seems useful to use ToString as a conversion method when an
argument of type DOMString is passed something that isn't a valid
DOMString value.
Null is not the same as no value. Null is a type, having one value:-
null. The value null is a primitive value in EcmaScript. It is the
only member of the Null type.
As far the the DOM spec goes the value null is a bit special. It isn't
simply a value valid for the Null type. null is also a valid value for
many other types. For example Node.insertBefore takes as a second
argument a Node, however passing null is a valid value to pass. So null
is a valid value for the type Node.
I argue that there is very strong indication in the spec that null is
also a valid value for the type DOMString. Camerons mail also supports this.
/ Jonas
/ Jonas
Re: [whatwg] WebIDL and HTML5
On Tue, Aug 26, 2008 at 1:04 PM, Andrew Oakley [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
You can assign the Array methods to the NodeList prototype, they're
generic.
I'm going to take slice as an example here - lets say you wanted the first n
nodes in a NodeList (no, I don't see how that would be useful, but lets
pretend that it is).
slice is often used for the purpose of creating a new Array based on
the NodeList.
Array.prototype.slice.call(nodeList);
- to obtain an array.
NodeList and Array are two separate beasts.
Array generics are useful, but provide mixed results in
implementations when using NodeList as the thisArg. For example:-
every, filter, forEach, reverse, some, sort, slice.
-only slice will work in IE and even that is now broken in IE8b1.
2) NodeList is an interface and should not have any implementation.
Even in browsers that expose a NodeList object, it cannot be
guaranteed
WebIDL is here to specify the behavior. In ECMAScript there is no such
thing as an interface, so WebIDL maps them to what it refers to as
interface objects and interface prototype objects. It would seem
reasonable that you cannot call functions on these objects directly, or that
functions could appear further down the prototype chain than is implied by
the IDL (as long as the function appears on all the relevant DOM objects).
In any case adding a new function should work if WebIDL has been followed.
EcmaScript doesn't have interfaces, but it does have objects.
Ducktyping is a common practice, and is why the Array generics are so
useful with NodeList (if IE had more robust Array methods). An
EcmaScript object that implements a dom interface would be provided by
the browser. The interface wouldn't have to be provided by the
browser. So, document.body should return an object that implements
Node, Element, HTMLBodyElement interfaces. There is no need for the
environment to modify those interfaces, and doing so could potentially
cause problems and make the web page less stable.
3) You answered a question for which no need was demonstrated, and
provided no example.
I could argue that there is no need for interactive web pages at all (they
tend to annoy me), but we want to be flexible.
Businesses want to make rich, featureful software-as-a-service. It is
a common business model and is very useful.
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.
I believe length is read-only on a NodeList, and assigning to read-only
members in ECMAScript fails silently. So we should carry on regardless.
You are partially correct. The correct part is that assigning a value
to a native EcmaScript object property that has the attribute ReadOnly
will fail silently, as per Ecma-262 r3, 8.6.2.2 [[Put]](P, V)[1]. For
example:-
Math.max.length = 10;
Math.max.length;
= 2
However, assigning to a readonly DOM property should raise a DOMException[2]*.
document.childNodes.length = 10;
Safari: No Error
Firefox: Error, setting a property that has only a getter.
Opera: DOMException: NO_MODIFICATION_ALLOWED
IE: I can't start windows :-(
Opera has the official standard behavior.
You are confusing DOM readonly and EcmaScript ReadOnly. These are not
the same ReadOnly.
* The one way to usurp that is in some cases for HTMLCollection, to
create a property with the name/id of the readonly property. For
example, to modify the length property of a form, create an element
with the name length and give it the value you desire. This is not
yet standard, but is implicitly specified in WF 2.0 WD, section 7.1.
This fails in Firefox. It is my opinion that it is a bad feature.
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.
OK, I'll agree that in general its a bad idea, and all hell breaks loose if
you have multiple windows. But it should be specified in WebIDL, and if the
document implies that it should work (which it does) and it is not a
requirement for it to work, then it should say so (and preferably explain
why).
Granting programs access to native interfaces makes the program less
stable. It also changes the meaning of the word interface to mean
something that I don't know what it is. For example, an Interface
cannot have a constructor, yet in WebIDL[4]:-
| An ECMAScript implementation supporting these interfaces
| would have a [[Construct]] property on the Circle interface
| object which would return a new object that implements the
| interface.
- defines a type of interface that implements [[Construct]].
Interfaces are used to describe objects. They should be flexible. They
should not provide any implementation. An object can be defined to
implement many interfaces and should not have any one of those
interfaces be a constructor.
Re: [whatwg] WebIDL and HTML5
One last time, the facts:
1) There are DOM methods that accept DOMString arguments or return
DOMString values.
Fact.
Sounds like you agree here.
2) In general, such methods need to be able to tell apart null and all
string values (including and null).
They need to determine value type so that they can either throw or
handle. null, 0, undefined, new String('x'), are all not strings.
Sounds like you agree here too?
3) The behavior of null is almost always either that of or that of
null. Which one depends on the exact DOM method.
That is false. null has no behavior. Methods have behavior. For
example, EcmaScript's internal ToString has a behavior of converting
null to null. That is a behavior.
You aren't actually answering Boris question, but rather point out a
grammatical error in the question. So let me repeat the question with
the grammatical error fixed. Please do excuse any other grammar errors I
introduce as English is a second language to me.
3) The behavior of the function when null is passed as value for an
argument is almost always either that of or that of null.
Which one depends on the exact DOM method.
Do you agree with this?
/ Jonas
Re: [whatwg] WebIDL and HTML5
On Aug 26, 2008, at 5:22 PM, Garrett Smith wrote: On Tue, Aug 26, 2008 at 4:47 PM, Jonas Sicking [EMAIL PROTECTED] wrote: So let me repeat the question with the grammatical error fixed. Please do excuse any other grammar errors I introduce as English is a second language to me. 3) The behavior of the function when null is passed as value for an argument is almost always either that of or that of null. Which one depends on the exact DOM method. Do you agree with this? No, I do not agree. If the parameter type is domstring, and null is not allowed, and the caller passes null, then the current behavior is implementation-dependent. 1) What DOM methods or attributes are specified to take a DOMString but disallow null? At least some DOM methods clearly specify how null should be treated when passed as the value for a DOMString parameter. There are also many DOM methods and attributes that are not specified anywhere (except perhaps in the unstable HTML5 Working Draft), which thus currently have implementation-defined behavior. And many other methods do not specifically say null is either allowed or disallowed, which would lead to the presumption that it is allowed, since the specification of other methods assumes it matches the DOMString type. I did not agree ever that should be used when null is passed as a value to an object that expects a string (or dom method that expects a domstring). I believe that in the following:- el.textContent = null; - with the options:- a) raise exception b) textContent is set to null c) textContent is set to Option (c) is wrong. Option (b) would be marginally useful in a few cases Option (a) would be helpful in some cases (finding bugs) Option (a) is unacceptable for the following reasons: 1) It does not match existing implementations and thus would likely break compatibility with existing content. 2) It violates the DOM Level 3 Core specification, which says: On setting, any possible children this node may have are removed and, if it the new string is not empty or null, replaced by a single Text node containing the string this attribute is set to. Thus, clearly assigning null to textContent must remove all children of the node. http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent In fact your option (c) appears to be mandated by the spec. Can you explain why you stated that it is wrong? Can you explain the reasoning behind your strongly held views on null used as a string parameter, since they do not seem to line up with either the DOM specifications or with existing implementations? I can sympathize with a desire for the handling for null to be clean and elegant, but unfortunately existing implementations, content and specs do not allow for such a possibility. Regards, Maciej
Re: [whatwg] WebIDL and HTML5
On Tue, Aug 26, 2008 at 6:52 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 26, 2008, at 5:22 PM, Garrett Smith wrote:
On Tue, Aug 26, 2008 at 4:47 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
So let me repeat the question with
the grammatical error fixed. Please do excuse any other grammar errors I
introduce as English is a second language to me.
3) The behavior of the function when null is passed as value for an
argument is almost always either that of or that of null.
Which one depends on the exact DOM method.
Do you agree with this?
No, I do not agree. If the parameter type is domstring, and null is
not allowed, and the caller passes null, then the current behavior is
implementation-dependent.
1) What DOM methods or attributes are specified to take a DOMString but
disallow null? At least some DOM methods clearly specify how null should be
treated when passed as the value for a DOMString parameter. There are also
many DOM methods and attributes that are not specified anywhere (except
perhaps in the unstable HTML5 Working Draft), which thus currently have
implementation-defined behavior. And many other methods do not specifically
say null is either allowed or disallowed, which would lead to the
presumption that it is allowed, since the specification of other methods
assumes it matches the DOMString type.
I did not agree ever that should be used
when null is passed as a value to an object that expects a string (or
dom method that expects a domstring). I believe that in the
following:-
el.textContent = null;
- with the options:-
a) raise exception
b) textContent is set to null
c) textContent is set to
Option (c) is wrong.
Option (b) would be marginally useful in a few cases
Option (a) would be helpful in some cases (finding bugs)
Option (a) is unacceptable for the following reasons:
1) It does not match existing implementations and thus would likely break
compatibility with existing content.
2) It violates the DOM Level 3 Core specification, which says: On setting,
any possible children this node may have are removed and, if it the new
string is not empty or null, replaced by a single Text node containing the
string this attribute is set to. Thus, clearly assigning null to
textContent must remove all children of the node.
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent
In fact your option (c) appears to be mandated by the spec. Can you explain
why you stated that it is wrong?
No, option (c) is not mandated by the spec. That is clearly not true.
| When it is defined to be null, setting it has no effect.
I don't agree that that is a good way to handle null, but it is clear
that these two:
document.body.textContent=null;
document.body.textContent='';
Are specified as being different from each other. They are different
because is the empty string and null is null. Agreed?
el.textContent = null won't work consistently across browsers. I would
argue that it ought to just set the textContent to null, since it
would make finding the bug easier. I say this because most programmers
who set textContent to null are doing so by accident, or are trying to
debug something, e.g.
var nodeRef = document.getElementById('invalid_id');
logger.log( nodeRef, INFO ), where log() sets the textContent
property of a node.
- where nodeRef could easily be null from the call to getElementById,
and would then create a problem with the logger where nothing was
logged. It would be possible to change the Recommendation. Setting
textContent = null is not something that has seen widespread use yet
and changing Firefox and Webkit implementations would be cumbersome.
It is probably at least as likely, if not more likely, that undefined
would end up as a value passed:-
var undef;
document.body.textContent=undef;
It would be somewhat useful if this were printed out as:-
undefined
being printed in the document.body.
Other considerations:-
el.textContent = new Date(); // Should it be calling toString()?
Can you explain the reasoning behind your strongly held views on null used
as a string parameter, since they do not seem to line up with either the DOM
specifications or with existing implementations? I can sympathize with a
desire for the handling for null to be clean and elegant, but unfortunately
existing implementations, content and specs do not allow for such a
possibility.
The spec you mention makes a misfortunate mistake, however, it is not
the mistake that I am concerned with at the moment. The mistakes that
I am more strongly opposed to is the creating of a serialize mapping
of null - .
As I have previously stated, it would be inconsistent to serialize
null to something other than null.
It would be OK for the method or setter to raise on null, or to have
specified behavior if null were passed in.
The mistake is the conversion of null to the empty string.
My view on passing null to DOM methods is inconsistent with the
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: Null is not the empty string. No one claimed that it was. A number of DOM methods are specified as treating them equivalently, however. -Boris
Re: [whatwg] WebIDL and HTML5
On Tue, Aug 26, 2008 at 8:04 PM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
Null is not the empty string.
No one claimed that it was. A number of DOM methods are specified as
treating them equivalently, however.
Well, I'm not so sure. I corresponded with Jonas who indicated that he
though null should convert to . Now Maciej seems to be confused
about textContent = null. The result should be no effect.
And we can see that the implementation of textContent = null feature
was not per spec in Firefox or Webkit, so it is apparently quite
confusing.
I have created a demo which expects that setting textContent to null
will have no effect, as per DOM Core 3. The deom does not take into my
opinion that setting textContent to null should result in the
textContent being null
!DOCTYPE HTML
html lang=en
head
titleSetting textContent to null/title
link rel=help
href=http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent/
link rel=author title=Garrett Smith href=mailto:[EMAIL PROTECTED]/
style type=text/css
#pass {
display: none;
background: #0F0;
}
#fail {
display: none;
background: #F00;
}
/style
/head
body
div id=elthis is the test node./div
script
var el = document.getElementById('el');
var orig = el.textContent;
function fail() {
var f = document.getElementById('fail');
var found = el.textContent;
f.style.display = inline-block;
f.textContent += : expected ' + orig + ' +
, found ' + found + ' ( + (typeof found) + );
}
function reset() {
el.textContent = orig;
}
clicks = [];
function checkPass(i) {
clicks[i] = 1;
if(clicks[1] clicks[2])
document.getElementById('pass').style.display = inline-block;
}
/script
button onclick=reset();el.textContent;el.textContent = null;
if(el.textContent!=orig)fail();else checkPass(1);el.textContent =
null/button
button onclick=reset();el.textContent =
'';checkPass(1);el.textContent = ''/button
button onclick=reset();el.textContent = undefined;el.textContent =
undefined/button
div id=failFAIL/div
/body
/html
Results:
Firefox 3.1, Webkit
FAIL: expected 'this is the test node.', found '' (string)
Opera:
FAIL: expected 'this is the test node.', found 'null' (string)
I feel that Opera's behavior is ideal, even though it is non-standard.
I would like to ask that the DOM 3 recommendation to be changed so
that setting textContent = null sets the textContent to have the
string value null. Reasons:
1) Widespread inconsistencies.
2) A feature not relied on (likely to break few, if any existing sites)
3) Would make debugging easier
Garrett
-Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: 2) It violates the DOM Level 3 Core specification, which says: On setting, any possible children this node may have are removed and, if it the new string is not empty or null, replaced by a single Text node containing the string this attribute is set to. Thus, clearly assigning null to textContent must remove all children of the node. http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent In fact your option (c) appears to be mandated by the spec. Can you explain why you stated that it is wrong? No, option (c) is not mandated by the spec. That is clearly not true. I'm a little confused here. The spec in question clearly requires that for this method and null be treated identically. So what's clearly not true, exactly? I don't agree that that is a good way to handle null, but it is clear that these two: document.body.textContent=null; document.body.textContent=''; Are specified as being different from each other. How so? Both remove all the existing kids. Neither does anything else. How do they differ? They are different because is the empty string and null is null. Agreed? Agreed that is the empty string and null is null. I don't see how that implies anything about the behavior of textContent, on its own. el.textContent = null won't work consistently across browsers. Sure it will, if the browsers implement what the spec clearly says to do. I would argue that it ought to just set the textContent to null That would be a spec change, but yes, the spec could be changed. Except for that little matter of backwards compat, etc. The spec you mention makes a misfortunate mistake, That's not really the subject of discussion here. Given what the DOM specs say (and which can't be changed), how do we best express that in IDL in all cases, instead of relying on normative prose? That's the question on the table. -Boris P.S. One thing I should note... the DOM spec is meant to be language-agnostic. There are plenty of languages in which the Null value, whatever it is, is an instance of all classes or can be used for all sorts of types. For example, one can have a NULL char* in C, or a Null String in Java. The fact that this can't happen in ECMAScript doesn't mean that the DOM doesn't make use of null DOMStrings. It also doesn't mean that the null value necessarily needs to be converted to an ECMAScript string before being passed across language boundaries. But in practice, a lot of DOM methods define the behavior when passed the null DOMString as being equivalent to either the behavior when passed or the behavior when passed null or the behavior when passed neither. It would be very useful to have a way to tell these cases apart just by looking at the IDL, without reading all the prose. I realize your argument is that we should change all of the DOM to never do anything special with null DOMStrings, simply because ECMAScript doesn't have such a thing, but that ship sailed long ago when the DOM specs were decided on and specified in a language-agnostic manner.
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: Well, I'm not so sure. I corresponded with Jonas who indicated that he though null should convert to . Jonas was saying that the default behavior for a DOM method passed a null DOMString should be the same as the behavior if passed . That's not the same as saying that null is . Now Maciej seems to be confused about textContent = null. I didn't see any confusion there (well, except on your part). And we can see that the implementation of textContent = null feature was not per spec in Firefox or Webkit, so it is apparently quite confusing. Er... how so, exactly? I have created a demo which expects that setting textContent to null will have no effect, as per DOM Core 3. Except that's not what DOM Core 3 says. Please do read what it says. Carefully: On setting, any possible children this node may have are removed and, if it the new string is not empty or null, replaced by a single Text node containing the string this attribute is set to. So. On setting all children are removed. If the string is not empty or null, they are then replaced by a single Text node, etc. If it's empty or null, the kids are removed and that's it. It would perhaps help to write this out as a step-by-step list instead of having a moderately complex grammatical structure with a subordinate clause, but the meaning is still the same. As for your test, sounds to me like Firefox and Webkit implement what the spec says, and Opera is just buggy here. -Boris
Re: [whatwg] WebIDL and HTML5
On Aug 26, 2008, at 7:31 PM, Garrett Smith wrote: Option (a) is unacceptable for the following reasons: 1) It does not match existing implementations and thus would likely break compatibility with existing content. 2) It violates the DOM Level 3 Core specification, which says: On setting, any possible children this node may have are removed and, if it the new string is not empty or null, replaced by a single Text node containing the string this attribute is set to. Thus, clearly assigning null to textContent must remove all children of the node. http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent In fact your option (c) appears to be mandated by the spec. Can you explain why you stated that it is wrong? No, option (c) is not mandated by the spec. That is clearly not true. | When it is defined to be null, setting it has no effect. I think you are misreading the spec. When it is defined to be null is not referring to assigning a value of null. It is referring to nodeTypes where textContent is null by definition, namely DOCUMENT_NODE, DOCUMENT_TYPE_NODE and NOTATION_NODE. Your interpretation does not make sense, because it would make the spec self-contradictory (it would both say setting to null has no effect, and describe the particular effect when setting to nul). I don't agree that that is a good way to handle null, but it is clear that these two: document.body.textContent=null; document.body.textContent=''; Are specified as being different from each other. They are different because is the empty string and null is null. Agreed? No, the spec requires the identical behavior for both. Please read again. el.textContent = null won't work consistently across browsers. I would argue that it ought to just set the textContent to null, since it would make finding the bug easier. So you are suggesting changing the requirements of the DOM 3 Core spec, as well as all existing implementations thereof? Such an extreme move would require extraordinary levels of justification. Can you explain the reasoning behind your strongly held views on null used as a string parameter, since they do not seem to line up with either the DOM specifications or with existing implementations? I can sympathize with a desire for the handling for null to be clean and elegant, but unfortunately existing implementations, content and specs do not allow for such a possibility. The spec you mention makes a misfortunate mistake, however, it is not the mistake that I am concerned with at the moment. The mistakes that I am more strongly opposed to is the creating of a serialize mapping of null - . As I have previously stated, it would be inconsistent to serialize null to something other than null. Unfortunately, many DOM methods as specified and widespread DOM extensions as implemented treat null and the same for many string arguments. It's true that this is inconsistent with the normal rules of the ECMAScript language. Because we seek to preserve compatibility with the Web and continuity with past specifications, the following are not viable options: - Treating null as the string null in cases where it currently is treated as empty string. - Raising an exception when null is passed for a parameter that expects a string, when currently an exception would not be raised. I think it is a waste of time to discuss these options further, since neither the Working Group nor implementors will be open to breaking Web compatibility in this way. Regards, Maciej
Re: [whatwg] WebIDL and HTML5
On Aug 26, 2008, at 8:12 PM, Garrett Smith wrote: On Tue, Aug 26, 2008 at 8:04 PM, Boris Zbarsky [EMAIL PROTECTED] wrote: Garrett Smith wrote: Null is not the empty string. No one claimed that it was. A number of DOM methods are specified as treating them equivalently, however. Well, I'm not so sure. I corresponded with Jonas who indicated that he though null should convert to . Now Maciej seems to be confused about textContent = null. The result should be no effect. No, you read the spec wrong. If you are going to be pendantic and criticize others for trivial errors, you should take more care to verify your claims. Regards, Maciej
