[shadow dom] relitigation
I hate to tear open a wound, but it seems to me that two important browser vendors have yet to buy into Shadow DOM. It's currently listed by Microsoft as under consideration but the sense I get is that the signal isn't very positive right now. Firefox is planning to move forward, Blink has it unprefixed. Things like document.register can be polyfilled fairly well and without too much crazy. If imports is controversial or we determine that we need more experimentation to figure out what's down there in terms of other systems like modules or fetch - we can do a lot of those experiments outside any browser implementation too and use it to lead discussions. I am all for that, especially if we can lead the way in getting vendors to cooperate on the polyfills and make some efforts to find future safe ways to do this. But Shadow DOM - this is a different story. It might not be a fundamental primitive or DNA level thing, but it's well down there and actually impossible to polyfill accurately and it is dark, dark magic requiring lots of code to even fake it reasonably well. There's a real risk there is that the fidelity could actually cause problems when you jump to native too, I think. There seems to be a pretty large split in sentiment on Shadow DOM, or perceived sentiment from developers. From my perspective, a whole lot of people tell me that they find Shadow DOM one of the most compelling pieces of custom elements and without it, they're holding off. Another thing they tell me that frustrates them is that this makes it hard to share custom elements - should they assume a Shadow DOM or not. With Mozilla's post the other day[1] this has opened up a whole lot of new conversations on my part and the preeminent question seems to be whether there will be a positive signal from Apple or Microsoft or whether we need to consider that as good as vapor for now. For a lot of orgs, consideration of switching to custom element and their plan for the next few years is probably affected, as well as the state of the landscape and where we will be shaping it. With this in mind, I'm asking if anyone is willing to tip their hand at all - even to the effect that if we get two interoperable, unprefixed versions, we will follow... Any information I think is helpful - and asking the question at least might move the conversation forward again (I hope)? 1 - https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [shadow dom] relitigation
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. - R. Niwa On Dec 17, 2014, at 12:55 PM, Brian Kardell bkard...@gmail.com wrote: I hate to tear open a wound, but it seems to me that two important browser vendors have yet to buy into Shadow DOM. It's currently listed by Microsoft as under consideration but the sense I get is that the signal isn't very positive right now. Firefox is planning to move forward, Blink has it unprefixed. Things like document.register can be polyfilled fairly well and without too much crazy. If imports is controversial or we determine that we need more experimentation to figure out what's down there in terms of other systems like modules or fetch - we can do a lot of those experiments outside any browser implementation too and use it to lead discussions. I am all for that, especially if we can lead the way in getting vendors to cooperate on the polyfills and make some efforts to find future safe ways to do this. But Shadow DOM - this is a different story. It might not be a fundamental primitive or DNA level thing, but it's well down there and actually impossible to polyfill accurately and it is dark, dark magic requiring lots of code to even fake it reasonably well. There's a real risk there is that the fidelity could actually cause problems when you jump to native too, I think. There seems to be a pretty large split in sentiment on Shadow DOM, or perceived sentiment from developers. From my perspective, a whole lot of people tell me that they find Shadow DOM one of the most compelling pieces of custom elements and without it, they're holding off. Another thing they tell me that frustrates them is that this makes it hard to share custom elements - should they assume a Shadow DOM or not. With Mozilla's post the other day[1] this has opened up a whole lot of new conversations on my part and the preeminent question seems to be whether there will be a positive signal from Apple or Microsoft or whether we need to consider that as good as vapor for now. For a lot of orgs, consideration of switching to custom element and their plan for the next few years is probably affected, as well as the state of the landscape and where we will be shaping it. With this in mind, I'm asking if anyone is willing to tip their hand at all - even to the effect that if we get two interoperable, unprefixed versions, we will follow... Any information I think is helpful - and asking the question at least might move the conversation forward again (I hope)? 1 - https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [shadow dom] relitigation
On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa rn...@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. - R. Niwa Ryosuke, Thanks for your response. 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 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? Is there any hope of resolving that if that's what you mean, or would this require significant change? Here's what I actually am unclear on at the end of the day: Technicalities around REC or process or politics aside - If we wind up with two interoperable implementations in FF and Blink, will you still feel there is something that needs addressing before sending the positive signal that it'll eventually get implemented in Webkit? If so, I feel like, as a developer, now is the time I'd like to learn that. Just as it is frustrating to you above - it seems will be all the more frustrating for everyone if that becomes the case and honestly, the development world is just guessing what may be wildly uninformed guesses... That seems bad. If we need to have hard discussions, let's have them and get it out of the way even if the result is something somewhat less than a commitment. That's my 2 cents, anyway. I'm not the chair, I'm not even a member - it's just something I hear a lot of people discussing and thought worth bringing into the open. Brian Kardell :: @briankardell :: hitchjs.com
Re: [shadow dom] relitigation
On Dec 17, 2014, at 3:18 PM, Brian Kardell bkard...@gmail.com wrote: On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@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. 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
Re: [shadow dom] relitigation
On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 17, 2014, at 3:18 PM, Brian Kardell bkard...@gmail.com wrote: On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa rn...@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
Re: [shadow dom] relitigation
On Dec 17, 2014, at 6:16 PM, Brian Kardell bkard...@gmail.com wrote: On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Dec 17, 2014, at 3:18 PM, Brian Kardell bkard...@gmail.com mailto:bkard...@gmail.com wrote: On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@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
