Intent to Deprecate: Attr child Text nodes

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate both access and modification of Attr child Text nodes, where removal would mean that Attr will never have any child nodes.

(This deprecation and eventual removal does not involve making Attr not inherit from Node, that is a possible second step if the first is successful.)

Motivation

Attr is one of the stranger parts of DOM, and an effort has been made to simplify it:

https://dom.spec.whatwg.org/#interface-attr

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26609

The effort has had its ups and downs. Some parts have been put back in the spec in response to Chrome use counter data as well as the failed removal of e.g. Attr.ownerElement.

However, the child node aspect of Attr is one where simplification still seems feasible...

Compatibility Risk

This is a test for whether browsers expose child text nodes on Attr, whether those child nodes can can be modified, and whether new text nodes can be appended:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3463

Blink/WebKit: Attr has a child Text node. It can be modified and additional Text nodes can be appended, and these changes are reflected to the owning element's attribute value.

Gecko: Attr has no child nodes and appending throws an exception. (This is the goal.)

IE11: Attr has a child text node. Attempting to modify that Text node or append another Text node throws an exception.

In other words, being able to modify or append child nodes is unique to Blink/WebKit, making it lower risk to remove.

Only Gecko does not expose a child Text node. This rules out widespread usage in common code paths, but it's still possible to have non-Gecko code, like IE-specific desktop sites, that depend on this. This is the biggest risk.

Alternative implementation suggestion for web developers

Read and write attr.value, it is the same string as in the child Text node with a much less strange API. If Attr nodes aren't really necessary, use setAttribute() and getAttribute() instead.

Usage information from UseCounter

Attr child node access, ~0.005%:

https://www.chromestatus.com/metrics/feature/timeline/popularity/600

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

https://www.chromestatus.com/metrics/feature/timeline/popularity/601

The access value is not very encouraging. It's possible that some of it is due to generic code that deals with any node type, but without analyzing real-world content nothing can be assumed.

Entry on chromestatus.com, crbug.com, or MDN

https://code.google.com/p/chromium/issues/detail?id=305105

Requesting approval to remove too?

No. Feedback on how long it should be deprecated is appreciated. The removals don't have to be at the same time, as one of them seems much lower risk.

[Dominic Cooney]

I'm not a platform OWNER, but I wanted to chime in with support for this:

It's great to get junk that has a simpler, faster alternative out of the developer's way. It's great to give Attr a chance to retire from its frenetic double like as a ContainerNode and something with a simple text value. And it's great to simplify part of the code that has produced security bugs, for example from faulty TreeScope adoption for these Text nodes.

FWIW, in the past I tried to add use counters for polymorphic uses of Attr as Node, but naively checking "is it an Attr?" in Node operations, which should be fast (...all of the interesting ones), regresses performance. But this new use counter data is at least encouraging.

Dominic

[Philip Jägenstedt]

Thanks for your support, Dominic!

To clarify, the AttrChildAccess is triggers on Attr.childNodes, firstChild and lastChild, by shadowing the ones on Node. These are the only way to get to child nodes from the Node interface, but now I realize that it would actually fail to trigger if NodeIterator or TreeWalker is used. That seems very unlikely to me, but if anyone is genuinely concerned I could try to cover that case with additional counters.

Philip

[Elliott Sprehn]

+1, Attr's children need to move out the house.

[Chris Harrelson]

LGTM

How about we put in the approximate date by which we expect this deprecation to expire into the warning message?

On Thu, Mar 19, 2015 at 10:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

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

[Dimitri Glazkov]

LGTM2.

[Philip Jägenstedt]

That would be useful. Here are the (planned) branch dates and release
dates of the past 10 milestones, taken from
http://www.chromium.org/developers/calendar and
http://googlechromereleases.blogspot.com

M32: Nov 4, 2013 => Jan 14, 2014 (71 days)
M33: Dec 16, 2013 => Feb 20, 2014 (66 days)
M34: Feb 17, 2014 => Apr 8, 2014 (50 days)
M35: Mar 31, 2014 => May 20, 2014 (50 days)
M36: May 9, 2014 => Jul 16, 2014 (68 days)
M37: Jun 20, 2014 => Aug 26, 2014 (67 days)
M38: Aug 15, 2014 => Oct 7, 2014 (53 days)
M39: Sep 26, 2014 => Nov 18, 2014 (53 days)
M40: Nov 7, 2014 => Jan 21, 2015 (75 days)
M41: Jan 9, 2015 => Mar 3, 2015 (53 days)

The average is 60 days, minimum 50 days, so fast-case predictions (50 days) are:

M43: Apr 3, 2015 => May 23, 2015
M44: May 15, 2015 => July 4, 2015
M45: Jun 26, 2015 => Aug 15, 2015
M46: Aug 21, 2015 => Oct 10, 2015

I suggest two release cycles (3 months) of deprecation, removing it in M45:

"Attr child nodes are deprecated and will be removed in a stable
release around August 2015. Please use 'Attr.value' instead."

Philip

[Chris Harrelson]

That messaging sounds good to me.

[Jochen Eisinger]

LGTM3