Re: [shadow dom] relitigation

> On Dec 17, 2014, at 6:16 PM, Brian Kardell <bkardell@gmail.com> wrote:
> 
> On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
> 
>> On Dec 17, 2014, at 3:18 PM, Brian Kardell <bkardell@gmail.com <mailto:bkardell@gmail.com>> wrote:
>> 
>> On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
>> Hi Brian,
>> 
>> The WebKit team has given a lot of feedback over the years on the Shadow DOM spec.  We wouldn't have done that if we didn't care about it. :)  We're excited to hear that Mozilla is planning to give more feedback on Custom Elements and Shadow DOM because we feel that much of their feedback resonates with us.
>> 
>> Having said that, our feedback has largely been dismissed or has not been adequately addressed.  I'm sure you can imagine that this does not encourage us to invest much more time or effort into providing additional feedback.
>> 
>> I can definitely appreciate that when you sink time into discussion and things don't appear to go that way it seems frustrating and doesn't promote good feelings about investing further.  At the same time, I'm sure you can appreciate that this leaves things in a frustrating/confusing spot for so many developers and their orgs around the world because of where this particular piece of the puzzle lies.  I'm glad to hear that Mozilla's position/feedback resonates but I'm still unclear.
> 
> I sympathize with the sentiment.  However, regardless of which browsers implement Shadow DOM and Custom Elements today, Web developers won't be able to use them without fallbacks since many users would be using older Web browsers that don't support these features.
...
>> I have followed all of these discussions pretty closely and even today after some searching I am not sure about which feedback regarding Shadow DOM specifically you feel still requires addressing?  Discussion about type 1, 2 boundary seems to have died off - was there some other?
> 
> We've argued not to expose the shadow root of a host by default many times.  In fact, we got an agreement over a year ago to add a private mode (type II encapsulation) to the Shadow DOM.  However, the corresponding bug [1], which was filed in November 2012, hasn't been resolved yet.
> 
> Yes, I commented on it then too... thanks for the other links below too, I couldn't find them but I recall now.  To be honest, I didn't get the relationship with the transclusion thing[2] even then - seemed to mix concerns to me.

There are two main problems with <shadow> as a function [1]

1. It mixes two concerns: a. binding light DOM's content into a shadow DOM; b. providing an inheritance hook.
2. A subclass defines where to insert its superclass's view (shadow DOM) instead of the superclass defining which parts could be overridden by its subclasses.

For the second point, I've even provided two JS template libraries that support inheritance [2] [3].

> #3 seems mostly relevant to things beyond shadow root, like how it fits with imports.  Is there some way to limit the scope and solve Shadow DOM L1 without imports and saying only in the same origin or something?

It's extremely relevant.  We're proposing to reuse Shadow DOM to provide builtin-element like encapsulation/security boundary, and adding encapsulation like that after the fact is really hard.  We've given the feedback we've given after making that thought experiment.

> What about this? Is it plausible to fork the draft and the prollyfills in polymer and work out a counter-proposal?  While some might be unhappy that Chrome released something unprefixed/not flagged on this front, you have to at least give the Polymer guys mad props for the effort to ship a prollyfill that works in all of the mainstream, modern browsers.

I'm not interested in contributing patches to Polymer or writing new prollyfills at this moment if that's what you're asking.

To be honest with you, I invested way too much time into this last year, and I really feel bad about wasting a lot of my colleagues' precious time for it as well.  As such, in my very personal opinion, I'm extremely reluctant in putting my time into making the same points we've made in the past unless I see a clear evidence that our feedback will be addressed promptly this time around.

- R. Niwa

[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html <http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html>
[2] http://paularmstrong.github.io/swig/docs/#inheritance
[3] http://jlongster.github.io/nunjucks/templating.html#template-inheritance