Re: [whatwg] getElementById
On Mon, 10 May 2010, Perry Smith wrote:
I see places that explicitly state that the same object is returned on
some operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is
referenced an explicit statement to this effect for getElementById.
getElementById() is a DOM Core method, so not defined by the HTML spec.
However, the DOM spec says it returns the Element, so that seems to
require that the same Element object representing the element be returned.
In practice there is always only one object per element anyway.
The other part to this that is not explicitly mentioned is if I attach a
new javascript attribute to the object, is that legal? Is it defined to
work? I have not found a statement one way or the other.
e.g.
foo = getElementById('foo');
foo.newAttr = true;
/* later */
foo = getElementById('foo');
if (foo.newAttr) {
alert(happy happy joy joy);
}
This would be defined by WebIDL.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementById
On May 10, 2010, at 10:54 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 8:28 PM, Perry Smith pedz...@gmail.com wrote:
snip
So, how about this?
As part of HTMLElement, have a defined bucket, maybe call it elementObject
which is defined to be a native ECMAScript object. If X denotes a
particular DOM element, then X.elementObject is defined to return the same
native ECMAScript object each time. More details could be added perhaps to
define how the object is created (i.e. which prototype to use, etc). I'm
thinking making it the same as {}.
WebIDL could require DOM objects to be implemented as native ECMAScript
objects.
To me, the host objects and the fact that they are mostly unspecified seems
rather critical and limiting. The getUserData seems terribly awkward and I
guess it suffers from portability issues as well.
Is WebIDL the best place to address this?
Thanks,
pedz
Re: [whatwg] getElementById
On Mon, May 10, 2010 at 9:10 PM, Perry Smith pedz...@gmail.com wrote: I see places that explicitly state that the same object is returned on some operations. For example, the element.style has that clause. I have not found in either html5 or the DOM documentation that is referenced an explicit statement to this effect for getElementById. if someone changes the id value on the node you used to think about and assigns it to another node then it most certainly will not return the same node.
Re: [whatwg] getElementById
On May 10, 2010, at 3:06 PM, timeless wrote:
On Mon, May 10, 2010 at 9:10 PM, Perry Smith pedz...@gmail.com wrote:
I see places that explicitly state that the same object is returned on some
operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is referenced
an explicit statement to this effect for getElementById.
if someone changes the id value on the node you used to think about
and assigns it to another node then it most certainly will not return
the same node.
Yea, that is an interesting point.
I wonder also if I change the id for the node to 'dog' and then do
getElementById('dog') if it will give me back the same javascript object with
newAttr set.
I am not sure if I am making myself clear. The question(s) boils down to, are
these objects going to behave consistently as javascript objects.
There are different ways the browser could implement the mapping from DOM
elements to javascript objects.
For example, the following code could fail and not give the alert box:
foo = getElementById('foo');
foo.newAttr = 1;
if (foo.newAttr)
alert(hi);
The setting of newAttr could simply not work at all. The browser could throw
it away. There is nothing I see that says that it must work. I say this
because there are particular methods and attributes defined. No mention is
made of other attributes. They could do anything including throw an exception,
silently fail, or randomly do something else.
I might have missed something obvious.
Perry
Re: [whatwg] getElementById
On May 10, 2010, at 7:04 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 4:55 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 5:12 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 2:27 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 3:06 PM, timeless wrote:
On Mon, May 10, 2010 at 9:10 PM, Perry Smith pedz...@gmail.com wrote:
I see places that explicitly state that the same object is returned on
some operations. For example, the element.style has that clause.
I have not found in either html5 or the DOM documentation that is
referenced an explicit statement to this effect for getElementById.
if someone changes the id value on the node you used to think about
and assigns it to another node then it most certainly will not return
the same node.
Yea, that is an interesting point.
I wonder also if I change the id for the node to 'dog' and then do
getElementById('dog') if it will give me back the same javascript object
with newAttr set.
Careful, it might actually not be a native ECMAScript object that you
get back. A host object could be implemented as a native ECMAScript
object, as seen in many implementations, but, as seen in recent
discussions, MSIE = 8 has host objects that are not native objects
and that do throw errors.
That is what I'm asking. I can't find where that is allowed (in the spec)
or not allowed in a conforming UA.
Any DOM object is a host object in ECMAScript parlance and host
objects have great liberty.
Look how IE's shoddy catchall implementation of the styleSheets dhtml
collection blows up on numeric [[Get]] access:
alert(document.styleSheets[9]); // Boom.
javascript: alert(document.styleSheets['a']); // OK
More indications on host objects in IE will show that they are not
native ECMAScript objects.
javascript: alert(document.body.valueOf); // undefined.
javascript: alert([].slice.call(document.childNodes)); // Boom.
I am not sure if I am making myself clear. The question(s) boils down to,
are these objects going to behave consistently as javascript objects.
There are different ways the browser could implement the mapping from DOM
elements to javascript objects.
For example, the following code could fail and not give the alert box:
foo = getElementById('foo');
foo.newAttr = 1;
if (foo.newAttr)
alert(hi);
The setting of newAttr could simply not work at all. The browser could
throw it away. There is nothing I see that says that it must work. I say
this because there are particular methods and attributes defined. No
mention is made of other attributes. They could do anything including
throw an exception, silently fail, or randomly do something else.
The code attempts to assign a property, not an attribute.
Setting a property such as newAttr is not specified. If it throws an
error or does nothing, it is your fault.
Ok. (Sorry for the incorrect use of terms.) If setting a property is not
specified, that means that a conforming UA can disallow setting properties.
Or it could silently ignore the attempt to set a property. Is that what was
intended?
Yes. An implementation can also throw errors with that. Nothing in
HTML 5 prevents that. Nothing in ECMAScript prevents that, for host
objects.
The browser can do whatever it wants with that property. Take a look
at MSIE document.expando.
Wow. I happened to pull down the ECMAScript 5 doc this past weekend to
understand exactly how an event handler is called. html5 refers to functions
defined in the ECMAScript doc. But I've never heard of host objects. The
first hit in the EMCAScript 5 doc for host object tells all. These guys did
not learn from the mistakes of Pascal. An utterly hopeless feeling came over
me.
So, how about this?
As part of HTMLElement, have a defined bucket, maybe call it elementObject
which is defined to be a native ECMAScript object. If X denotes a particular
DOM element, then X.elementObject is defined to return the same native
ECMAScript object each time. More details could be added perhaps to define how
the object is created (i.e. which prototype to use, etc). I'm thinking making
it the same as {}.
Re: [whatwg] getElementById
* Perry Smith wrote:
As part of HTMLElement, have a defined bucket, maybe call it
elementObject which is defined to be a native ECMAScript object. If X
denotes a particular DOM element, then X.elementObject is defined to
return the same native ECMAScript object each time. More details could
be added perhaps to define how the object is created (i.e. which
prototype to use, etc). I'm thinking making it the same as {}.
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-getUserData allows
you to associate user data with a DOM Node object with gurantees about
the availability of the data when a node is eg. cloned if used properly.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] getElementById
On Mon, May 10, 2010 at 8:28 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 7:04 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 4:55 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 5:12 PM, Garrett Smith wrote:
On Mon, May 10, 2010 at 2:27 PM, Perry Smith pedz...@gmail.com wrote:
On May 10, 2010, at 3:06 PM, timeless wrote:
On Mon, May 10, 2010 at 9:10 PM, Perry Smith pedz...@gmail.com wrote:
I see places that explicitly state that the same object is returned on
some operations. For example, the element.style has that clause.
[...]
The browser can do whatever it wants with that property. Take a look
at MSIE document.expando.
Wow. I happened to pull down the ECMAScript 5 doc this past weekend to
understand exactly how an event handler is called. html5 refers to functions
defined in the ECMAScript doc. But I've never heard of host objects. The
first hit in the EMCAScript 5 doc for host object tells all. These guys did
not learn from the mistakes of Pascal. An utterly hopeless feeling came over
me.
I see you've put our discussion back on list. I'm OK with that.
HTML 5 refers to ECMAScript for defining Function.
However ECMAScript does not specify anything about event handlers,
document, or any other host objects. An addition to the 5th edition,
and a very good one, is the requirement for host objects to implement
many of the semantics defined in the specification (see table 8).
The ECMAScript committee has some incredibly smart and hard working
individuals for whom I have a good deal of respect.
One thing not specified yet in ECMAScript is catchalls, and that is
necessary to implement some existing browser behavior that is
partially specified by HTML 5. Catchalls is an active proposal.
To learn more about Ecmascript, the es-discuss mailing list and
comp.lang.javascript may be of interest.
The pertinent section of the FAQ:
http://www.jibbering.com/faq/#objects
So, how about this?
As part of HTMLElement, have a defined bucket, maybe call it elementObject
which is defined to be a native ECMAScript object. If X denotes a particular
DOM element, then X.elementObject is defined to return the same native
ECMAScript object each time. More details could be added perhaps to define
how the object is created (i.e. which prototype to use, etc). I'm thinking
making it the same as {}.
WebIDL could require DOM objects to be implemented as native ECMAScript objects.
Re: [whatwg] getElementById
On Mon, May 10, 2010 at 8:35 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Perry Smith wrote: [...] http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-getUserData allows you to associate user data with a DOM Node object with gurantees about the availability of the data when a node is eg. cloned if used properly. Doesn't work cross browser.
