#Composition is the Goal
I see several discussions now that vacillate around on encapsulation qualities of Shadow DOM and the flavors thereof. It's all my fault. I stuck encapsulation into the problem statement of the spec. I even glued the somewhat irrelevant term functional encapsulation on top of it. What a dork.
It was a couple of years ago, when one of my colleagues read the spec and noted: "Dude, it's like your story and whatever, but the way you tell it, Shadow DOM is not about encapsulation. It's about composition". The world went blank around me. I was blinded by insight.
My hipster colleague was right, of course. Encapsulation is just a tool. Composition is the goal.
This is why the people who'd never used Shadow DOM in real life get really hung up on the details of encapsulation, while those who actually use Shadow DOM stare at them quizzically.
If you walk into another author's DOM tree and starts messing with it, you simply lose the right to compose. It's not about one party wanting to prevent another party from doing stuff. It's about both parties having a straightforward composition contract and, given the mutual agreement, the resulting ability to build wonderful things. Should one party muck with this contract, the onus is clearly on that party to live with the consequences.
This is strikingly different from the today's world, where the composition contract is at best a convention, of which all participating parties must be aware. It's also exceedingly easy to fall off this convention and often hard to determine whodunnit.
Now, it's not to say that things couldn't possibly go wrong. An opinionated framework could come up with a concept where breaking the Shadow DOM composition contract is the norm and thus render the whole thing useless -- at least in the context of that framework. But just like we can't stop people from doing other crazy things with their lives, we can't be stressing over these scenarios.
What we need to be stressing over is enabling Web developers to do the right thing and not forget that there are many kinds of them. While the widget users and even widget developers might not mind your overprotective attitude, the authors of the framework and tools that support those frameworks--the actual enablers of the widget ecosystems--will go into extreme length to work around encapsulation boundaries and curse you through their entire path.
I have same view point, We're not just creating components, we're still creating widget html snippets that help us take a shortcut into componentization of web. Which in my humble opinion is far beyond our perception of true components.
By common history take a look at the Actionscript 3.0 UI Components introduced to market circa 2006. Turns out that was so out of customization that we couldn't even write a complete set top box of new implementations of current uses.
Polymer Project, Brick, Blink, X-tags are all implementation of a single Object DOM element, while we don't have a truly Class support by Javascript we will still get only fair amount of tags that needs more polish than DRY.