[Bug 27401] [Shadow]: Fully explore composition

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

Olli Pettay <bugs@pettay.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs@pettay.fi

--- Comment #1 from Olli Pettay <bugs@pettay.fi> ---
(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>

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

Received on Friday, 21 November 2014 21:12:41 UTC