Intent to deprecate and remove: DocumentCreateAttributeNS

[kaust...@samsung.com]

Primary eng (and PM) emails

kaust...@samsung.com

Summary

Deprecate and Remove Unused measure DocumentCreateAttributeNS

Motivation

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

Usage information from UseCounter

DocumentCreateAttributeNS is only used on 0.000088% of pageviews as per the discussion in below thread.

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

Compatibility Risk

None

Row on feature dashboard?

no.

Requesting approval to remove too?

Yes

[Eric Seidel]

lgtm.

[TAMURA, Kent]

lgtm2 to remove.

--
TAMURA Kent
Software Engineer, Google

[Adam Barth]

LGTM

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

Hi all,

this is basically a copy of the post to another thread (the one that is mentioned in the "Usage Information". I should have posted it to this thread first, I believe, so please accept my apologies.

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 LGTMs referred to actually removing the measure, which I would agree to be totally risk free (Compatibility Risk None),

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.

This is what the "DOM 4 standard" has to say about the removal of this API:

"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." (http://dom.spec.whatwg.org/)

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.

[tec...@gmail.com]

Hi All,

Please reconsider the change. The removing of the method DocumentCreateAttributeNS causes big compatibility issues for me and makes several webpages unusable. There seem to be several libraries which are still relying on this method to be available (beyond others one within the SAP UI5 enviroment).

Thanks & Regards,

Timo

[Eric Seidel]

Could you provide me more information about which sites break? Chrome
UseCounters report that this function is only used in 88 out of every
100,000,000 reported page views, which is extremely small usage.
However, I agree that removing this has small benefit as well.

Sites affected by this should be able to add something like this to their pages:
<script>
Document.prototype.createAttributeNS = function(name, ns) {
var attr = this.createAttribute(name);
attr.namespaceURI = ns;
return attr;
}
</script>

[Adam Barth]

On Mon Apr 14 2014 at 8:53:27 AM, Eric Seidel <ese...@chromium.org> wrote:

Could you provide me more information about which sites break?  Chrome
UseCounters report that this function is only used in 88 out of every
100,000,000 reported page views, which is extremely small usage.
However, I agree that removing this has small benefit as well.

Sites affected by this should be able to add something like this to their pages:
<script>
Document.prototype.createAttributeNS = function(name, ns) {
  var attr = this.createAttribute(name);
  attr.namespaceURI = ns;
  return attr;
}
</script>

I don't think that works because namespaceURI is read-only:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Attr.idl

Adam

[Erik Arvidsson]

Yeah, it is readonly but there are other solutions:

https://gist.github.com/arv/9529994

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

--
erik

[tec...@gmail.com]

Please really think about reverting those changes. The method is e.g. used in the JavaScript Library datajs ( http://datajs.codeplex.com/releases/view/117856 - already open defect: http://datajs.codeplex.com/workitem/1272), 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.

I'll check the alternative implementation anyways. Thanks.

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

Hi Erik,

we found this issue in our HTML5 javascript diagramming library "yFiles":

http://www.yworks.com/yfileshtml  - (live demos linked from the page)

We have since removed the offending code, but a great number of our customers (software developers, some listed here: http://www.yworks.com/en/company_references.html )

were or are affected by the removal. I really hate it, having to tell our customers that they cannot rely on Chrome anymore, because it could happen anytime that they will be removing crucial standardized functionality that had been working for years in all major browsers. 

I was surprised to hear that the use-counter is that low for that feature, but to me this just shows how irrelevant these statistics are.

Our customers are corporate customers, mostly and I believe the statistics are badly skewed because of these issues:

-facebook, gmail, google, and probably pron sites will probably cause by far the most "page views" 

-modern single page applications which run for hours or maybe even days just count as a single "page view" and are thus underrepresented.

-especially in corporate environments, but maybe also to a large degree for power users, people probably are not going to opt-in into the statistics - I know for sure that our online demo *alone* that was using that code path that we had online was used far more than a few hundred times per day by Chrome browsers. (Is 88 actually an absolute number?)

-it is the most modern pages that make use of these features only. The average webpage is certainly not going to use namespace attributes, but more sophisticated applications are much more likely - our codebase is not old at all - it was authored from scratch in 2012.

The original intent was to "improve the code base" to make it more maintainable. In effect about 10 trivial lines of core code (if you leave away the tests) were removed from the blink code-base. A great many of developer's around the world now have to add about twice as much as lines of code of shim (in GitHub there are 15.000 occurences of createAttributeNs in javascript source files - all of them should break on chrome, now). I actually believe that the maintenance for the usecounter causes more headaches and work than the removal did.

Why don't you add a use-counter for technologies like WebSql? Now that would be a feature that would really reduce the code base. There is so much feature bloat in Chrome nowadays that requires massive amounts of code (WebSql, NaCL,WebSpeech API, Media Recorder  to name just a few), that I wonder why one has to remove those features that had been working for ages, were standardized and respected by most developers and only require a few lines of trivial code in the blink code-base.

[andreas...@sap.com]

Dear all,

A number of our large enterprise customers, with hundreds of productive users, raised very serious issues to us because of that incompatible change. The consequence is that we have to advise our customers not to update to Chrome 34 until the problem is solved. The expectation is, that the change will be turned back. We see a big risk if Chrome looses it's, so far good, reputation as a stable and compatible browser.

Kind Regards, Andreas