Intent to Remove: Attr child nodes

296 views
Skip to first unread message

Philip Jägenstedt

unread,
May 24, 2015, 7:20:42 AM5/24/15
to blink-dev

Primary eng (and PM) emails

phi...@opera.com


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/tW6Lr5nA1pY/BOedStgP2pEJ


The deprecation is in M43 with this message: "Attr child nodes are deprecated and will be removed in M45, around August 2015. Please use 'Attr.value' instead."

Summary

Let Attr nodes not have any child nodes. It currently has child text nodes as a redundant representation of the attribute value.


(This removal does not involve making Attr not inherit from Node.)

Motivation

Attr is one of the stranger parts of DOM, and an effort has been made to simplify it:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26609

This will be a simplification of the code and gets rid of a few FIXMEs:
https://codereview.chromium.org/1158433004/ (prepared to sanity check the change)

Usage information from UseCounter

Attr child node access, ~0.002% and falling:

Usage dropped quickly on May 20, just as M43 was released. I've verified that the counter wasn't accidentally unreachable in M43, so maybe there's a large site that reacted to the deprecation message, or there was some internal use that hit the code path that was removed with M43.

Attr child node changes (modify/append/remove), ~0.0008%:

Entry on chromestatus.com

https://www.chromestatus.com/features/5688366657961984


Compatibility Risk

After the removal, Blink will match Gecko in having no child nodes and throwing an exception if one attempts to add child nodes. The biggest risk is non-Gecko code paths that assume that the child nodes are there, for example using element.attributes[n].firstChild.data' instead of element.attributes[n].value. Such code would start throwing exceptions.

Dimitri Glazkov

unread,
May 26, 2015, 10:50:33 AM5/26/15
to Philip Jägenstedt, blink-dev
LGTM.

David Benjamin

unread,
May 26, 2015, 11:37:21 AM5/26/15
to Philip Jägenstedt, blink-dev
On Sun, May 24, 2015 at 7:20 AM Philip Jägenstedt <phi...@opera.com> wrote:

Usage dropped quickly on May 20, just as M43 was released. I've verified that the counter wasn't accidentally unreachable in M43, so maybe there's a large site that reacted to the deprecation message, or there was some internal use that hit the code path that was removed with M43.


Looking at data from other channels, it appears to be correlated with the version and not time. Based on Dev, it's between 43.0.2327.5 and 43.0.2334.0. The Canary data seems too noisy to give a useful range at a glance.

My guess is it's this CL.I remember when toying with doing a prefixed Page Visibility deprecation message that, because of this issue, it would trigger a false positive every time you typed |document| into the console, since that happened to iterate over all properties of the object.

David

Philip Jägenstedt

unread,
May 26, 2015, 2:06:19 PM5/26/15
to David Benjamin, blink-dev
Thanks for checking on that, David. Moving DOM attributes to the
prototype chain could certainly change which code paths are taken.
Perhaps there's some code that did attr.getOwnPropertyNames() and
looked up all the attributes, or similar. Even if it wasn't that CL,
it must be something internal rather than a reaction to the
deprecation message, so that's good to know.

Philip

Chris Harrelson

unread,
May 26, 2015, 2:51:09 PM5/26/15
to Philip Jägenstedt, David Benjamin, blink-dev
LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

TAMURA, Kent

unread,
May 26, 2015, 8:07:58 PM5/26/15
to Chris Harrelson, Philip Jägenstedt, David Benjamin, blink-dev
LGTM3.  Compatible with Gecko sounds safer.

--
TAMURA Kent
Software Engineer, Google


Reply all
Reply to author
Forward
0 new messages