Re: Shadow tree style isolation primitive

> On Feb 5, 2015, at 3:51 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
> 
> On Thu, Feb 5, 2015 at 2:53 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
> 
>> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov <dglazkov@google.com <mailto:dglazkov@google.com>> wrote:
>> 
>> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay <olli@pettay.fi <mailto: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 <https://wiki.whatwg.org/wiki/Component_Model> and https://wiki.whatwg.org/wiki/Component_Model_Use_Cases <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 <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.

Okay.

> 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 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775>), enabled by a flag as we discussed at the spring session.

Like we've argued many times in the past, type II encapsulation should be default and components should opt-in to open up its internals.  In that regard, our position perfectly aligns with what Olli says.  That is, representatives of two major browser vendors agree on this matter.

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

Like I've mentioned in the past, we did a through case study of this model and we've discovered a number of problems with existing web components features that we believe are not fixable in the future.

If you're asking us to go study layout manager use case, which we did do, please go study our use case as well.

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

Sorry, maybe I was short on words.  What I meant is that they're not needed for builtin elements.  During our study of layout manager use case, we did come to consolation that something akin to insertion points and node distributions are necessary.

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

I am not.  Supporting multiple generations of shadow DOM dramatically increases the complexity of the feature as we've stated in the past numerous times.  We're not speculating that this increases the complexity.  We know it does because we removed the code Google added in WebKit in order to support this feature.

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

It seems like there was a miscommunication on this matter then.  Like I stated in public-webapps at the time, a regular VC meeting is not something I have a time to attend.  We would like to continue our discussion on the mailing list instead.

And we're more than interested in solving this problem although we're focused on figuring out various aspects of custom elements at the moment.

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

Thanks for the clarification.

> 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 <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 understand and respect that you care about that use case but others may not.

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

I'll eventually do that although they're nothing to do with web components so it will be on another thread or another working group.

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

I don't think it's fair to say nobody has committed to work on this.  We've been responding to various threads and bugs for the past one year, keep re-stating our position on various matters.  In fact, there was a numerous agreement to add the flag to "seal" shadow DOM in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775> but that still hasn't happened yet in the spec.

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

Again, I don't think it's fair to expect for non-editor participants of the working group to write spec patches.  It's the duty of spec. editors to document upon what the working group has agreed.

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

I think we did that two years ago: https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html

- R. Niwa