Like Mozilla and Apple [1] [2], I would also like to briefly lay out my viewpoint on Web Components in advance of the face-to-face meeting.
I love the work that has been done thus far on the web components specs, and while Microsoft has not yet begun development of these features [3] I know they support the use cases and are excited to see the success that early implementations have had. As has been said, I also feel that there are some rough edges among the present set of web components specifications. I also believe that some important additional features are necessary to complete the web components usage and development experience for web developers. Finally, I'm also a fan of simplification where appropriate, both in terms of helping facilitate quicker interoperability, as well as making an implementations easier :-) I make reference to some proposals below (special thanks to Arron Eichols for helping me navigate the weird waters of CSS). I want to emphasize that these are primarily Arron and I's own work and should not be considered an official Microsoft proposal. The following views are organized by spec. They cover the breadth of web component features. At the face-to-face meeting, our shared goal is to primarily resolve issues in Shadow DOM--the rest of this viewpoint is provided for reference and in case the scope of the meeting is expanded ;-) --Shadow DOM------------------------------- Open vs. closed * I think that both types of shadow doms should be available in the platform, but believe that developers asking for a closed shadow dom often want more strict encapsulation [4] than simply closing off access to the shadowRoot. I'm not sure whether it makes sense to have 1) a "simple" closed shadow root as well as 2) a fully encapsulated closed shadow root in the platform. Similar to Apple's "isolated imports" and Mozilla's "isolated Shadow DOM" ideas, I'd like to propose "isolated custom elements" [5], but think such a feature is additive and doesn't need to block progress of any of the existing specs. Generational Shadow DOMs * I support Apple's proposal to simplify this concept in favor of some form of named slots. Imperative Distribution API * I'm in favor of pursing this, but don't feel it needs to block progress. Event Retargeting * I believe that for open Shadow DOM's this isn't necessary. I think some form of event retargeting is necessary for a closed component. Declarative Syntax * I support Mozilla's idea for a straightforward Shadow DOM declarative syntax to help with serialization and parsing scenarios. We don't think this blocks progress on the current spec. --Custom Elements------------------------------------ Construction * I support synchronous or the "almost-synchronous" construction options for their simplicity and rationality. Inheritance * I don't object to inheritance from any arbitrary element--though I've heard that many developers expect to inherit _behavior_ and element _semantics_ (e.g., Accessibility behaviors) as well, and that this might lead to failed expectations. --Styling/CSS------------------------------------------- Default Styles * Both Microsoft internal and external customers have told me they need the ability to style components (not necessarily just those that might have a Shadow DOM) with "default" styles that can be overridden by author styles. I offer a proposal to support this [6]. Shadow Piercing * I believe that the correct platform technique for achieving style isolation is through Shadow DOM, and that it might be necessary to have the shadow piercing combinator. I'm interested in exploring other ideas that may obviate the need for the combinator. *If* the shadow piercing combinator is retained as currently defined, then it should be tempered with the ability for component authors to control which styles it can affect. Such a feature might look like a new general technique for styling control [7] which limits the capability of the shadow dom piercing combinator. The proposal could also be used to open up styling control to iframes using the combinator in order to help fix the current iframe[seamless] situation. --Template---------------------------------------------- Databinding * I think it is still premature to standardize any particular data-binding syntax on top of the template element. There is a thriving set of existing JavaScript-based data-binding libraries and there doesn't appear to be a particular dominant technique. --HTML Imports---------------------------------------- link[rel=import] * I would like to focus our efforts on developing and understanding the ES6 module loader before pursuing an implementation of this spec. -Travis [1] http://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html [2] http://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0225.html [3] https://status.modern.ie/?term=web%20components [4] http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button [5] https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal [6] https://github.com/w3c/webcomponents/wiki/Default-Stylesheets:-Concept-and-Proposal [7] https://github.com/w3c/webcomponents/wiki/Limiting-the-superpowers-of-the-%22Shadow-DOM-piercing-cominator%22
