- 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