Re: [webcomponents]: Let's reach consensus on Shadow DOM
On Sun, Feb 8, 2015 at 10:17 AM, Ryosuke Niwa rn...@apple.com wrote: One more thing. I think it's nice to have a new comprehensive list of use cases participants have come up over the years on the same document since the wiki page is quite outdated. I spent the last couple of weeks working on this. Here's what I have so far: https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Refresher I am still updating the examples. Any help in finishing this is appreciated. :DG
Re: [webcomponents]: Let's reach consensus on Shadow DOM
On Sat, Feb 7, 2015 at 12:25 AM, Dimitri Glazkov dglaz...@google.com wrote: So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits This is really great Dimitri, thanks. All the pointers to past discussion help a lot as well. When we discussed shadow DOM at Mozilla at the end of last year, this was roughly our thinking for the various points listed: A) Having shadow inheritance would be useful and is actually something we use in Firefox UI (through XBL). B) We would prefer encapsulation by default. C) We would like to come up with a distribution API. (I need to grasp the distribution algorithm a bit better. It's still a bit unclear to me why we can do it lazily while everything else in DOM is live.) D) We would like these to be separated. E) When we discussed this there were no clear thoughts on styling. There was interest for having some kind of way to style the component while letting the component retain control over what the outside can actually affect. Possibly through CSS variables or some way to restrict what properties apply. My personal worry with shadow DOM is that frameworks such as React and perhaps also Ember now are going in quite a different direction. Perhaps a bit more hostile towards DOM, but with server-side rendering not necessarily more hostile towards users. So while we solve a problem some developers have today, it's not necessarily clear this is how pages will be written going forward. -- https://annevankesteren.nl/
Re: [webcomponents]: Let's reach consensus on Shadow DOM
One more thing. I think it's nice to have a new comprehensive list of use cases participants have come up over the years on the same document since the wiki page is quite outdated. - R. Niwa On Feb 8, 2015, at 10:14 AM, Ryosuke Niwa rn...@apple.com wrote: Hi Dimitri, Thanks for writing up that page. I think it's valuable to have some documentation like this since the discussion has been scatters across many threads and a long time span. Another point of contention appears to be how show isolation is done particularly in the world where we've separated style isolation from event retargeting. I also think it would be valuable if you (or someone else) could add the description for which use case and scenario each feature is needed or used. That way, we can make an informed assessment of whether a new unicorn people come up withstands all the requirements the original unicorn satisfied, and if not, whether the trade off is acceptable or not. - R. Niwa On Feb 6, 2015, at 3:25 PM, Dimitri Glazkov dglaz...@google.com wrote: Folks, I wrote a long email, replying to each point where I agreed/differed with Ryosuke, and then deleted it, realizing I wasn't being productive. So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits We are at a point where there are hard choices to be made. But with the 4+ history of the adventure, it's nearly impossible for everyone to recall or catch up on discussions and relevant insight. With this doc, I am hoping we'll get on the same page and make way. :DG
Re: [webcomponents]: Let's reach consensus on Shadow DOM
Hi Dimitri, Thanks for writing up that page. I think it's valuable to have some documentation like this since the discussion has been scatters across many threads and a long time span. Another point of contention appears to be how show isolation is done particularly in the world where we've separated style isolation from event retargeting. I also think it would be valuable if you (or someone else) could add the description for which use case and scenario each feature is needed or used. That way, we can make an informed assessment of whether a new unicorn people come up withstands all the requirements the original unicorn satisfied, and if not, whether the trade off is acceptable or not. - R. Niwa On Feb 6, 2015, at 3:25 PM, Dimitri Glazkov dglaz...@google.com wrote: Folks, I wrote a long email, replying to each point where I agreed/differed with Ryosuke, and then deleted it, realizing I wasn't being productive. So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits We are at a point where there are hard choices to be made. But with the 4+ history of the adventure, it's nearly impossible for everyone to recall or catch up on discussions and relevant insight. With this doc, I am hoping we'll get on the same page and make way. :DG
[webcomponents]: Let's reach consensus on Shadow DOM
Folks, I wrote a long email, replying to each point where I agreed/differed with Ryosuke, and then deleted it, realizing I wasn't being productive. So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits We are at a point where there are hard choices to be made. But with the 4+ history of the adventure, it's nearly impossible for everyone to recall or catch up on discussions and relevant insight. With this doc, I am hoping we'll get on the same page and make way. :DG
