- From: <bugzilla@jessica.w3.org>
- Date: Fri, 02 May 2014 16:33:30 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24861 Daniel Buchner <danieljb2@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danieljb2@gmail.com --- Comment #3 from Daniel Buchner <danieljb2@gmail.com> --- (In reply to Olli Pettay from comment #2) > (In reply to Elliott Sprehn from comment #1) > > We also need to be able to detect when an element gets a ShadowRoot since > > that's conceptually like an "appendChild" like operation. > Why would we need that. That is yet another way to expose more > internals of shadow dom management to the outer world, and we should > make encapsulation better, by default, not worse. There are many, many cases where this functionality is essential - I'll illustrate one I have faced: A while back, I worked on a component that wrapped up drag and drop into a simple, declarative tag, <x-dragbox>. The component subscribed to all the drag/drop events, and allowed children of certain kinds to be draggable within it. The catch is that in order to "turn on" the DOM's drag/drop functionality for an element, you must first add the boolean attribute, draggable="". For obvious reasons, this sucks. Instead of a simple, async event that keyed off the select="" filter for my allowed, draggable node types, it required me to setup a significant chunk of boilerplate using Mutation Observers and a redundant node filter. All this just so I could intercept added nodes and append the draggable="" attribute. There are many more examples where this feature would dramatically reduce code complexity and boilerplate. (also note: MO's are on the 'advanced' side in terms of web API experience/difficulty, so it's not simple boilerplate for a huge percentage of web devs) -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 2 May 2014 16:33:33 UTC