New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 46 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Apr 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 341830

Sign in to add a comment

DOM Level 2 API not available anymore (createAttributeNS, setAttributeNodeNS, ...)

Reported by, Feb 27 2014 Back to list

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1861.0 Safari/537.36

Steps to reproduce the problem:
1. Try to use any of the DOM Level 2 AttributeNS API in Javascript in any page.
2. e.g. "document.createAttributeNS"
3. notice that the functions are not available anymore and you get an "undefined" error

What is the expected behavior?
The DOM Level 2 API should still be available.

But everything related to ns attribute nodes seems to be gone. 

What went wrong?
Someone removed the API, I believe this is a misunderstanding and a bad review of the following bugs:

Instead of removing the "measure" - a usage couner as far as I  understand, they removed the "feature" - which is highly backwards incompatible.

Did this work before? Yes Current Stable Release, and probably before this revision:

Chrome version: 35.0.1861.0  Channel: canary
OS Version: 6.3
Flash Version: Shockwave Flash 13.0 r0

Please review these issues and what they did there: 
I get the same error. DOM Level 2 API is crucial for us, so what is the plan to fix that issue?
Labels: -Cr-Blink-JavaScript Cr-Blink-DOM

Comment 3 by, Mar 3 2014

This is already a problem in Chrome 34.0.1847.11 beta-m.

Please fix ASAP, this is a breaking change.
Obviously the idea is to "move forward" to the incompatible DOM level 4 "standard":
(quote from the URL above as of today: "It is inappropriate to cite this document as other than work in progress.") and that "rarely used" API from the current active standard DOM Level 2 and DOM Level 3 is removed to "simplify the code in Blink and the web platform as such".

If anyone of you thinks this is a bad idea (like I do): Please raise your voice here and possibly in these threads:!topic/blink-dev/jS7iCEmoWfQ!topic/blink-dev/8p-gwWL4ypc

Also if you feel that it might not be a good idea to use the Usecounter statistics to remove other existing standardized features, please consider raising your voice, too.
See this page and this thread:
IMHO the usecounter cannot be trusted that much. It's an opt-in counter, i.e. I believe many power and corporate users will not opt-in. Also it is based on page views and thus will mostly record features on facebook, google, news and pron sites. Sophisticated modern single-page applications will thus be underrepresented. Last but not least I doubt that a usage of less than 0.03% really means the feature is not used very often. Given the number of page views and different pages on the internet, this still is a massively huge amount of usages.

Thank you for your consideration.

@arv - in a different issue you said you could write a shim that brings back the compatibility with other browsers and the DOM level 2/3 standard. Can you please share that code for the corresponding methods so that other who will find this thread can include this compatibility snippet into their existing code bases?

Hi @sebp.muller - 

First of all apology for delayed response. After reading all those different views and opinions about this Removal of DOM Level 2 apis, I understand that it has caused you lot of inconvenience. If you looked at the codereview links, I was intended to Deprecate the feature only as per the guidelines from the Meta bug of Unused features. But after some discussion, it was decided by the reviewers itself to remove the feature rather than deprecating. I personally agree with the comments & views they shared on this issue.  I do not consider myself as Web Dev expert but I understand the need of simplifying complexities and healthy web standards and I was following the same. 

Comment 7 by, Mar 13 2014

sebp.mueller: Here is a polyfill for setAttributeNodeNS and createAttributeNS:

This bug just made a web application that I am using unusable. I will try to use the polyfill.

<sarcasm>@manuel: The usecounter says these kind of applications don't exist. This is a no-issue.</sarcasm> 
Polyfill works. Nevertheless I attached a screenshot of the web application. 
83.7 KB View Download
@sebp.mueller I have to admit that I am using the same software that willy referenced by chance we are former fellow students.

@willy I just added the polyfills at the beginning of oryx.js Afterwards the editor is again working like a charm.
@manuel I filed the bug for a different piece of software.

Note that the code snippet in #10 will soon break again once they actually remove "setAttributeNode" (see ) without notice. <sarcasm>But hey! We can add the same polyfill to each website or rewrite all of our outdated legacy code! What's important is that we remove the code from the browser!</sarcasm>
Blockedon: chromium:341830
Labels: -OS-Windows OS-All M-34
Status: Untriaged
These were removed as part of  bug 341830  as part of a larger effort to remove low-usage DOM APIs from Blink, particularly those related to Attribute nodes (which introduce significant complexity into the Blink codebase, despite having extremely low usage).  My apologies for having broken sites which you use.  Hopefully Arv's instructions in comment #7 will help you get things working again.

At time of removal, createAttributeNS was seen on 88 out of every 100,000,000 reported Chrome page views, and setAttributeNodeNS was seen on 2 out of every 1,000,000 reported views.  Both of these are extremely low usage.

Our goal is to focus on the 99.999% of chrome page views (and presumably users) which do not use these features.  By removing these two in particular, we're hoping to make it possible to remove Attribute Nodes entirely from Blink in the future.

I don't think we've done a particularly good job about communicating these changes to a wide enough audience and we'll be looking at better ways to do so for any future removals.

Comment 14 by, Apr 14 2014

Please really think about reverting those changes. The method is e.g. used in the JavaScript Library datajs ( - already open defect:, which is itself used within e.g. SAP UI5 ,which is again used in SAP OData, which is used in hundreds of commercial products over the world, with a pretty high sales volume.
For posterity: I've re-confirmed that in the two weeks prior to April 1, 2014 reported usage:
Document.createAttributeNS : .8 times
Element.setAttributeNS: 1.3 times
out of every 1,000,000 reported Chrome views.

Comment 16 by, Apr 14 2014

Honestly, it was a bad idea to just remove these functions. Even if they are rarely used, you are punishing developers who did the right thing: Adhering to web standards. This is not about some proprietary or undocumented functionality, but functions of DOM Level 3 specification. The success of the world wide web is based on the compatibility with old documents, you can still open HTML 2.0 documents in modern browsers. Please keep the browser compatible. 
While I don't completely disagree about eventually making attributes less "Node-like", removing these functions without warning was a very bad idea. While the overall usage might be small, to that small amount of sites it was very important. We had to do emergency updates on our site to fix the issues related to this.

Simply having these functions deprecated for a few Chrome versions would have given us time to find alternative solutions, before the functionality is completely removed.
Thank you for the feedback and my apologies for the disruption.  We highlight removals on blink-dev, they're also tracked at and recently we've been highlighting them on  I'm sure we can and should do more to give developers more warning about removals.

If you can I would encourage you to enable anonymous usage reporting in Chrome.
I understand that's not an option for all environments, but those are the numbers which we use to generate our public UseCounter stats at and drive these decision making processes.

Comment 19 Deleted

Comment 20 by, Apr 16 2014

As you can see in this thread:!topic/blink-dev/8p-gwWL4ypc a large number of enterprise users were actually using this instruction (e.g. SAP, EADS etc.). Maybe you should think about the usefulness of your usage counter if most probably 90% of all enterprise users have disabled this option.

I really do not see a point to punish enterprise customers / developers who used web standard functions. There is just no sense behind it to save 20 lines of code, and loose the trust of a lot of companies using tools, where this function is actually used.

 Issue 364028  has been merged into this issue.
 Issue 364028  has been merged into this issue.
Labels: M-35 Merge-Requested
Thank you for your report.  I've created a patch to add back three APIs we removed relating to Attr nodes in Chrome 33 and Chrome 34.  I'm starting the process of getting these changes merged into Chrome 35.
Cc: has landed in r171971, but it looks like it missed canary by 15 revisions (r171956).

Comment 26 by, Apr 21 2014

Status: Assigned
giving to you eric, so we can approve tomorow once it's been on canary.
Labels: Cr-Enterprise says this is definitely in Canary now.  Preparing the merge:
drover --merge 171971 --branch 1916
Karen says there is some un-related trouble with the Beta build atm, so I will hold off on completing the merge until that's resolved.

The merge was clean.  Anyone could complete this by running the above drover command with the blink drover properties file:

mkdir blink_merges
cd blink_merges
svn export
drover --merge 171971 --branch 1916

are the instructions.

Comment 31 by, Apr 23 2014

Labels: Needs-Feedback
As per C#23,>add back three APIs we removed relating to Attr nodes
Able to see the "createAttributeNS" in the console on latest canary-36.0.1953.0(Official Build 265450))windows7.

eseidel@:Could you please confirm as to what else we are looking for in the added APIs?
Thanks in advance!

I can confirm that the functionality is back in the latest Windows Canary build (I'm on 36.0.1953.0). "createAttributeNS", "setAttributeNodeNs", "ownerElement" (on attributes) now show a deprecation warning in the console, but they seem to work the way they did before the removal.


Comment 33 by, Apr 23 2014

Labels: -Merge-Requested Merge-Approved
awesome ty.
Status: Fixed
Committed revision 172389.

Should be in the next roll of M35 (Beta).

Comment 35 by, Apr 23 2014

Labels: -M-35 -Merge-Approved Merge-Merged-1916 Merge-Requested
Are you requesting this be merged into M34?  I'm confused by the new flags?

Comment 37 by, Apr 23 2014

> Are you requesting this be merged into M34? 

Yes. We should do it if TPM allows it.

Labels: -Merge-Requested
I'm curious about how the intent to deprecate works with SVG files (xlink:href, namely). Is there a plan to have SVG 2 drop that, will there be a compatibility exception, or should I just start using polyfills now?

Sign in to add a comment