- From: <bugzilla@jessica.w3.org>
- Date: Tue, 24 Feb 2015 02:00:26 +0000
- To: public-webapps-bugzilla@w3.org
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