- From: <bugzilla@jessica.w3.org>
- Date: Tue, 11 Mar 2014 18:30:42 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22141 --- Comment #6 from Daniel Freedman <dfreedm@google.com> --- Unfortunately, I think this is a very bad user experience decision. Yes, we would be breaking the written semantics of document.contains, but we would be keeping the developer expectation that document.contains(node) means "this node is *in* the document". Otherwise we've broken the developer assumptions about this method, and introduced a whole new variety of bugs. For example, the jQuery flot charting library draws a helpful chart hover target that follows the mouse. It uses document.contains to determine if it should add page scroll offsets to the mouse x/y position to draw the the target correctly. In the Polymer ShadowDOM polyfill, we followed the spec, and it broke this library: https://github.com/Polymer/polymer/issues/162. Ember is another library that uses document.contains to determine if an element should instantiate its controller: https://github.com/Polymer/ShadowDOM/issues/365 Even if we made a new function that does what we want, like Node.prototype.isInDocumentForReals, we still have to knock on all the library authors doors to get them to use the new method, or they say "ShadowDOM broke my stuff, it sucks" and everybody loses. Web developers need their tools to work, and making document.contains continue to follow developer expectations seems like winning all around. WDYT? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 11 March 2014 18:30:44 UTC