Intent to Deprecate and Remove: ElementSetAttributeNodeNS

[kaust...@samsung.com]

Primary eng (and PM) emails

kaust...@samsung.com

Summary

Deprecate and Remove Unused measure ElementSetAttributeNodeNS

Motivation

The ElementSetAttributeNodeNS measure is one of the unsed UseCounters and is removed from DOM4.

Usage information from UseCounter

The ElementSetAttributeNodeNS use counter was among those listed in <http://crbug.com/332191>.

Compatibility Risk

None

Row on feature dashboard?

no.

Requesting approval to remove too?

Yes

[Alex Russell]

LGTM.

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

[Tab Atkins Jr.]

lgtm2

[Ojan Vafai]

It looks like this UseCounter has only made it out to the beta channel, but the 0.0002% usage there seems unlikely to me to change much once it hits stable. lgtm as well.

[kaust...@samsung.com]

Thank you all for approval. I have added crbug here - crbug.com/341296 . I will upload patch soon.

[PhistucK]

Just to clarify - are you referring to Element.setAttributeNodeNS?

(I do not recall any ElementSetAttributeNodeNS)

☆PhistucK

[Philip Jägenstedt]

Yes, the counter ElementSetAttributeNodeNS is for Element.setAttributeNodeNS()

Philip

[Ojan Vafai]

Looking at the related enums, ElementGetAttributeNodeNS is only used on 0.00016% of pageview and DocumentCreateAttributeNS is only used on 0.000088% of pageviews. Mind removing those as well?

[kaust...@samsung.com]

Yes, thats also probable candidate as it was also removed in DOM4. I will work on that too today. Thanks for sharing usage counter data :)

[sebp.m...@gmail.com]

Hi all,

please reconsider what happened due to the discussion in this thread:

IMHO it started with a misleading "summary" that stated that an "unused measure" should be removed.

It could only be me, but maybe the two LGTMs referred to actually removing the measure, which I would agree to be totally risk free (Compatibility Risk None),

However due to the very last comment (which may also be referring to the "usecounter" only) the original author finally ended up removing several of the public DOM Level 2 *APIs*, which I highly doubt to be of no compatibility risk.

In fact after this change, Chrome is incompatible to all other major browser and to every version of Chrome that existed before: Now Chrome does not implement the DOM level 2 and 3 standard anymore (the latter of which is the most recent, current, and active standard implemented by all other browsers).

While it may be true that the (unreleased, work in progress, still in flux) DOM4 "standard" will maybe be incompatible, I strongly argue that this will mean that Chrome should ever drop compatibility for the older standards. It's not like Chrome does not support HTML 4 or XHTML anymore just because today there is HTML5.

Granted, these features do have a relatively low usage counter, but does this really mean they can be removed silently even without a deprecation warning? Even if only few pages may use this feature, it is because of this change, that developers will have to rewrite their applications and introduce Chrome compatibility layers just to make the feature work in Chrome, too (like it was working in IE, FF, Opera, and even Chrome version 1 for ages).

The original goal of the meta bug was to remove code bloat, if I understand it correctly. The public API implementation that was removed due to this change consisted of less than about 50 lines of code. So the result is that code bloat was reduced by a few lines of code and Chrome has become incompatible to all other browsers. Please reconsider this change. It is the most sophisticated pages that now break due to these pages. Most of the time namespaced xml is used by advanced single page applications, only, so their actual usage count (per page view) is not very high (because the number of page views is probably dominated by Facebook and pron sites), but I believe they are very relevant to Chrome as a browser alternative to IE and FF.

Thank you for your consideration.

[Philip Jägenstedt]

AFAICT, this is the only patch that refers to this Intent to Deprecate
and Remove thread:
https://codereview.chromium.org/143173003 (8 lines removed in Source/,
more in LayoutTests/)

The fact that something has been specified and implemented for a long
time is not in itself a reason to keep it around. Web standards are
increasingly moving towards unversioned, living specifications, to
match the reality of how browser development works. That means that
only the latest version of the spec should be targeted, which in this
case is http://dom.spec.whatwg.org.

Here's a polyfill for anyone who depends on setAttributeNodeNS but
cannot fix it where used:

if (!Element.prototype.setAttributeNodeNS &&
Element.prototype.setAttributeNode) {
Element.prototype.setAttributeNodeNS = Element.prototype.setAttributeNode;
}

That's all that Blink's implementation did, anyway.

Philip

[sebp.m...@gmail.com]

Thanks Philip, 

I understand that setAttributeNodeNS is not such a big problem (and this actually wasn't the change that broke our library and all our customers usages of our library), and that instead the removal of "document.createAttributeNS" is the real problem. Still I believe that the "standard" you are referring to is actually not yet valid - this is what it says about the removal of these functions:

"It is not yet clear if it would be web-compatible to remove all the following features. The editors welcome any data showing that some of these features should be reintroduced."

In no way do I read that this is already removed and the current state of the art. Thus I don't believe it is a good idea to remove the existing API this soon (without a deprecation warning or whatsoever).

Also AFAICT it would be a lot harder to write a shim for document.createAttributeNS.

But I understand that this is indeed the wrong discussion thread and instead this one is the right one:

 https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8p-gwWL4ypc

I was referring to this changeset:

https://src.chromium.org/viewvc/blink?revision=166794&view=revision

And I was under the impression that this thread here was the reason for the action taken in the other changeset.

Sebastian

[Adam Barth]

Attribute nodes introduce significant complexity into the engine and are used extremely rarely.  Once we remove all the APIs that expose the existence of attribute nodes, we can remove the machinery.  It's easy to look at each individual change along that path and say "that change is small," but the big win comes at the end when we can remove the concept of an attribute node entirely.  We might not get there, but we'd like to try because it's the right thing for the long-term health of the web platform.

Adam

[Philip Jägenstedt]

For the curious, these are the remaining APIs that return Attr, and
their use counters:

Document.createAttribute:
http://www.chromestatus.com/metrics/feature/timeline/popularity/111
Element.getAttributeNode:
http://www.chromestatus.com/metrics/feature/timeline/popularity/107
Element.setAttributeNode:
http://www.chromestatus.com/metrics/feature/timeline/popularity/108
Element.removeAttributeNode:
http://www.chromestatus.com/metrics/feature/timeline/popularity/109
Element.getAttributeNodeNS:
http://www.chromestatus.com/metrics/feature/timeline/popularity/110

Usage from Ojan's "FYI: UseCounter data" mail:
Document.createAttribute: 0.1865156846
Element.getAttributeNode: 7.163385257
Element.setAttributeNode: 0.1286837253
Element.removeAttributeNode: 0.0005441460026
Element.getAttributeNodeNS: 0.0005441460026

Element.getAttributeNode is going to make full removal impossible, so
I've filed a spec bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25016

The direction the DOM spec is taking is making Attr a much dumber
object, which I hope will end up Web compatible:
http://dom.spec.whatwg.org/#attr

Philip

[PhistucK]

I think getAttributeNode is simply used by jQuery (and maybe other popular libraries), so it makes sense it has such a high share, but it is mostly used to overcome incompatibilities, so it might be easier to remove if jQuery moved away from it.

☆PhistucK

[sebp.m...@gmail.com]

I think getAttributeNode is simply used by jQuery (and maybe other popular libraries), so it makes sense it has such a high share, but it is mostly used to overcome incompatibilities, so it might be easier to remove if jQuery moved away from it.

Well I doubt that it will be that easy - a quick search on GitHub for "getAttributeNode" yields more than 250.000 references in Javascript code - there are quite a number of false positives here and duplicates, but the web is not just jQuery....

Also I really don't see how we can discuss the removal of Attr in whole - even the "DOM4 Spec (Quote:  It is inappropriate to cite this document as other than work in progress)" requires the "attributes" property on element to return an array of "Attr" instances. 

@Philip:

Your usecounters do not contain a usecounter for "element.attributes", but I guess the usage is a lot higher than "getAttributeNode".

How do you iterate over attributes of an element without such a method/property?

[Philip Jägenstedt]

On Wed, Mar 12, 2014 at 4:47 PM, <sebp.m...@gmail.com> wrote:
>> I think getAttributeNode is simply used by jQuery (and maybe other popular
>> libraries), so it makes sense it has such a high share, but it is mostly
>> used to overcome incompatibilities, so it might be easier to remove if
>> jQuery moved away from it.
>
>
> Well I doubt that it will be that easy - a quick search on GitHub for
> "getAttributeNode" yields more than 250.000 references in Javascript code -
> there are quite a number of false positives here and duplicates, but the web
> is not just jQuery....

Yeah, it's unlikely that making jQuery go away would let us remove
getAttributeNode. But that's hypothetical, because current versions of
jQuery are going to be around for a very long time.

> Also I really don't see how we can discuss the removal of Attr in whole -
> even the "DOM4 Spec (Quote: It is inappropriate to cite this document as
> other than work in progress)" requires the "attributes" property on element
> to return an array of "Attr" instances.

To quote the spec, Attr "No longer inherits from Node and therefore
completely changed." I don't think it's clear yet how much simpler
Attr can be made without breaking content, but hopefully a lot simpler
than what Blink currently has.

> @Philip:
> Your usecounters do not contain a usecounter for "element.attributes", but I
> guess the usage is a lot higher than "getAttributeNode".
> How do you iterate over attributes of an element without such a
> method/property?

Element still has "readonly attribute Attr[] attributes" in the DOM
spec and doesn't have a use counter in Blink, so I don't think anyone
has even considered removing it.

In summary, it's very unlikely that everything related to Attr can be
removed. That being said, I think it's great that we're removing the
bits that are very rarely used.

Philip

[Anne van Kesteren]

On Wed, Mar 12, 2014 at 9:47 AM, <sebp.m...@gmail.com> wrote:
> Also I really don't see how we can discuss the removal of Attr in whole -
> even the "DOM4 Spec (Quote: It is inappropriate to cite this document as
> other than work in progress)" requires the "attributes" property on element
> to return an array of "Attr" instances.

I recommend reading the WHATWG copy. That's definitely the intent. If
we find out, by removal efforts such as this one, that it does not
work we can always reconsider. However, until proven otherwise that
will remain the plan.


--
http://annevankesteren.nl/

[Mike Sherov]

On Wed, Mar 12, 2014 at 3:25 AM, PhistucK <phis...@gmail.com> wrote:

I think getAttributeNode is simply used by jQuery (and maybe other popular libraries), so it makes sense it has such a high share, but it is mostly used to overcome incompatibilities, so it might be easier to remove if jQuery moved away from it.

 

As of jQuery 1.10.0 (May 24th, 2013) and prior to jQuery 1.3 (Jan 14th, 2009), jQuery's use of getAttributeNode is only hit in old IE codepaths and never on Chrome.

Between jQuery 1.4 and jQuery 1.10.0 (Jan 14th 2010 - May 2th 2013), the only use of getAttributeNode in a non-IE codepath was for tabindex. tabindex is used by jQuery UI dialogs, which likely account for a large portion of the 7%.

Perhaps we can add a usecounter for which attributes are being requested if we'd like to confirm that suspicion.

--
Mike Sherov

[Philip Jägenstedt]

On Sun, Mar 16, 2014 at 11:12 PM, Mike Sherov <mike....@gmail.com> wrote:
>
> On Wed, Mar 12, 2014 at 3:25 AM, PhistucK <phis...@gmail.com> wrote:
>>
>> I think getAttributeNode is simply used by jQuery (and maybe other popular
>> libraries), so it makes sense it has such a high share, but it is mostly
>> used to overcome incompatibilities, so it might be easier to remove if
>> jQuery moved away from it.
>
>
> As of jQuery 1.10.0 (May 24th, 2013) and prior to jQuery 1.3 (Jan 14th,
> 2009), jQuery's use of getAttributeNode is only hit in old IE codepaths and
> never on Chrome.
>
> Between jQuery 1.4 and jQuery 1.10.0 (Jan 14th 2010 - May 2th 2013), the
> only use of getAttributeNode in a non-IE codepath was for tabindex. tabindex
> is used by jQuery UI dialogs, which likely account for a large portion of
> the 7%.
>
> Perhaps we can add a usecounter for which attributes are being requested if
> we'd like to confirm that suspicion.

The code looks like this:

var attributeNode = elem.getAttributeNode( "tabIndex" );
return attributeNode && attributeNode.specified ?
attributeNode.value :
rfocusable.test( elem.nodeName ) || rclickable.test(
elem.nodeName ) && elem.href ?
0 :
undefined;

Dropping getAttributeNode would throw an exception, so even if this
were the only code anywhere that used getAttributeNode, the fact that
it's jQuery means removal will not fly.

Anyway, since Element.attributes exists, I don't think
getAttributeNode is much of an added burden. The question is rather if
Attr can be simplified to get rid of the crazier aspects. (For
example, Attr currently has a child text node with the attribute
value. Modifying child nodes modifies both Attr.value and the
attribute on the element from where the Attr object came.)

Philip

[Mike Sherov]

Right.

I suppose my point is that the wish for jQuery to move away from getAttributeNode was granted last year :). 

Secondly, as you can see from the single code path, jQuery relies on the less arcane properties of Attr: specified and value.

Perhaps a use counter for the Attr API itself is in order? I'd again guess that an overwhelming percent of that usage is just value and specified. 

Mike

[sebp.m...@gmail.com]

Dear Anne,

thank you for your insights.

I did read the WHATWG copy, but I think I would still like to have a clarification here in this thread about your claim: "Removing Attr" ... "That's definitely the intent".

I don't see in any way that the WHATWG copy says that the Attr interface can be removed, and if the complete removal of the interface is "the intent", then I wonder how one should ever be able to iterate over all attributes of an element.

If the intent is to remove the "node" interface from the "attr" interface (but still keep a dumbed down version of the attr interface at least as a return value for the "attributes" property of element), then I do understand that this can be the intent.

If you need a proof that the existance of the Attr interface is required, then I would say it is for iterating over attributes of an element. I don't see how you should be able to do this *without* the Attr interface.

Please clarify.

Thanks - Sebastian

Anne van Kesteren:

[Anne van Kesteren]

On Wed, Mar 19, 2014 at 2:42 PM, <sebp.m...@gmail.com> wrote:
> I did read the WHATWG copy, but I think I would still like to have a
> clarification here in this thread about your claim: "Removing Attr" ...
> "That's definitely the intent".

Sorry, that was perhaps a bit too brief. Simplifying Attr to no longer
inherit from Node and removing features that are barely used is the
intent. We do indeed need to keep around Attr objects.


--
http://annevankesteren.nl/

[i...@malte.de]

The latest Chrome release does contain this change which is breaking DOM Level 2 and 3 compatiblity. While I understand that getting rid of unused functionality is a good thing, is it really a good idea to intentionally break web standards? I can't think of any good reason to remove support of setAttributeNodeNS, getAttributeNodeNS and createAttributeNS, even if they are only used rarely, they are still part of http://www.w3.org/TR/DOM-Level-3-Core/core.html ! 

.

[Anne van Kesteren]

On Mon, Apr 14, 2014 at 10:54 AM, <i...@malte.de> wrote:
> http://www.w3.org/TR/DOM-Level-3-Core/core.html

Obsoleted per http://dom.spec.whatwg.org/


--
http://annevankesteren.nl/

[i...@malte.de]

So what? This is incompatible. I am fine if browsers show a deprecation warning, but they should continue supporting this functionality. I agree that these methods are ugly and it is right to obsolete them, but why do you need to break existing websites/applications?

[Anne van Kesteren]

On Mon, Apr 14, 2014 at 11:15 AM, <i...@malte.de> wrote:
> So what? This is incompatible. I am fine if browsers show a deprecation
> warning, but they should continue supporting this functionality. I agree
> that these methods are ugly and it is right to obsolete them, but why do you
> need to break existing websites/applications?

By obsoleted I meant removed. If it can be demonstrated that a method
is used so little that we can remove it, we should do so as it reduces
code complexity. You can find a longer form of this argument here:
http://dev.opera.com/articles/view/showmodaldialog/


--
http://annevankesteren.nl/

[i...@malte.de]

I see a difference between a broken, proprietary method of IE, which was mimicked by other browsers for compatilbility and the W3C DOM specification which widely adopted, not only in the browsers but all kind of XML processing software. Compatibility is such an important feature of the web and it took us so long to achieve it. It is one thing to create a new standard which improves things by simplification, but another thing to just drop support for the previous standard in the browser. Again: I can't think of any good reason to intentionally break standards based websites. Please don't.

 

[sebp.m...@gmail.com]

I am with you, Malte. What I think is scary that the "whatwg standard" is proclaimed as a standard already, whereas even that "standard" claims the following with regard to the methods that have just been removed:

"*It is not yet clear if it would be web-compatible to remove all the following features. The editors welcome any data showing that some of these features should be reintroduced.*"

Though, the editors don't really seem to be interested in this kind of input. For them it's enough to see that a questionable Chrome statistics page says that only thousands of pages will be broken, but not millions.

I think breaking a standard that has been there for more than a decade and was implemented by all browsers for years in favor of a "standard" that is not at all finalized in this regard is extremely questionable. During this debate, I lost my faith in this so-called standard and the way it's being developed and enforced.

[Torne (Richard Coles)]

On 14 April 2014 12:42, <sebp.m...@gmail.com> wrote:

I am with you, Malte. What I think is scary that the "whatwg standard" is proclaimed as a standard already, whereas even that "standard" claims the following with regard to the methods that have just been removed:

The WHATWG specs are a living standard, which is intended to evolve in concert with implementations over time, including removing old features. It will never be finalized, that's not the goal at all.

[sebp.m...@gmail.com]

The WHATWG specs are a living standard, which is intended to evolve in concert with implementations over time, including removing old features. It will never be finalized, that's not the goal at all.

 

"*It is not yet clear if it would be web-compatible to remove all the following features. The editors welcome any data showing that some of these features should be reintroduced.*"

In that case they should make a clear statement: Right now they are saying: "if it would be web-compatible to remove those features" - I'm not a native english speaker but to me this does not sound like a definitive statement that they actually *have been removed*. This is how the Chrome team interpreted the statement. We the programmers need a documentation that tells us what features we can use and which ones we can't. Right now the situation is this: There *is* a well-known standard (DOM level 2/3) - you cannot rely on it anymore. Then again there is this document that looks like a work in progress mess - and this is what browser implementations (read Chrome) are using as a guideline. Now we have the same mess that we had before HTML5 when there were different interpretations of the standard for each and every browser implementation. 

Even if the "standard" is a "living standard" that can never be considered finalized, it should at least *try* to be definitive. Otherwise any browser vendor will interpret this differently and we (the developers) would probably be just as well off without this document.

[Anne van Kesteren]

On Mon, Apr 14, 2014 at 2:06 PM, <sebp.m...@gmail.com> wrote:
> Even if the "standard" is a "living standard" that can never be considered
> finalized, it should at least *try* to be definitive. Otherwise any browser
> vendor will interpret this differently and we (the developers) would
> probably be just as well off without this document.

It does try to be definitive. That is why these features are gone from
the document and not yet from all browsers... If there is anything
unclear please use the links at the top of the standard to provide
feedback. Off-topic for blink-dev.


--
http://annevankesteren.nl/

[Mathias Bynens]

On 14 Apr 2014, at 15:06, sebp.m...@gmail.com wrote:

> In that case they should make a clear statement: Right now they are saying: "if it would be web-compatible to remove those features" - I'm not a native english speaker but to me this does not sound like a definitive statement that they actually *have been removed*. This is how the Chrome team interpreted the statement.

No. This thread is the result of the Chromium team looking at UseCounter data and deciding the overhead of keeping `ElementSetAttributeNodeNS` is not worth the complexity.

The comment in the spec predates this data, and this thread.