Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 22.2.2013 3:33, Blake Kaplan wrote:
> Hello everybody,
>
> I'm coming into this conversation late, but wanted to add my thoughts.
>
> As has been pointed out in this thread, the web has traditionally been
> very open and malleable. JavaScript has very few readonly properties,
> doesn't generally throw exceptions instead guessing or returning bogus
> values. Making shadow trees hidden clearly goes against this idiom
> and, by definition, limits what pages will be able to do with external
> libraries built using shadow DOMs.
>
> Even given this downside, though, I think that it's a mistake to make
> shadow trees accessible to the bound document by default. One of the
> most important features for frameworks is the ability to provide an
> encapsulated API. Without that, it becomes extremely difficult to fix
> bugs or add features to the framework without risking breaking
> downstream clients. Shadow DOMs are one of a host of features being
> designed and implemented that make HTML + CSS + JavaScript usable for
> programming in the wild and it feels like an oversight to make the
> default imitate the bad ol' days of monkey patching and low to no
> encapsulation.
>
> Finally, reading through the thread, it seems like one of the main
> use-cases for open-by-default is features like Google Feedback. From
> my point of view, it seems like features like that need to be
> considered from the beginning of a site's design. So if a site wants
> to have something like GF and also use web components and shadow DOMs,
> then the designers of the components should have to explicitly set the
> bit that says "let other people poke at my internals." I don't think
> that this one use-case needs to trump the good programming practices
> of every other library.
> --
> Blake Kaplan
>
>
I'd like to second that, shadow DOM is explicitly designed not to be 
accessible from outside, to stay consistent, to be sure that nothing 
gets broken by altering the internals of Shadow DOM control/widget. I'd 
like to be able to create controls in the future and give those controls 
to users to place them anywhere. I do not want to hear "our site is 
broken, because something else on our page was checking if there's a DIV 
there and you changed it to SECTION, you suck!", internals of the 
controls should stay internals of the control. You are effectively 
crippling half of the advantage of Shadow DOM: the ability do whatever I 
want to do inside the control as long as I expose the same API between 
versions.

So if this is going to be breached, there should be a way for control 
authors to decide, whether they want to opt for this traversing or not...


BTW looking at mail
From: Elliott Sprehn <esprehn@gmail.com>
Date: Thu, 8 Nov 2012 01:45:16 -0800
Traversable shadows are a requirement for a number of things like:
- Generic page level libraries and polyfills that need to transform DOM
nodes
- Generic event handling libraries (ex. Pointer events)
- Creating screenshots of the page by rendering every node to a canvas (ex.
Google Feedback)
- Creating awesome bookmarklets like Readability

Maybe I'm coming too late to this discussion, but how did everyone 
missed those first 2 points? Is this actually a suggestion that 
someone/something should be able not only read my DOM but alter it as 
well? So what is the point of Shadow DOM then?




B.

Received on Monday, 25 February 2013 15:53:55 UTC