Re: [whatwg] WebIDL and HTML5
On Tue, 26 Aug 2008 23:20:16 -0400, Boris Zbarsky [EMAIL PROTECTED] wrote: Garrett Smith wrote: 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. Couple examples: Example 1: var div = document.createElement(div); div.textContent = null; 'textContent' takes a DOMString, null is not one, null is toString()ed to null and the textContent becomes null. Example 2: var div = document.getElementsByTagName(div)[0]; div.style.display = none; div.style.display = null; 'display' takes a DOMString, null is not one, null is toString()ed to null and since null is not a valid value for the display property, the new declaration is ignored and the display remains at 'none'. I know Opera differs in these cases compared to Safari and Firefox, but from an ECMAScript point of view, Opera does what I expect. With that said, if that's a behavior of ECMAScript and the DOM spec clashes, which one gets priority and in what situations and why? Although I understand why it might be desired to have null have the same effect as , it seems odd to be so inconsistent across different things in the DOM and inconsistent with ECMAScript (which exposes the DOM to users, in browsers). It'd be nice if the behavior was the same for all DOM things taking a DOMString. But, since that probably can't happen because of compatibility, I guess it would be great to have a way to show each and every special case so browsers don't differ and break pages. -- Michael
Re: [whatwg] WebIDL and HTML5
Garrett Smith: 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. The term I’ve used is “interface object”, not “interface”. It’s an object that provides access to functionality related to that IDL interface. You can think of an interface object with [[Construct]] as being also a factory object for that interface, that happens to allow the use of 'new' in ES to invoke the factory method. -- Cameron McCormack ≝ http://mcc.id.au/
Sound quality; widget signatures
Art, the sound quality of the meeting is bad enough that I can't usefully participate. I'll be happy to review the editor's draft after the meeting, and (given the topics covered) would recommend that you ask for review by WSC and xmlsec. I'll be happy to help enlist a review from at least one of the two groups. Sorry, and regards, -- Thomas Roessler, W3C [EMAIL PROTECTED]
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: I do not see where the spec describes the particular effect when setting to nul. Maciej quoted the exact text. So did I. I suggest selecting that text, copying it, going to your browser, opening up the find dialog or equivalent, pasting it, and thus getting to see where it is in the spec. Or you could actually read the section on textContent in DOM3 Core... Whichever. I don't see it. Where does it say null is converted to the empty string? See above. It doesn't say null is converted to the empty string. It says that the empty string and null behave the same when assigned to textContent. I do see some discussion of null being differentiated from empty strings: Yes, indeed. And that discussion talks about what to do with that case. Again, no one claims that null is . But they have to be treated the same way in some cases. | 1.3.3 XML Namespaces | In programming languages where empty strings can be | differentiated from null, empty strings, when given as a | namespace URI, are converted to null. Like in this case. | Setting the prefix to null makes it unspecified, setting it to | an empty string is implementation dependent. Indeed. In this case, no mapping is defined by the idl (though ideally this would not have the implementation-dependent thing and just define behavior, period). | Note that when using the methods that take a feature and a | version as parameters, applications can use null or empty | string for the version parameter Right. And the behavior must be the same whether null or is used. I've explained numerous times that null is not a string value. In the DOM, it is. This isn't called out explicitly in the DOMString definition, but it's assumed de-facto throughout the DOM specs. Note that I'm not saying this is necessarily a good thing. It's just a fact we have to live with. Treating null as the empty string is not consistent with the language. The language? The DOM is language-agnostic. A method that has special behavior for null would be fine. Indeed. The DOM is full of such methods. The special behavior could be throwing an exception (might help find bugs), or creating a string from the argument, in the given language; that would be null in EcmaScript and Java. A number of DOM methods define the special behavior to be 'treat the argument as '. Why exactly do you have a problem with accepting this given the numerous examples in the spec? Put another way, what do _you_ think createElementNS is saying to do with the namespaceURI argument? Creating mappings for methods where null=Empty, null=null is chatty. It's not consistent with what developers would naturally expect in EcmaScript. Sure. No one _likes_ having to do this. But changing the way the DOM works is not an option, so we're kind of stuck with it. And again, there's more to the DOM than just ECMAScript (sadly, in some ways, from an ECMAScript point of view). I would more rather you try to understand the reasoning. I think we understand your reasoning. You, on the other hand, seem to have trouble understanding... Again, in simple terms: 1) The DOM defines certain behavior. 2) Changing this behavior is not an option. 3) It would be good to express this behavior explicitly in the IDL so that it's easy to machine-generate DOM bindings and for improved interoperability. Which part of that doesn't make sense? Get some rest. We don't have to come to an agreement right away. Honestly, I don't see how we can come to an agreement when you fundamentally won't accept basic premises like the DOM Core specs are not up for change in this discussion. And honestly, trying to explain things to you is starting to look like a total waste of time. -Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote:
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.
I don't see it. Where does it say null is converted to the empty string?
It does not say to convert null to the empty string no, you are entirely
correct there. What it does do though is describe what happens when you
set textContent to null:
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 it says to first remove all children, and then do nothing more. Do
you share this interpretation for this one attribute?
So at this point I want to ask though: What is your proposal?
What do you propose should happen when an attribute like
attribute DOMString nodeValue;
is set using the following ECMAScript code:
myNode.nodeValue = hello;
myNode.nodeValue = ;
myNode.nodeValue = 0;
myNode.nodeValue = 10.2;
myNode.nodeValue = { toString: function() { return str; } };
myNode.nodeValue = new Date();
myNode.nodeValue = null;
myNode.nodeValue = undefined;
myNode.nodeValue = myNode;
where myNode points to a textnode. Note that 'throw an exception' is a
valid answer. In that case ideally also specify the exception to be
thrown if you have an opinion.
Note that the lines should be considered separate from each other. So if
for example the second line throws I am still interested to hear what
the third line does etc.
Extra interesting would be to hear motivation on why you think the
behavior you describe is the appropriate one.
Best Regards,
Jonas
Re: [whatwg] WebIDL and HTML5
On Wed, Aug 27, 2008 at 9:44 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
So it says to first remove all children, and then do nothing more. Do you
share this interpretation for this one attribute?
Yes.
So at this point I want to ask though: What is your proposal?
Walk away from the argument.
I contend that the textContent example is not designed in a useful
manner and that having null - sometimes and null - null others
introduces complexity. I see this influence in Pro JavaScript
Techniques:
| In JavaScript, null, 0, '', false, and undefined are all equal (==)
| to each other...
(though slightly out of context, it is in similar vain)
Of course IDL is language-agnostic. It was a proposal to leave the
serializing of null to a language, so that languages that treat null
as can do so.
What do you propose should happen when an attribute like
attribute DOMString nodeValue;
is set using the following ECMAScript code:
myNode.nodeValue = hello;
myNode.nodeValue = ;
myNode.nodeValue = 0;
myNode.nodeValue = 10.2;
myNode.nodeValue = { toString: function() { return str; } };
myNode.nodeValue = new Date();
myNode.nodeValue = null;
myNode.nodeValue = undefined;
myNode.nodeValue = myNode;
where myNode points to a textnode. Note that 'throw an exception' is a valid
answer. In that case ideally also specify the exception to be thrown if you
have an opinion.
No specification is needed for ' or hello.
Should the others be implementation-dependent, or should they be
standardized/specified to throw/handle?
Andrew Oakley seemed to be of the opinion that WebIDL should specify
what type conversions may or may not happen.
In IE throws an error with - style.color = obj - which might seem
surprising, but does not pose a serious problem. Easy to notice and
very easy to code around.
Conversion of numbers where a string is expected works in the browsers
I've tried.
If there were serialization plans for each value type, and they varied
across methods, it would be confusing and complex. However, if there
were a string conversion function that could be applied, and it would
not break sites, and would meet reasonable expectations, and not
create browser compatibility issues, that would be good.
Using EcmaScript's ToString, the result would be:-
myNode.nodeValue = hello; // hello (already specified)
myNode.nodeValue = ; // (already specified)
myNode.nodeValue = 0; // 0
myNode.nodeValue = 10.2; // 10.2
myNode.nodeValue = { toString: function() { return str; } }; // str
myNode.nodeValue = new Date(); // result (new Date).toString()
myNode.nodeValue = null; // null
myNode.nodeValue = undefined; // undefined
myNode.nodeValue = myNode; // result String( myNode );
Does this behavior seem reasonable? Consider that the setting of
myNode.nodeValue = null has the result:
Opera:
null
Firefox, Webkit,
and for myNode.nodeValue = undefined
IE:
FF, Op, Safari,
undefined
The following example demonstrates a comparison between a command
above, and calling String() for a command above. The intent is to
observe the difference between the string conversion handled by the
dom setter and the string conversion performed by calling String on
that same argument.
!DOCTYPE HTML
html lang=en
head
titlenodeValue -gt, ToString/title
/head
body
button onclick='next()'next()/button
divactual: span id=outxxxspan/div
divToString: span id='ToString'xxx/span/div
script
var d = document,
o = { toString: function() { return str } },
myNode = d.getElementById('out').firstChild,
ToString = d.getElementById('ToString').firstChild;
var i = 0,
cmds = [hello, , 0, 10.2, o, new Date, null, undefined, myNode ];
function next() {
if(i == cmds.length-1) return;
myNode.nodeValue = cmds[i];
ToString.nodeValue = String(cmds[i]);
i++;
}
/script
/body
/html
The result of setting nodeValue is the same as setting
String(nodeValue), except for the case null.
For null
Firefox, Webkit:
Opera, MSIE:
null
for undefined:
Firefox, Webkit, Opera
undefined
MSIE
I keep having problems starting windows. Insufficient system
resources for the API. Not enough virtual memory. Errors.
Garrett
Note that the lines should be considered separate from each other. So if for
example the second line throws I am still interested to hear what the third
line does etc.
Nothing throws in any browser, but the test is far from exhaustive to
make a standard.
Extra interesting would be to hear motivation on why you think the behavior
you describe is the appropriate one.
Well they're all non-standard.
It seems to be an expectation among some that object would be
converted to a string:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/788d0d6e130d51a4/7ccea2f5a7226d65?lnk=gstq=new+color+library+tostring#7ccea2f5a7226d65
I experienced the same thing Jeff did - setting a color to an object
causes an error in IE. IE's behavior is valid and is not
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: I contend that the textContent example is not designed in a useful manner and that having null - sometimes and null - null others introduces complexity. Sure. And we're stuck with this complexity. Now where do we go from here? -Boris
Re: [whatwg] WebIDL and HTML5
On Wed, Aug 27, 2008 at 11:58 AM, Boris Zbarsky [EMAIL PROTECTED] wrote: Garrett Smith wrote: I contend that the textContent example is not designed in a useful manner and that having null - sometimes and null - null others introduces complexity. Sure. And we're stuck with this complexity. Now where do we go from here? Having specifications that mention null's special behavior, but having that behavior vary has caused problems. Given that, I suggest moving forward: Test, then document those methods as having special behavior. Do this not by a null-value mapping, but by documenting the method's algorithm in simple terms. e.g. if X is not a string, throw an error Make a decision for either (1) null and other non-string values are handled or (2) leave the behavior implementation-dependent. I would say (1) is somewhat desirable. Sites that rely on things like input.value = 12; style.height = 0. If it is decided that handling non-string values for dynamic languages (EcmaScript) should be standardized, then methods that handle non-string values should be tested using non-string values (in EcmaScript, that includes an Object and 4 other primitives). For exampe:- input.value = null; Firefox: Opera null Safari: depending on the type of input, use defaultValue or remove the attribute. IE: Windows won't start (Opera often has the same result as IE) Testing would indicate where handling of some values, especially null, is not consistent. Edge cases with null will usually be a programmer accident. spec-correction http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent The textContent documentation seems a bit off. | 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. This would be the following pseudocode: If newString !== || newString === null Then // replace by a Text node containing newString I now realize that this is interpreted as: If not newString === and not newString === null Then // replace by a Text node containing newString Could be written as: | Setting: | Remove all children of this node. | If inputString is null or empty, return. | append a single Text node containing the inputString. Aside from that, there is the error: if it the new string. The sentence would be more clearly broken into two sentences using positive, not negative conditions. /spec-correction Garrett -Boris
Re: [whatwg] WebIDL and HTML5
On Wed, 27 Aug 2008 08:34:03 -0400, Boris Zbarsky [EMAIL PROTECTED] wrote: Michael A. Puls II wrote: 'textContent' takes a DOMString, null is not one Uh... Except null IS a DOMString according to the DOM specs. Certainly they implicitly treat it as one, and one of the clarifications that WebIDL is making is making it clearer that null is a valid DOMString value. null is toString()ed to null and the textContent becomes null. Except that's not what the spec for textContent says to do. Please do read the spec. Carefully. Yes, understood. Those were just my guesses for reasons why Opera does what it does. I know Opera differs in these cases compared to Safari and Firefox, but from an ECMAScript point of view, Opera does what I expect. But it doesn't do what the DOM spec says to do in the textContent case. Sad, but there you are. Understood. With that said, if that's a behavior of ECMAScript and the DOM spec clashes, which one gets priority and in what situations and why? The DOM spec gets priority for methods it defines, just like in all cases of host objects and methods. There are no requirements for those to follow all sorts of rules that native methods and objects have to follow. See the ECMAScript spec. O.K. Thanks. That clears it up right there. Although I understand why it might be desired to have null have the same effect as , it seems odd to be so inconsistent across different things in the DOM and inconsistent with ECMAScript (which exposes the DOM to users, in browsers). It _is_ odd. But it's an established fact of life, and changing that behavior is not acceptable at this point. Understood. Too bad no one brought all this up back when the DOM specs were being written. Or maybe they did, and the non-ECMAScript users of the DOM carried the day on the issue. Again, in other languages the fact that null is a string is much more natural than in ECMAScript. Yes, too bad. Thanks -- Michael
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: Given that, I suggest moving forward: Test, then document those methods as having special behavior. Do this not by a null-value mapping, but by documenting the method's algorithm in simple terms. e.g. if X is not a string, throw an error But giving a (per-method) mapping means that the algorithm can then be machine-generated from the IDL, which is an interoperability win: less chance of a mistake being made. So why are you opposed to having such per-method mappings, as needed? -Boris
Re: [whatwg] WebIDL and HTML5
On Wed, Aug 27, 2008 at 2:39 PM, Boris Zbarsky [EMAIL PROTECTED] wrote: Garrett Smith wrote: Given that, I suggest moving forward: Test, then document those methods as having special behavior. Do this not by a null-value mapping, but by documenting the method's algorithm in simple terms. e.g. if X is not a string, throw an error But giving a (per-method) mapping means that the algorithm can then be machine-generated from the IDL, which is an interoperability win: less chance of a mistake being made. So why are you opposed to having such per-method mappings, as needed? I can appreciate the desire to make the task of implementing the spec in an automated fashion. That is a desire, however, not a need. What I opposed is calling null a string. Null is not a string by the definition in the DOM 3 spec[1]. A String variable, in Java, can have the value null, but this can be determined: if(s == null). However, WebIDL does lump null into domstring. What WebIDL does creates compatibility issues in an attempt to standardize bugs. Moving forward, if null is allowed, it should not be called a string. However, if only a DOMString is allowed, and null is passed, it should not require a one-off mapping. Garrett [1] DOM3 domstring http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-C74D1578 [2] WebIDL domstring http://dev.w3.org/2006/webapi/WebIDL/#idl-DOMString -Boris
Re: [whatwg] WebIDL and HTML5
On Wed, Aug 27, 2008 at 2:49 PM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
So is everything else. This particular desire has great benefits, however,
so it needs to have great drawbacks as well to not be done, right?
The drawback would be inconsistency with current implementations and
with the behavior that developers might naturally expect. (the
unnatural expectation that null is converted to in some default
mapping appendix).
What I opposed is calling null a string. Null is not a string by the
definition in the DOM 3 spec[1]
(You linked to the DOM2 spec, but DOM3 says the same thing.)
That definition does not necessarily preclude null being considered a
DOMString, and in fact parts of the spec consider it so. I'm honestly a
little confused why you care so much about what something is called as
opposed to what it does. The latter is what really matters.
I disagree. That the DOM spec does not include null. It is very
verbose on what it does include, so it's not by accident.
I believe that null should be handled based on what it is.
However, WebIDL does lump null into domstring.
Yes, because de-facto DOM does this already.
My examples clearly show otherwise. null is handled differently in
Firefox, [Opera/IE], Safari, depending on what DOM method /property it
is used for.
input type=submit id='xx' value=go
document.getElementById('xx').value = null
Will result in:
Opera setting the value to null
Safari removing the attribute
Firefox sets the attribute to
IE: Windows will not start again :-(
My examples show that there is non-standard behavior that is handled
differently in different browsers. The way to standardize that is not
to call the value null a string with a special value.
What WebIDL does creates compatibility issues in an attempt to standardize
bugs.
It doesn't create any issues that were not there.
Moving forward, if null is allowed, it should not be called a string.
Moving forward doesn't help with the existing DOM interfaces, which
certainly allow passing null for a DOMString.
That is true. There are methods that discuss what happens when you
pass null to a method that accepts a domstring.
However, if only a DOMString is allowed, and null is passed, it should
not require a one-off mapping.
Ideally, yes. That's why there should be a default mapping, with one-offs
flagged as needed (ideally rarely).
I see. Well, I can just avoid the problem by always using strings
where domstring is required.
-Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith: I disagree. That the DOM spec does not include null. It is very verbose on what it does include, so it's not by accident. The fact that a boxed valuetype (in OMG IDL) was used to define the DOMString type leads me to believe that null was explicitly wanted as a member of that type. That’s different from dom Level 1 Core, where it was just a typedef: http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-C74D1578 Since there are some languages that include null in their string type and others that don’t, and with DOM meant to be language agnostic, it probably made more sense to define the DOM string type as including null than not. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: If I'm reading the right spec[1], OMG IDL defines the string type string consisting of all possible 8-bit quantities except null. DOMString isn't an OMG IDL String. It's defined as [1]: valuetype DOMString sequenceunsigned short; And no, I'm not sure you're looking at the right spec. The right thing would seem to be http://www.omg.org/docs/formal/02-06-39.pdf which says: value_box_dcl ::=“valuetype” identifier type_spec Section 3.9.2 of this document then says: It is often convenient to define a value type with no inheritance or operations and with a single state member. A shorthand IDL notation is used to simplify the use of value types for this kind of simple containment, referred to as a “value box.” In other words, the syntax above defines a kind of value type. Looking to http://www.omg.org/docs/formal/02-06-41.pdf to see what the semantics of value types are, we see the following (section 5.2): There are two kinds of value types, concrete (or stateful) value types, and abstract (stateless) ones. Note that DOMString is a concrete value type (since there is no abstract keyword in its definition). Section 5.2 goes on to say: Concrete (stateful) values add to the expressive power of (IDL) structs by supporting: ... * null value semantics Section 5.2.4.2 is even more explicit: In order to be expressive enough to describe arbitrary graphs, lattice, trees etc., value types support sharing and null semantics. Instances of a value type can be shared by others across or within other instances. They can also be null. This is unlike other IDL data types such as structs, unions, and sequences that can never be shared. Contrast this with the DOM1 DOMString definition, which is: typedef sequenceunsigned short DOMString; This does not allow null values, since it's a sequence, not a new type. But again, the DOM2/3 definition is: valuetype DOMString sequenceunsigned short; Which declares a new type which contains a sequence. The type is not _itself_ a sequence, but a container for a sequence. It can be null (which means doesn't contain any sequence, as far as I can tell from these specs). -Boris [1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMString Which languages include the value null in their string type? I already mentioned Java and C/C++ earlier. There are plenty of others. -Boris
Re: [whatwg] WebIDL and HTML5
On Wed, Aug 27, 2008 at 4:39 PM, Boris Zbarsky [EMAIL PROTECTED] wrote: Garrett Smith wrote: So is everything else. This particular desire has great benefits, however, so it needs to have great drawbacks as well to not be done, right? That's an issue even if it's just the spec text that says that null is treated in a special way. There was a proposal to treat null in a language-dependent manner. Developers of EcmaScript could reasonably expect null maps to null. Again, what is your specific problem with the specific approach of annotating null/undefined conversions as opposed to just describing them in the spec text? I disagree. That the DOM spec does not include null. It is very verbose on what it does include, so it's not by accident. Then how do you account for all the places in the same spec that talk about passing null to DOMString arguments? I believe that null should be handled based on what it is. That's fine. How is it compatible with the existing specs? It is not compatible? Where? How? A spec mentioning null for a method that accepts a string does not make null a string. It means they mentioned null, probably to appease Java programmers' concern for when to throw npe or raise analagous DOMException. Yes, because de-facto DOM does this already. what is de-facto DOM? You mean browsers? Browsers are totally inconsistent with each other with null. My examples clearly show otherwise. null is handled differently in Firefox, [Opera/IE], Safari, depending on what DOM method /property it is used for. I don't see what that has to do with my statement above, that de-facto DOM method specifications assume that null can be passed for a DOMString and that a number of DOM methods specify what should be done in that case. That the specs talk about what happens in the event that a null slips doesn't change what a string is. The spec discussing null does not change what null is or what a string is. Why do the specs mention that? Who knows. They might mention this case because this can happen in Java and they wanted to address that. The spec mentions that domstring maps to Java string, so they did consider Java. A String variable can have the null value in Java. The fact that the Java compiler lets this happen does not mean that the variables value is a string. It's still null. Honestly, you can stop copy/pasting the same examples in. We've seen them. That was a new example I posted. That is true. There are methods that discuss what happens when you pass null to a method that accepts a domstring. Right. That discussion is what should be moved into IDL annotations. Each method should not be moved to IDL. I can understand that you want to think of null as a String. I'm going to give this a rest because it's wearing me out. Null is not a string. I am capable of using string value where domstring is required. Garrett -Boris
Re: [whatwg] WebIDL and HTML5
Garrett Smith wrote: It is not compatible? Where? How? Node.textContent. A spec mentioning null for a method that accepts a string does not make null a string. See long post with an analysis of the exact OMG IDL meaning of the DOMString type (which is NOT quite the same as ECMAScript string, note). what is de-facto DOM? You mean browsers? Browsers are totally inconsistent with each other with null. de-facto in this case means existing DOM method definitions. That the specs talk about what happens in the event that a null slips doesn't change what a string is. Please divorce the idea of DOMString and ECMAScript string in your mind. They're not the same thing. That was a new example I posted. Not really. It basically showed the same default conversions as the other examples. Right. That discussion is what should be moved into IDL annotations. Each method should not be moved to IDL. I must be missing something here. What do you mean, exactly? I can understand that you want to think of null as a String. No. I want to think of null as a DOMString. Please see the definition of DOMString again. Null is not a string. It's not an ECMAScript string. It is a DOMString. I am capable of using string value where domstring is required. That's great, but I don't think we should be predicating the spec on the restrictions you're placing on yourself. -Boris
Re: [whatwg] WebIDL and HTML5
Boris Zbarsky wrote: See long post with an analysis of the exact OMG IDL meaning of the DOMString type (which is NOT quite the same as ECMAScript string, note). I should note that there is one thing adding to the confusion. The use of String in the ECMAScript language bindings for the DOM. If one takes this to mean the ECMAScript String built-in type, this is not consistent with the value type semantics DOMString has. The inconsistency can probably be resolved in a number of ways, including modifying the definition of DOMString, declaring that the ECMAScript binding of DOMString is a String object (result of new String(), not a String itself), or declaring that a DOMString can be either a String or null. This last is probably the most backwards-compatible. -Boris
Re: [whatwg] WebIDL and HTML5
On Aug 27, 2008, at 2:39 PM, Boris Zbarsky wrote: Garrett Smith wrote: Given that, I suggest moving forward: Test, then document those methods as having special behavior. Do this not by a null-value mapping, but by documenting the method's algorithm in simple terms. e.g. if X is not a string, throw an error But giving a (per-method) mapping means that the algorithm can then be machine-generated from the IDL, which is an interoperability win: less chance of a mistake being made. In fact, we already use such IDL annotations in WebKit and it has made our DOM bindings more consistent, more interoperable, and less prone to breaking through coding errors. I think it is a good model for the spec to do the same. - Maciej
Re: [whatwg] WebIDL and HTML5
On Wed, Aug 27, 2008 at 5:39 PM, Boris Zbarsky [EMAIL PROTECTED] wrote: Boris Zbarsky wrote: See long post with an analysis of the exact OMG IDL meaning of the DOMString type (which is NOT quite the same as ECMAScript string, note). I should note that there is one thing adding to the confusion. The use of String in the ECMAScript language bindings for the DOM. If one takes this to mean the ECMAScript String built-in type, this is not consistent with the value type semantics DOMString has. That would be true for the reason that null is not a string value. That would also be true of the built-in String Object type. The inconsistency can probably be resolved in a number of ways, including modifying the definition of DOMString, declaring that the ECMAScript binding of DOMString is a String object (result of new String(), not a String itself), That would seem to be inefficient. or declaring that a DOMString can be either a String or null. This last is probably the most backwards-compatible. Using null where a domstring is required is not widely compatible with existing implementations, including MSIE and Opera. In fact, you could say it's mostly unreliable. Webkit also has strange behavior with setting properties to null, where it can remove an attribute. If there is a desire to handle non-string values, then that handling should include null, which is a non-string value, both in Java and in EcmaScript. Garrett -Boris
