ES accessor usage guidelines (Was: Map/Set.prototype.size)

Brendan Eich brendan at
Mon Oct 15 21:20:30 PDT 2012

Allen Wirfs-Brock wrote:
> On Oct 15, 2012, at 2:41 PM, Brendan Eich wrote:
>> Yehuda Katz wrote:
>>>     * get/set accessor may have effects on 'set' (see the DOM) but
>>>     only on the receiver object (and unobservably, any children that
>>>     become garbage, e.g. when trimming .length on an array-like).
>>> DOM methods like `innerHTML=` seem to violate this particular wording (but perhaps not the spirit?)
>> Definitely the spirit!
>> That's one of those "children become garbage" cases, unless I misunderstand your point. "The receiver" for .innerHTML includes all descendants.
> It may be observable in another way:
> capture a reference to an existing inner element, then use innerHTML to change the parent element's  inner element collection.  Then use the original captured reference to navigate to its original parent.  I'm not sure what innerHTML actually does in this case,

This test:

     function doit() {
         var x = document.getElementById('x');
         var y = document.getElementById('y');
         x.innerHTML = "<div id='z'>bye!</div>";
<body onload="doit()">
<div id="x">
         Hi <div id="y">there</div>



then alerts

[object HTMLDivElement]

and then (once you dismiss that alert) displays


and alerts


So you're right, orphaned children suffer mutation to null .parentNode 
-- legacy feature indeed!

>   but most alternatives would make it either directly or indirectly observable  via the captured element reference that the original parent has been modified via innerHTML.
> By my statement of the design guideline, innerHTML should not be an accessor.  However, it is legacy and I was only accessing for guidelines for use in EcmaScript standards.  It would be nice if HMTL APIs used the same guidelines but that isn't something that TC-39 could enforce, even if we wanted to.

Legacy no one likes tends to fade, but innerHTML is pretty useful. If it 
had been a method, setInnerHTML, would it really be that much better? Is 
anything like it brewing in the modern DOM4/DOMCore/whatever-it's-called 
standards group?


More information about the es-discuss mailing list