On Oct 15, 2012, at 9:20 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... > > 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?
Don't know, if anything new is brewing. Maybe Alex Russell is working one something... Does it matter a lot that innerHTML doesn't follow this guideline? Not really. You can't depend upon best practices being followed by the world at large, but they're still useful to have. A set of best practice guidelines (at least for use within Ecma defined built-ins) for choosing when to use use accessors will help us make the overall set of built-in APIs more consistent as it grows. Otherwise, in situations like this you may get what appears to be coin-flip API design. Some objects may use an accessor and others a method in very comparable situations. A set of guidelines gives us a basis for making consistent decisions that can be explained. "no side-effects visible via other accessible objects" seems like reasonable candidate for an accessor best practice, even if innerHTML and many developer defined objects don't follow it. But, it is just one of several possible accessor guidelines and it wouldn't necessarily be a bad thing if we don't adopt it. But we should have some guidelines so we don't appear to be coin-flip designers Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
