Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

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

Received on Sunday, 24 February 2013 22:51:19 UTC