Re: [webcomponents] Decoupling Custom Elements and Shadow DOM (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa  wrote:

> On Dec 5, 2013, at 7:32 PM, Scott Miles  wrote:
> > >> We don't think decoupling custom elements and shadow DOM completely
> is useful given that most important and natural use cases of custom
> elements involve the use of shadow DOM.
> >
> > Separating concerns is always useful, especially when it involves
> contentious standards.
> >
> > I also would like to point out that Mozilla's X-Tags/Brick custom
> elements library is built entirely without Shadow DOM.
>
> Could you elaborate on what value does document.register add in that
> world?  Web developers could use mutation observers to manipulate elements
> of a given name and add a bunch of properties already.


Custom Elements adds a lot of value over Mutation Observers. Mutation
Observers are great, but for other things. A couple of the benefits are:

Instances get callbacks/the right prototype more eagerly than they do with
Mutation Observers. If element authors follow local discipline, they end up
with a composition of elements that is consistent. This makes it easier to
create more robust applications. Technically, more eager callbacks (more
eager than typical uses of Mutation Observers, but less eager than Custom
Elements) are possible with Mutation Observers through takeRecords. However
it turns out this is infeasible because developers end up cargo-culting
takeRecords. (It doesn't work? Add a call to the thing that flushes changes
with takeRecords! Something else broke? ...)

It is easier to get consistent availability of the element than it is with
Mutation Observers. For example, Custom Elements are upgraded even if the
element instance is not in the document. With Mutation Observers this is
extremely difficult because it requires registering observers as subtrees
are disconnected... and modifications including disconnections may have
happened in the interim. With Custom Elements, the responsibility of
understanding how operations affect elements lies with the UA, which has
comprehensive knowledge of this now and into the future, and not with the
author.


> > >> creating shadow DOM when an optional parameter is specified will give
> us a way to constrain the scope of shadow DOM
> >
> > As Dimitri mentioned, we very much wanted to use this approach
> ourselves, but we determined it was naive given: (1) the complexities it
> introduces for inheritance and (2) the flexibility end-users required for
> manipulating templates and shadow roots.
>
> We get that and we're not objecting to giving that ability to expert
> developers but why should average web developers pay the price?
> i.e. Why should they be forced to use libraries and frameworks to do the
> simplest thing in the world?
>
> We're also not convinced that attaching a shadow DOM to a builtin element
> is a valid use case.  All use cases that of binding a shadow DOM to a
> builtin element that are remotely useful involves decorator; i.e. binding
> via style resolution.
>
> Replacing the appearance of form controls with shadow DOM isn't going to
> give us any accessibility benefit or forward compatibility because UA can't
> tell whether the attached shadow DOM targets a specific platform/device or
> not.  Using a subclass of HTMLInputElement is even worse because UAs can't
> hide the author-defined shadow DOM and the subclass could be overriding or
> exposing more APIs on the element so UAs can't even decide not to
> instantiate the custom element and use the regular input element.
>
> Given that, we have a hard time understanding why we ought to be blocking
> ourselves to provide a useful mechanism to scope id and CSS selectors and
> provide a "soft" encapsulation.
>
> - R. Niwa
>
>
>


-- 
Email SLA  •
Google+

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa  wrote:

>
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney  wrote:
>
> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa  wrote:
>
>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita  wrote:
>> > On inheritance around HTMLElement family, there seems to be a confusion
>> between interface side inheritance and implementation side inheritance.
>>
>> Right.  Differentiating the two is very important.
>>
>> > For Custom Elements, the inheritance is not only about interface, but
>> also about implementation. The implementation is more complex and flux in
>> detail, thus worth being shared between different elements. Actually, the
>> implementation of built-in HTML elements, which are usually done in C++,
>> uses inheritance heavily, at least Blink and (I believe) WebKit.
>>
>> The reason we can use inheritance heavily is because we have control over
>> both parent and child classes, and there are careful distinctions between
>> public, protected, and private member functions and member variables in
>> those classes.
>>
>> Unfortunately, custom elements can't easily inherit from these builtin
>> HTML elements because builtin elements do not provide "protected"
>> functions, and they don't expose necessary hooks to override internal
>> member functions to modify behaviors.
>>
>
> Built-in HTML elements have lots of hooks to modify their behaviour (for
> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
> Java class which has private and public final members, but no protected or
> public non-final ones.
>
> If someone were to make proposals about adding more hooks to the web
> platform to enable more subtyping use cases (for example, a protocol for
> participating in form submission) I would look forward to working with them
> on those proposals.
>
>
> 
>
> The problem here is that until such hooks are well defined, inheriting
> from builtin elements doesn't make any sense. So let's not support that
> until such proposal is made and implemented.
>

You assert that inheriting from built-in elements does not make any sense.
You seem to base this on the claim that hooks (the example being form
submission protocol hooks) are not well defined. Whether hooks are well
defined or not doesn't sufficiently support your assertion, because:

1. Not all subtyping relies on hooks. For example, subtyping a built-in
element can add additional API to it. This may make sense. For example, a
social network "endorse" button has a number of additional properties. Yet
it is (or could be) a button.

2. The premise that hooks are not defined is also incorrect. Many hooks are
already defined. Here is one example: the INPUT element has input and
change events and a value property. These are sufficient to observe, filter
and change the value of the INPUT element.

In mentioning hooks, was merely observing that we could define more hooks
to enable even more use cases.


> In addition, consider how inheriting "views" work in AppKit, UIKit, .net
> and MFC. When a view T inherits from another view S, T doesn't simply put S
> into a subregion of T; S intrudes into T's view and modifies what's been
> displayed or places extra content after or before T draws itself.
>

I can not discern a specific point you are making here. You are drawing an
analogy to various UI frameworks but you have not completed the analogy. I
think if you completed the analogy it would end up being a claim about
Shadow DOM. You may have confused extending an element and having Shadow
DOM. As Rafael Weinstein points out here: <
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0883.html>,
whether an element has Shadow DOM is orthogonal to whether it is a Custom
Element or not. I also disagree with your implied argument about Shadow DOM.


> I have a hard time understanding how this bizarre mixture of inheritance
> and composition is considered as the minimal subset of features while
> adding one optional argument to document.register to eliminate the most
> common boilerplate is considered as "building a framework" and "bundling"
> orthogonal features. Where did use cases and developer ergonomics go?
>

The use cases were discussed on this list in 2010.

As for ergonomics, this is subjective, but I spent a day last week building
a Polymer app and the ergonomics were splendid. I have played with X-Tags
in the past and they're great too.

Dominic

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Daniel Freedman]

I've been thinking through the implications of this "auto shadow" proposal,
and I'm glad people are seeing the utility of , but I don't think
this feature would see much use.

Developers want data-binding, and the auto cloning  does not give
them a favorable timing model.
They want to set those up before the ShadowDOM is stamped, on a
per-instance level.
If they were to use the automatic template, it would be far too late, and
there could be unnecessary network requests or FOUC.

To remove a bit of vaguness from this scenario, Polymer elements use
data-binding in almost all cases.
Event handlers, computed properties, MVC, everywhere.
As such, no Polymer element would use the automatic  registration
argument.
I doubt that elements created with other libraries like Ember or Angular
would make much use of it either.

However, if some low level data-binding primitives were introduced to the
platform, there would be some real merit in an automatic template argument.
There would have to be some modifications to the proposal, such as adding
hooks for data-binding information to be given to the template instance,
but I think those details can be discussed when such a data-binding spec
arrives.

Until data-binding primitives arise, I think this automatic template is a
premature discussion.


On Sat, Dec 7, 2013 at 8:33 PM, Rafael Weinstein  wrote:

> On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa  wrote:
>
>>
>> > On Dec 7, 2013, at 3:53 PM, Rafael Weinstein 
>> wrote:
>> >
>> > The issue is that being an element and having shadow DOM -- or any
>> display DOM, for that matter -- are orthogonal concerns.
>> >
>> > There are lots of c++ HTML elements that have no display DOM. Polymer
>> already has an even larger number.
>>
>> While that's true in browser implementations, there is very little
>> authors can do with a plain element without any shadow content it since
>> JavaScript can't implement it's own style model (i.e. creating a custom
>> frame object in Gecko / render object in WebKit/Blink) or paint code in
>> JavaScript.
>>
>> If the only customization author has to do is adding some CSS, then we
>> don't need custom element hook at all.
>>
>>
> I'm was thinking about elements whose purpose isn't presentational. For
> example,  or 

RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[François REMY]

± > If someone were to make proposals about adding more hooks to the web
± platform to enable more subtyping use cases (for example, a protocol for
± participating in form submission) I would look forward to working with them
± on those proposals.
± 
± I am very interested  in such proposals and I think others are as well. We run
± into the usual time-budget issues, but if we can find someone who is willing
± to champion a particular cause (like form submission) I would be very willing
± to help that champion work through designs and shepherd them through the
± process.
± 
± CC'ing public-nextweb as this is the sort of stuff we love over there.

There's definitely something we should do about that. That being said, things 
have to be prioritized and I'm not sure overloading the FORM tag's behavior is 
absolutely necessary right now. Indeed, inheritage can always be emulated in 
ECMAScript using some Object.setPrototypeOf(...) magic and composition. 

It is very likely that [[ creating some "x-form" element ]] + [[ adding some 
real form element into its shadow dom ]] + [[ forwarding all events/method 
calls back & forth from the shadow to the main dom tree ]] + [[ hooking 
onsubmit to perform some pre-submit processing, to map non-input elements in 
the main tree into real input elements in the shadow tree ]] would to the trick 
to cover a large majority of the use cases. 

This is somewhat cumbersome but that would work, and doesn't seem to be an 
unsurmountable amount of work. Meanwhile, there are other problems in the 
platform that still lack any proper solution.

That being said, I'm open to review any proposal in that space, it is great to 
see the discussion rolling! My two cents would be that we could add some 
@@InputElement symbol that, when present on a tag, make it participate to the 
form submission process (aka, we use its "name" and "value" properties to add 
it to the request body).

Best regards,
François

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Ryosuke Niwa]

> On Dec 7, 2013, at 4:38 PM, Dominic Cooney  wrote:
> 
>> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa  wrote:
>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita  wrote:
>> > On inheritance around HTMLElement family, there seems to be a confusion 
>> > between interface side inheritance and implementation side inheritance.
>> 
>> Right.  Differentiating the two is very important.
>> 
>> > For Custom Elements, the inheritance is not only about interface, but also 
>> > about implementation. The implementation is more complex and flux in 
>> > detail, thus worth being shared between different elements. Actually, the 
>> > implementation of built-in HTML elements, which are usually done in C++, 
>> > uses inheritance heavily, at least Blink and (I believe) WebKit.
>> 
>> The reason we can use inheritance heavily is because we have control over 
>> both parent and child classes, and there are careful distinctions between 
>> public, protected, and private member functions and member variables in 
>> those classes.
>> 
>> Unfortunately, custom elements can't easily inherit from these builtin HTML 
>> elements because builtin elements do not provide "protected" functions, and 
>> they don't expose necessary hooks to override internal member functions to 
>> modify behaviors.
> 
> Built-in HTML elements have lots of hooks to modify their behaviour (for 
> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a 
> Java class which has private and public final members, but no protected or 
> public non-final ones.
> 
> If someone were to make proposals about adding more hooks to the web platform 
> to enable more subtyping use cases (for example, a protocol for participating 
> in form submission) I would look forward to working with them on those 
> proposals.

The problem here is that until such hooks are well defined, inheriting from 
builtin elements doesn't make any sense. So let's not support that until such 
proposal is made and implemented.

In addition, consider how inheriting "views" work in AppKit, UIKit, .net and 
MFC. When a view T inherits from another view S, T doesn't simply put S into a 
subregion of T; S intrudes into T's view and modifies what's been displayed or 
places extra content after or before T draws itself.


I have a hard time understanding how this bizarre mixture of inheritance and 
composition is considered as the minimal subset of features while adding one 
optional argument to document.register to eliminate the most common boilerplate 
is considered as "building a framework" and "bundling" orthogonal features. 
Where did use cases and developer ergonomics go?

- R. Niwa