(In reply to Dimitri Glazkov from comment #0)
> We also need better terminology. "Information hiding" sounds negative and
> purposeless. Why would anyone want to hide information?
negative? To me information hiding sounds like a positive thing.
You expose only what you need to and the outside world should be ok with that.
It is up to you to expose what you want, and if you aren't exposing enough, the outside world can't really
co-operate with or approve you.

> "Encapsulation" is a super-overloaded term. When you say it to one crowd,
> they hear iframe. To another crowd, it sounds like something different.
Indeed

> I suggest we use the term "composition" and see how far we can get. 
Composition doesn't really say much. Composition of what, or which objects or well, what?

> For example, the question "when should I put things in Shadow DOM?" is a
> symptom of approaching the problem from the wrong angle.
Why?

> It's effectively
> the same question as "when should I put things in a class?"
Object oriented languages are pretty popular, and there classes have proved to be
rather useful abstractions. (Even JS is getting classes)


> I, as a developer, should use Shadow DOM when I need to draw composition
> boundaries in my code.
One question is that why to use shadow DOM when you can achieve the same approach by just 
using DOM/CSS classes. If you consistently annotate your elements with the right class, and deal with
with those explicitly or deal with all the elements regardless of class attributes, you end up to
quite similar (not the same) setup to non-information-hiding-nor-encapsulating-shadow-dom.

 
> For example, when I build a <my-app> element, it seems nonsensical for
> document.activeElement to return <my-app> when I focused something inside of
> it.
Er, what? I'd definitely expect document.activeElement to return my-app since that is what the outside
world should see.
If you don't want any encapsulation or information hiding, just don't use shadow DOM.

 
> Unfortunately, too often, "flexibility" is another word for "added
> complexity" and "unpredictable performance characteristics". This is the
> hardest constraint. We should avoid adding more bloat to the platform.
Yeah, I've been thinking this lately. By default shadow dom makes many things slower.
Perhaps not much, but still does. (More complicated event propagation, more complicated element bind-to-tree/unbind-from-tree, etc).




The following is just something I've been thinking and shouldn't be taken too seriously:
Since the current form of web components doesn't really provide what I'd call information hiding or encapsulation, and
perhaps those aren't even goals in its current incarnation, maybe it would be simpler to just not have shadow DOM
for the cases where those aren't needed.
If one could say "this particular subtree is my component", that might help already.
Perhaps it would mean replacing/renaming elements with similarly behaving elements or annotating elements in some other way.
Insertion points would be there just in the initial step to put the elements from the outside world to the right places
in the DOM tree.


<div id="myComponent">
  <span><content></span>
</div>

<div id="d">normal dom.</div>

document.getElementById(d).installComponent("myComponent");

->

<div id="d">
  <span class="myComponent">normal dom.</span>
</div>

(In reply to Olli Pettay from comment #1)
> (In reply to Dimitri Glazkov from comment #0)
> > We also need better terminology. "Information hiding" sounds negative and
> > purposeless. Why would anyone want to hide information?
> negative? To me information hiding sounds like a positive thing.
> You expose only what you need to and the outside world should be ok with
> that.
> It is up to you to expose what you want, and if you aren't exposing enough,
> the outside world can't really
> co-operate with or approve you.
> 
> > "Encapsulation" is a super-overloaded term. When you say it to one crowd,
> > they hear iframe. To another crowd, it sounds like something different.
> Indeed
> 
> > I suggest we use the term "composition" and see how far we can get. 
> Composition doesn't really say much. Composition of what, or which objects
> or well, what?
> 
> > For example, the question "when should I put things in Shadow DOM?" is a
> > symptom of approaching the problem from the wrong angle.
> Why?

See the rest of that sentence, it meant to all work together :)

> 
> > It's effectively
> > the same question as "when should I put things in a class?"
> Object oriented languages are pretty popular, and there classes have proved
> to be
> rather useful abstractions. (Even JS is getting classes)

Exactly my point. The question of when I should put things in a class is along the same lines -- you do it when it's useful for your software engineering needs.

> 
> 
> > I, as a developer, should use Shadow DOM when I need to draw composition
> > boundaries in my code.
> One question is that why to use shadow DOM when you can achieve the same
> approach by just 
> using DOM/CSS classes. If you consistently annotate your elements with the
> right class, and deal with
> with those explicitly or deal with all the elements regardless of class
> attributes, you end up to
> quite similar (not the same) setup to
> non-information-hiding-nor-encapsulating-shadow-dom.

Shadow DOM is not a capability. It's a productivity tool. At the limit, you can achieve the same things with a stick and a rock that you can achieve with a power tool. The difference is in the level of patience, discipline, and effort it takes.

> 
>  
> > For example, when I build a <my-app> element, it seems nonsensical for
> > document.activeElement to return <my-app> when I focused something inside of
> > it.
> Er, what? I'd definitely expect document.activeElement to return my-app
> since that is what the outside
> world should see.
> If you don't want any encapsulation or information hiding, just don't use
> shadow DOM.

As I mentioned, Shadow DOM is about composition. Encapsulation and information hiding are just facets of composition. There are more.

> 
>  
> > Unfortunately, too often, "flexibility" is another word for "added
> > complexity" and "unpredictable performance characteristics". This is the
> > hardest constraint. We should avoid adding more bloat to the platform.
> Yeah, I've been thinking this lately. By default shadow dom makes many
> things slower.
> Perhaps not much, but still does. (More complicated event propagation, more
> complicated element bind-to-tree/unbind-from-tree, etc).

In some cases yes, but in some cases it's actually a win. Style resolution is easier because of inherent scoping.

I would also be interested in figure out ways in which we could turn off or simplify event retargeting for developers who aren't interested in it, or similar performance-optimizations for distributions, etc.

I am realizing now that I severely over-constrained the problem space by trying to solve both "explain HTML form elements" and "enable composition" with the same primitive. It seemed like a great idea at the time, because the former problem helped the latter stay more opinionated about the HTML/DOM ways and not get too crazy.

> 
> The following is just something I've been thinking and shouldn't be taken
> too seriously:
> Since the current form of web components doesn't really provide what I'd
> call information hiding or encapsulation, and
> perhaps those aren't even goals in its current incarnation, maybe it would
> be simpler to just not have shadow DOM
> for the cases where those aren't needed.
> If one could say "this particular subtree is my component", that might help
> already.
> Perhaps it would mean replacing/renaming elements with similarly behaving
> elements or annotating elements in some other way.
> Insertion points would be there just in the initial step to put the elements
> from the outside world to the right places
> in the DOM tree.
> 
> 
> <div id="myComponent">
>   <span><content></span>
> </div>
> 
> <div id="d">normal dom.</div>
> 
> document.getElementById(d).installComponent("myComponent");
> 
> ->
> 
> <div id="d">
>   <span class="myComponent">normal dom.</span>
> </div>

Yes! This is effectively what Shadow DOM and custom elements do today. The custom elements are the insertion points. That's why we built this whole Web Components thing. But don't listen to me, listen to this guy: https://www.youtube.com/watch?v=6vcQlD-jadk. He's not great, but tries to explain the overall approach bottom-up.

(In reply to Dimitri Glazkov (afk until Dec 1, 2014) from comment #2)
> > > For example, the question "when should I put things in Shadow DOM?" is a
> > > symptom of approaching the problem from the wrong angle.
> > Why?
> 
> See the rest of that sentence, it meant to all work together :)
It still doesn't say why 
'the question "when should I put things in Shadow DOM?" is a
 symptom of approaching the problem from the wrong angle'


> Exactly my point. The question of when I should put things in a class is
> along the same lines -- you do it when it's useful for your software
> engineering needs.
Hmm, somehow I'm misreading you here, I think. Since yes, this is all about
usefulness. But the question is what are the use cases. The level of information hiding and encapsulation
affect quite a bit to the possible use cases.



> I am realizing now that I severely over-constrained the problem space by
> trying to solve both "explain HTML form elements" and "enable composition"
> with the same primitive.
That indeed may have lead to some confusion. It has not been too clear always what
Shadow DOM is aimed for.


> Yes! This is effectively what Shadow DOM and custom elements do today. The
> custom elements are the insertion points. 
But why the need for shadow DOM then? Why the need for making the platform much more complicated when
something simpler might have been enough. (if we didn't have shadow DOM, we wouldn't have to modify event dispatch, nor go through
all the spec and their use of is-in-document etc.)

(In reply to Olli Pettay from comment #3)
> (In reply to Dimitri Glazkov (afk until Dec 1, 2014) from comment #2)
> > > > For example, the question "when should I put things in Shadow DOM?" is a
> > > > symptom of approaching the problem from the wrong angle.
> > > Why?
> > 
> > See the rest of that sentence, it meant to all work together :)
> It still doesn't say why 
> 'the question "when should I put things in Shadow DOM?" is a
>  symptom of approaching the problem from the wrong angle'

Let me try this way: the answer to this question is not specific to Shadow DOM, it's a general OOP question. Thus, the angle of looking at it as feature-specific practices is wrong.

> 
> > Yes! This is effectively what Shadow DOM and custom elements do today. The
> > custom elements are the insertion points. 
> But why the need for shadow DOM then? Why the need for making the platform
> much more complicated when
> something simpler might have been enough. (if we didn't have shadow DOM, we
> wouldn't have to modify event dispatch, nor go through
> all the spec and their use of is-in-document etc.)

I disagree. Having gone over this exercise many times in the last few years, I am convinced that we have the right solution shape. We do need to make sure we give developers the ability to opt in/out with some features. That's what this bug is about.

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.

(In reply to Travis Leithead [MSFT] from comment #5)

Thanks for the insightful comment.

> 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.

Could you look over https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits and see if there are any bits that are missing or any pros/cons that are not mentioned? Appreciate any help in improving the wiki doc ahead of the F2F.

Moved to https://github.com/w3c/webcomponents/issues/69