[Bug 27401] [Shadow]: Fully explore composition

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27401

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |travil@microsoft.com

--- Comment #5 from Travis Leithead [MSFT] <travil@microsoft.com> ---
I love this meta-bug :)

When you use the word "composition", I think of making a big pot of chili--all
the ingredients are throw into the pot and mixed together to form a whole. In
web components, the hosting page is the pot, and the elements it contains have
been "composed" into it. In my mind, isolation in a composed environment is
what gives you a component. So, prior to the days of "web components" we
already had at least one component: the <iframe> (and window.open, framesets,
object tag, etc., etc.).

So what makes web components different? What makes them a better solution than
<iframe> (which is an incredibly popular component model today :-)?

>From what I understand, its that iframe's isolation is too strict for certain
composition scenarios. Iframe isolates along all three vectors of the
web--isolated script environment, isolated CSS environment, and isolated
document and URL. Of course, we've slowly refined this model over time:
document.domain opt-ins, postMessage passing, sandbox, and seamless attributes,
etc. Yet, it's still not what folks are looking for in a web component model.

So, we took web components to the opposite side of the spectrum--we built a web
components model that did an absolutely minimal job of isolation. No script
environment isolation, no CSS isolation, an open bridge to the shadow content.

As pointed out above, what we have is very complicated and could be
accomplished through much simpler means. I propose the question: was turning
from strong isolation to the current model a swing too far in the opposite
direction? 

iframes force component authors to work closely together with the content that
hosts them: the content within the iframe cooperating with iframe's host
environment. This is a well-oiled machine thanks to the enforcements of the
same-origin security model. This forces good encapsulation, good contracts,
etc. The disadvantages already noted still apply though--it's not an
integrated/composed solution.

Yet, we loose something significant with the way shadow dom is built
today--there is no more cooperation! In fact, the component's sense of identity
is completely lost. The hosting page has full control, full access and full
veto power. If you look at it from the host's POV, this seems fine (they get
full integration rights). But from the POV of the component author, there are
difficult challenges with today's model--and I think we see them in the
concerns regarding "open or closed" scripting, defining parts/states or >>> for
CSS. 

Basically, I think that went too far away from isolation. We built the right
primitives for a host to assemble a component model, but we dropped the
isolation scenarios that are still important in scripting and CSS for
components that might not want to cede full access to the host.

Where am I going with this? I think we need to take a very careful look at the
script and CSS isolation models and what might be done to improve the
state-of-the-art in that respect. Depending on the outcome, it could lead to a
much simpler shadow dom model--which I think is still the right primitive at
its core.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 24 February 2015 02:00:30 UTC