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------------------------------------

* I support synchronous or the "almost-synchronous" construction options for 
their simplicity and rationality.

* 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 


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.


* 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----------------------------------------

* I would like to focus our efforts on developing and understanding the ES6 
module loader before pursuing an implementation of this spec.



Reply via email to