[Bug 27401] [Shadow]: Fully explore composition

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

--- Comment #2 from Dimitri Glazkov <dglazkov@chromium.org> ---
(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.

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

Received on Friday, 21 November 2014 23:38:33 UTC