On Wed, Aug 27, 2008 at 5:13 PM, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
Java does not include null value for String type. You can ignore the
null type and just pretend that null can be of any reference type, but
that does not make null a string.
Any Java method that
Garrett Smith wrote:
Any Java method that takes a String can have null passed to it.
Yes, and this is true for any reference type, not only String.
Yep. Point is, DOMString is defined as a reference type.
Are you concerned with what can be passed to a method, or what is a String?
The
On Tue, 26 Aug 2008 23:20:16 -0400, Boris Zbarsky [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
I have created a demo which expects that setting textContent to null
will have no effect, as per DOM Core 3.
Except that's not what DOM Core 3 says. Please do read what it says.
Carefully:
Garrett Smith:
Granting programs access to native interfaces makes the program less
stable. It also changes the meaning of the word interface to mean
something that I don't know what it is. For example, an Interface
cannot have a constructor, yet in WebIDL[4]:-
| An ECMAScript
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
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?
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?
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
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
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
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)
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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);
//
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
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
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)
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
45 matches
Mail list logo
