- From: <bugzilla@jessica.w3.org>
- Date: Fri, 21 Nov 2014 18:46:54 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27401
Bug ID: 27401
Summary: [Shadow]: Fully explore composition
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglazkov@chromium.org
Reporter: dglazkov@chromium.org
QA Contact: public-webapps-bugzilla@w3.org
CC: mike@w3.org, public-webapps@w3.org
Blocks: 14978
This is a meta bug for polishing Shadow DOM as a composition primitive.
https://gist.github.com/dglazkov/716913d889c38e42d55c
With Shadow DOM, the developers finally have the composition boundaries to help
them reason about larger web apps in terms of smaller chunks. The actual
concept is not unique. What's unique about it is that the Web Platform is also
aware of these boundaries.
We have a whole set of challenges ahead of us. We need to make sure that the
composition boundaries have the right crunchy/gooey balance to be truly useful,
we need to build introspection tooling to make these composition boundaries
more grokkable. We also need to ensure that these boundaries are designed in a
way that allows the browser to help developer build modern UX
(http://bit.ly/blink-midnight-train as an example of UX guidelines).
Some of these challenges are conflicting with each other, and the problem
easily gets into the over-constrained territory.
We also need better terminology. "Information hiding" sounds negative and
purposeless. Why would anyone want to hide information?
"Encapsulation" is a super-overloaded term. When you say it to one crowd, they
hear iframe. To another crowd, it sounds like something different.
I suggest we use the term "composition" and see how far we can get.
For example, the question "when should I put things in Shadow DOM?" is a
symptom of approaching the problem from the wrong angle. It's effectively the
same question as "when should I put things in a class?"
I, as a developer, should use Shadow DOM when I need to draw composition
boundaries in my code. The consistency of these composition boundaries should
be flexible enough to express the degrees of composition I need in each
particular case.
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. However, it's equally non-sensical for <datetime-input> element to _not_ do
that.
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 21 November 2014 18:46:56 UTC