subject:"\[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

2008-08-27 Thread Jonas Sicking



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

2008-08-27 Thread Michael A. Puls II



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

2008-08-27 Thread Cameron McCormack


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

2008-08-27 Thread Maciej Stachowiak




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

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Jonas Sicking



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: [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

2008-08-26 Thread Jonas Sicking



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

2008-08-26 Thread Jonas Sicking




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

2008-08-26 Thread Maciej Stachowiak

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

2008-08-26 Thread Maciej Stachowiak




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

2008-08-26 Thread Maciej Stachowiak




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

[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

2008-08-25 Thread Boris Zbarsky



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

2008-08-25 Thread Boris Zbarsky



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

2008-08-25 Thread Boris Zbarsky



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

2008-08-25 Thread Jonas Sicking



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