Re: [shadow dom] relitigation

On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>
> On Dec 17, 2014, at 3:18 PM, Brian Kardell <bkardell@gmail.com> wrote:
>
> On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa <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.
>

Hopefully you don't mean this to the extent it sounds.  A whole lot of the
Web doesn't follow this model and there is a point past which this approach
increases complexity to the point where it is unmanageable. If tomorrow
everyone shipped these APIs interoperably (I won't hold my breath, I'm just
making a point) then within a few months this would be the common target
for vast swaths of the Web and private enterprise, try surfing the Web with
IE6 and if you're very lucky most of it will simply be prompting you to
upgrade your browser.  If your point is simply that until this is the case,
you'll have to ship polyfills - that's my whole point.  It's impossible to
polyfill that which is not yet agreed to, and where this fits in the puzzle
it's hard to even get it close.  If we were to say 'it's going to work just
like it does in chrome when we get around to it, and we will' (note: not
advocating this, just making a point) then there would be good reason to
consider using the polyfill.  Currently, it looks more like a prollyfill
and you might be stuck with it forever.  If we were stuck with
.registerElement forever, or even HTML Imports, it's probably not the end
of the world.  If they work for you today, they should work even better for
you tomorrow as the trend of perf is always faster.  But shadow dom is big
and complex and a different kind of bet.  We might be willing to use it for
development, even in production for smaller projects if it looks pretty
probable that we'll remove it and gain perf and drop the scary code.  It's
a different proposition if you can't.



>
> 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.  Did anyone else bite on it?  I don't see anything
positive, but it's possible I missed it given that I was away during this
time.  I'm very curious on where that landed though in terms of who else
thought this was a problem/needed addressing like this.  #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?

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.

Believe it or not, I'm not interested in the politics of right or wrong
about shipping, I'm interested in finding a path forward that allows
competition in a healthy way.  A bad answer would be bad, I don't disagree
- but an imperfect answer isn't the same thing.  So that's my question: Is
it bad (in the sense that more than 1 person can be convinced of the same
bad aspects). If so, what do we need to fix to make it just imperfect, but
hopefully something we can iterate on?



>  We've been extremely firm on this position but we don't feel compelled to
> keep making the same point every six months.  We also care about the
> cross-origin use cases as we outlined last year [2].  In addition, we feel
> strongly that the current model of inheritance is broken [3].  These are
> three significant differences I can think of off the top of my head now.
>
> Is there any hope of resolving that if that's what you mean, or would this
> require significant change?
>
>
> Addressing these concerns would likely result in a lot of changes to the
> Shadow DOM specification.  This is precisely why we tried to give much of
> our feedback as early as we could.
>





> - R. Niwa
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html
> [3]
> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
>
>

-- 
Brian Kardell :: @briankardell :: hitchjs.com