- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Mon, 29 Apr 2013 15:00:23 -0700
- To: "Edward O'Connor" <eoconnor@apple.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Hi Ted! Thanks for the kudos. We Shadow DOM elves are hard at work on making the world a better place :) I think you're raising good questions. I am sensitive of the fact that you are just starting the journey into the shadows and volunteer to be your Aragorn. Yes, Shadow DOM is fairly complex, but it is also the minimal set of machinery that is actually useful. We elves had gone through the extensive process of making sure of that. If we take away multiple insertion points, we significantly reduce authors' ability to build useful controls. For example, the control that uses insertion points in WebKit now is the <details> element, which needs two. So would a properly implemented <fieldset> (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees). If you're planning to build an accordion, you need more than one insertion point (https://github.com/dglazkov/Web-Components-Polyfill/blob/master/samples/accordion/accordion-component.html). Same for even the simplest tab view control, let alone the one that manages tab overflow (https://github.com/dglazkov/Web-Components-Polyfill/blob/master/samples/tabs/tabs-component.html) As Scott pointed out in his succinct reply, removing multiple insertion points does not eliminate the need for reprojection. In our elvish experience, it took literally seconds for control authors to write this code: <button is="my-funky-button"> <content></content> </button> At which point, the lack of reprojection bites the author in the rear soft tissue. As far as implementation complexity, <content select>, distribution APIs, and <shadow> are trivial, compared to the event handling and representation of the composed tree. Hoping to alleviate this, I wrote all event-related handling as imperatively as I could. One thing where we could definitely help the implementers is in uncondensing the spec. I think today's spec, though technically correct, is way too dense and is in need of good refactoring. I am planning to tackle this very soon and would appreciate any contributions. Thanks again! :DG<
Received on Monday, 29 April 2013 22:00:51 UTC