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 wrote: > >> 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 8:35 PM, Bjoern Hoehrmann 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.
Re: [whatwg] getElementById
On Mon, May 10, 2010 at 8:28 PM, Perry Smith wrote: > > On May 10, 2010, at 7:04 PM, Garrett Smith wrote: > >> On Mon, May 10, 2010 at 4:55 PM, Perry Smith wrote: >>> >>> On May 10, 2010, at 5:12 PM, Garrett Smith wrote: >>> On Mon, May 10, 2010 at 2:27 PM, Perry Smith wrote: > > On May 10, 2010, at 3:06 PM, timeless wrote: > >> On Mon, May 10, 2010 at 9:10 PM, 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. [...] >> 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
* 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 May 10, 2010, at 7:04 PM, Garrett Smith wrote: > On Mon, May 10, 2010 at 4:55 PM, Perry Smith wrote: >> >> On May 10, 2010, at 5:12 PM, Garrett Smith wrote: >> >>> On Mon, May 10, 2010 at 2:27 PM, Perry Smith wrote: On May 10, 2010, at 3:06 PM, timeless wrote: > On Mon, May 10, 2010 at 9:10 PM, 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. > > 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
On May 10, 2010, at 3:06 PM, timeless wrote: > On Mon, May 10, 2010 at 9:10 PM, 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. > > 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 Mon, May 10, 2010 at 9:10 PM, 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. 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.
[whatwg] getElementById
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. In FF 3.5, it seems to be true but it would be nice to know if it is or is not something that can be depended upon. 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"); } Thank you, Perry
[whatwg] getElementById and more same IDs
Hi, I think, the behaviour of getElementById for documents with more same IDs could be specified in HTML5. DOM2 Core leaves it undefined: "Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID." MSDN says about this: "Returns a reference to the first object with the specified value of the ID attribute." http://msdn2.microsoft.com/en-us/library/ms536437.aspx Seems for me browsers are doing same as MSDN for static pages, and this is probably the logical behaviour. I have even heard it returns the htmlcolection in some library, which sounds confusing. Martin Hassman