[whatwg] getElementById

[Perry Smith]

On May 10, 2010, at 7:04 PM, Garrett Smith wrote:

> On Mon, May 10, 2010 at 4:55 PM, Perry Smith <pedzsan at 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 <pedzsan at gmail.com> wrote:
>>>> 
>>>> On May 10, 2010, at 3:06 PM, timeless wrote:
>>>> 
>>>>> On Mon, May 10, 2010 at 9:10 PM, Perry Smith <pedzsan at 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[99999]); // 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 {}.