26609 2014-08-19 20:59:15 +0000 AttrExodus: investigate child nodes of attributes and attributes being nodes 2015-11-11 14:46:05 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED MOVED P2 normal --- 1 annevk annevk crimsteam mike Ms2ger philipj www-dom public-webapps-bugzilla oldest_to_newest 110320 0 annevk 2014-08-19 20:59:15 +0000 As a first step investigate what various browsers support. Then investigate what could be simplified in the model if they dropped support for those features. Then investigate whether those features could be dropped if worthwhile. 110347 1 annevk 2014-08-20 11:36:23 +0000 Gecko throws when you attempt to mutate an attribute's children and acts as if an attribute has no children. E.g. attr.firstChild returns null. attr.appendChild() throws a "HierarchyRequestError". Chrome allows mutating attribute children. Inserting a text node modifies both the inserted text node and the text node already present. IE10 throws just like Gecko. However, it does pretend there is either no child or a single text node child. Hopefully Chrome can start throwing for mutation. And hopefully it can even emulate Gecko in not exposing any children. (I'm assuming Safari is the same as Chrome here.) Now if these methods simply throw, removing them should be possible so there's still hope for attributes not being nodes I think. 110348 2 philipj 2014-08-20 11:56:38 +0000 In Gecko, how can you attempt to mutate the children if it has no children? If we can end up with Attr as a child-free Node type like Text it would be great. Beyond that, is there simplification to be had for making it not a Node at all? 110349 3 annevk 2014-08-20 12:48:00 +0000 Well you can attempt to use things like appendChild() and see them fail. If they are not nodes they do not have all the concepts associated with nodes: base URL, node document, cloning, adopting, ... Other algorithms do not have to worry about them. 115059 4 crimsteam 2014-11-18 15:42:35 +0000 It looks that these old property are often used for attributes: https://www.chromestatus.com/metrics/feature/timeline/popularity/348 more then Attr.textContent and Attr.ownerElement (which was added to the interface Attr): https://www.chromestatus.com/metrics/feature/timeline/popularity/349 https://www.chromestatus.com/metrics/feature/timeline/popularity/160 115078 5 philipj 2014-11-18 22:15:48 +0000 Given that Attr has no children in Gecko, I guess that Attr.textContent overrides Node.textContent to instead be an alias of value? 115079 6 philipj 2014-11-18 23:03:18 +0000 Use counters for the access and modification of Attr's child Text nodes in Blink: https://codereview.chromium.org/723393005/ If the usage is low, hopefully Blink can align with Gecko as a first step. textContent would need special casing, though. 115106 7 annevk 2014-11-19 07:51:45 +0000 textContent is already changed in the specification. Am I missing something? 115107 8 philipj 2014-11-19 08:12:41 +0000 Ah, I didn't know you'd changed the spec. Ignore me :) 118062 9 philipj 2015-02-21 18:28:06 +0000 Blink bug tracking this: https://code.google.com/p/chromium/issues/detail?id=305105 120469 10 philipj 2015-05-25 20:48:09 +0000 A potential problem was raised on public-html: https://lists.w3.org/Archives/Public/public-html/2015May/thread.html#msg90 If Attr.cloneNode() is in common use as a workaround for setAttribute() being stricter than the HTML parser, that could complicate the effort to make Attr not inherit from Node. 124174 11 annevk 2015-11-11 14:46:05 +0000 https://github.com/whatwg/dom/issues/102 covers this fine.