Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 2:53 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
>
> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay <olli@pettay.fi> wrote:
>
>> On 02/05/2015 02:24 AM, Dimitri Glazkov wrote:
>>>
>>> However, I would like to first understand if that is the problem that
>>> the group wants to solve. It is unclear from this conversation.
>>>
>>
>> Yes. The marketing speech for shadow DOM has changed over time from "do
>> everything possible, make things awesome" to "explain the platform"
>> to the current "enable easier composition".
>> So it is not very clear to me what even the authors of the spec always
>> want, this said with all the kindness :)
>>
>
> I appreciate the affirmation, the kindness, and the smiley. Though since
> this is public forum, I have to add a few things:
>
> 1) The original "Component Model" (as it was known back then) charter from
> 2011 clearly includes easier composition as one of its main goals, as
> illustrated by https://wiki.whatwg.org/wiki/Component_Model and
> https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we
> definitively solved at huge chunk of these problems. For example, Polymer
> is a clear illustration that
> https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager  is
> nearly 100% solved and there are now examples in the wild of most of these
> use cases solved with Web Components. There's still lots of work to do, of
> course. But
>
> 2) Refining terminology and the way to describe problem space is a natural
> part of working on solutions for that problem space. Calling it "marketing"
> is just not helpful.
>
>
> I agree his wording was a bit harsh.  But let me try to explain where Olli
> is coming from because I do sympathize with what he's saying here.
>

Let's do it.


> For example, at the WebApps F2F meeting last spring, you mentioned that
> explaining builtin element is a goal of web components.
>

Yep. I would like to emphasize that "explaining the platform" is not a
self-goal. It's a constraint, which helps guiding the thinking about new
primitives and behaviors. Relying on builtin elements to inform discovery
of Shadow DOM was a real thing. I hope you remember me going through that
huge refactoring in WebKit.



> Yet, the web components as spec'ed today doesn't explain any builtin
> elements due to its lack of strong encapsulation.
>

There are two distinct concepts mixed in here:

1) the type 2 encapsulation. There's no barrier for this to happen. There's
broad agreement that we should do it, and even recent work by hayato on
outlining specific places where the "open" and "closed" modes differ. The
research he provided shows that it's a fixed set of changes (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775), enabled by a flag as
we discussed at the spring session.

2) the actual, honest-to-goodness security boundary (isolation) that
builtins enjoy thanks to the C++/JS bindings layer. This is a much more
difficult problem, but something we definitely want to tackle at some point
in the future. Maybe Realms are the answer.


> And insertion points, which is a huge source of complexity, is only needed
> to explain details and summary elements.
>

For builtins, yes. For general composition problem, they are essential.


> The ability to attach multiple generations of shadow DOM to a single host
> element, which is another source of an enormous complexity, is not required
> to explain any builtin HTML elements at all as far as I know.
>

This is true. Multiple roots per element is an extension that enables
reasoning about subclassing in terms of DOM. You are definitely overstating
the complexity. It's not that difficult -- just a list of pointers instead
of one pointer.


>  So it appears that there is a precedence in adding features to Web
> components that are not needed for builtin elements but desirable for other
> use cases.
>

This is where my intro sentence is useful. Explaining builtins is not a
self-goal. We browser developers don't _need_ to explain the platform for
any other purpose other than extracting useful primitives for web
developers.


>  Yet, you (Google representatives as the collective) in the past argued
> that you didn't want to add support for imperative API for selecting
> distributed elements because that can't explain builtin elements even
> though we've listed a few use cases that can't be adequately addressed
> unless we have an imperative API.
>

The distribution discussion terminated early because the people who were
interested in solving this problem withdrew from it. I even organized a
regular VC to facilitate the work, but there was no interest. I am still
interested in developing a good distribution API, but I don't want to walk
alone.


>
> So I have a hard time understanding that exactly which use cases and
> problems you're trying to solve (and have solved) in web components because
> it seems to drift left and right every time we discuss different issues.
>

I hope this clarifies it.


> Let us not discuss goals and objectives, etc… because they're too abstract
> at this point.
>
> Personally I think composition piece itself doesn't legitimate the
>> complexity of shadow DOM.
>>
>
> I accept this as a personal opinion, not a fact.
>
>
> Like I mentioned earlier in the thread, I fully agree with Olli's position
> here.  I don't think I'll be interested in implementing shadow DOM in
> WebKit at all if the only use case we're solving at first is the layout
> manager use case.
>

Don't diminish "only Layout Manager" case. It's effectively the Holy Grail
of any UI toolkit. Also -- please go over the use cases. Once
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775 is fixed, we would've
solved all but one of them (the +1 button).


> I've done a fair amount of web programming myself, and most recently I've
> been using Ember.js to write a new UI for our performance dashboard.
> Granted, I only have ~5000 lines of JS code so it's not nearly as big as
> Gmail or many other modern Web apps but I've encountered a lot more
> pressing issues that need to be addressed in the platform than having to
> soft-ecapsulate DOM and CSS rules.
>

Would love to hear about them (maybe in a separate thread). Please don't
discount other people's experiences based on your own.

So again, I'd like to remind us all that different participants of the
> working group care about different use cases.  Like you regard the layout
> manager use case to be very important, others regard other use cases to be
> much more important.  We all have differences in opinions.  We need to find
> a point to where we can all compromise or else we'll never agree on
> anything ever.
>

Agreed! My biggest problem so far has been that nobody had committed to
resolving the differences long enough (or productively enough) to move this
forward.

As a positive example, accessibility folks were asking questions about
semantics of custom elements. So Steve Faulkner rolled up his sleeves and
knocked out an excellent section in the spec, submitted a pull request, and
got it landed within minutes.


>
> Is event retargeting part of composition?
>
>
> This one is something I am eager to explore. Event retargeting came
> directly from trying to address the goal of explaining the native controls,
> and it might be something we could separate from the pure composition
> primitive.
>
>
> Indeed.  I've talked with multiple Web developers over the last couple of
> years and they all raised the concern over the event retargeting mechanism
> being baked into the browser.
>
> That said, I think we should aim for something stronger than just enabling
>> easier composition.
>> The end goal could go as far as let pages to implement their own form
>> controls. And to make that
>> all less error prone for the users of such components requires
>> encapsulation.
>>
>
> Again, I accept this as a personal opinion, but I would like to push back
> on this. Stronger encapsulation comes with its own host of problems for
> developers. Before taking this as a fact, I encourage first exploring the
> trade-offs and trying to prototype/build/tool/test components. I've done
> it. I've learned the lesson.
>
>
> I don't think Olli needs to do that exercise to know there are valid use
> cases.  Social sharing buttons are everywhere on the Web, and being able to
> encapsulate them will benefit the Web.
>

Great! Let's discuss how social sharing buttons should work, what the
requirements are, and how Web Components could be used to benefit from
them. Maybe not on this thread.

:DG<