Defining custom element subclasses that can fill in base class insertion points

[Jan Miksovsky]

In porting a component framework to custom elements, I've hit a significant hurdle in creating a custom element that can both derive from, and populate the visual presentation of, a base element. Because the problem description got more involved than can comfortably fit in a discussion board post, I've written a blog post on the problem: http://blog.quickui.org/2013/06/11/puzzle-define-html-custom-element-subclasses-that-can-fill-in-base-class-insertion-points/.

Any thoughts or suggestions from this community would be much appreciated!

[Steve Orvell]

Thanks for writing such a detailed and thoughtful post.

In Polymer, we tend to use composition when simple inheritance doesn't fit the bill. This gives us the flexibility we need, but it does have some of the costs you noted: facading, failing instance of test. We're also considering supporting a mixin mechanism to propagate common behavior and avoid facading.

It may be valuable to separate in this discussion Custom Elements (behavior) from ShadowDOM (presentation). Each has its own mechanism for inheritance.

Inheritance in Custom Elements is about as simple as it gets. This is partially because it matches well with prototypal inheritance and ES6 classes and also because more complex behavior can be sugared around it.

Inheritance in ShadowDOM is quite a bit more complex. It's very likely that the ShadowDOM spec needs to evolve here. Specifically, we've argued that nodes placed inside <shadow> should be distributed. This would perhaps partially address one of the concerns in your post.

I realize the example you chose to highlight is simple on purpose, but I'd still like to point out that in this case, it's plain-button's button-y behavior and button-y decoration that should be inherited by icon-button. Depending on complexity, the button decoration could be done as @host styling, or it could be a separate custom element used by both plain-button and icon-button. Again depending on complexity, the button-y behavior could be inherited or could be mixed in.

This is a complicated topic and more feedback is very welcome. If we can work towards crystalizing some features the platform should support, the Polymer team will be happy to help push for them.

On Tue, Jun 11, 2013 at 8:36 AM, Jan Miksovsky <j...@quickui.org> wrote:

In porting a component framework to custom elements, I've hit a significant hurdle in creating a custom element that can both derive from, and populate the visual presentation of, a base element. Because the problem description got more involved than can comfortably fit in a discussion board post, I've written a blog post on the problem: http://blog.quickui.org/2013/06/11/puzzle-define-html-custom-element-subclasses-that-can-fill-in-base-class-insertion-points/.

Any thoughts or suggestions from this community would be much appreciated!

--
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dominic Cooney]

On Wed, Jun 12, 2013 at 2:29 AM, Steve Orvell <sor...@google.com> wrote:

Thanks for writing such a detailed and thoughtful post.

In Polymer, we tend to use composition when simple inheritance doesn't fit the bill. This gives us the flexibility we need, but it does have some of the costs you noted: facading, failing instance of test. We're also considering supporting a mixin mechanism to propagate common behavior and avoid facading.

It may be valuable to separate in this discussion Custom Elements (behavior) from ShadowDOM (presentation). Each has its own mechanism for inheritance.

Inheritance in Custom Elements is about as simple as it gets. This is partially because it matches well with prototypal inheritance and ES6 classes and also because more complex behavior can be sugared around it.

Inheritance in ShadowDOM is quite a bit more complex. It's very likely that the ShadowDOM spec needs to evolve here. Specifically, we've argued that nodes placed inside <shadow> should be distributed. This would perhaps partially address one of the concerns in your post.

Where's the discussion for evolving the Shadow DOM spec happening? I would like to follow it.

 

I realize the example you chose to highlight is simple on purpose, but I'd still like to point out that in this case, it's plain-button's button-y behavior and button-y decoration that should be inherited by icon-button. Depending on complexity, the button decoration could be done as @host styling, or it could be a separate custom element used by both plain-button and icon-button. Again depending on complexity, the button-y behavior could be inherited or could be mixed in.

This is a complicated topic and more feedback is very welcome. If we can work towards crystalizing some features the platform should support, the Polymer team will be happy to help push for them.

On Tue, Jun 11, 2013 at 8:36 AM, Jan Miksovsky <j...@quickui.org> wrote:

In porting a component framework to custom elements, I've hit a significant hurdle in creating a custom element that can both derive from, and populate the visual presentation of, a base element. Because the problem description got more involved than can comfortably fit in a discussion board post, I've written a blog post on the problem: http://blog.quickui.org/2013/06/11/puzzle-define-html-custom-element-subclasses-that-can-fill-in-base-class-insertion-points/.

Any thoughts or suggestions from this community would be much appreciated!

--
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Scott Miles]

I would really like to be able to reproject into <shadow>, like this:

  <shadow>

    [static content]

    <content></content>

  </shadow>

and we have been trying to gently suggest this, as Steve mentioned.

But, fwiw it is possible to manipulate shadow roots manually for all kinds of effects. I'm not suggesting this makes your arguments go away, I just want to point out the option.

http://jsbin.com/agokak/2/edit

(or the hardcore version, if you like: http://jsbin.com/agokak/3/edit)

[Jan Miksovsky]

+1 on being able to reproject into <shadow>!

As far as I can tell, that would precisely solve the need which the blog post lays out. Steve: You say this "would perhaps partially address one of the concerns in your post", but it seems to strike at the core of the issue.

I will say that I'd hoped to be able to use <shadow> to fill in a base class (i.e., an older shadow), and was disappointed when I couldn't. It looks like at least one other Polymer user (https://groups.google.com/forum/#!searchin/polymer-dev/<shadow>/polymer-dev/VjK_hTdlYNE/u1_UsMauzfUJ) expected to be able to do the same thing. While it's not a big data set, I just think it's interesting that that specific use of <shadow> is so natural, custom element authors are coming up with it on their own — even though it's not spec'ed anywhere and doesn't actually work! That suggests that delivering such a feature would probably be an extremely natural extension of the current model.

"We've been trying to gently suggest this." Perhaps stronger measures are called for. Do we need to bribe someone with their favorite dessert? (Dimitri: Do you like chocolate cake?) :)

Perhaps data would help make the case. I've amended my original blog post (http://blog.quickui.org/2013/06/11/puzzle-define-html-custom-element-subclasses-that-can-fill-in-base-class-insertion-points/#comment-63) with a quick analysis of the extent to which a sample set of real QuickUI applications rely upon such a base class-filling feature. Real component-based apps need this!

I think the Polymer team could do some analysis of their own along these lines. I did a quick look through toolkit-ui/elements, searching for cases in which one custom element extends another custom element, and where the templates for *both* contribute their own visible elements (not just <style>, <content>, or <shadow>). Of the 40 or so elements in that repo, I can't find a single pair of custom elements working together like that. Either the base element defines all the interesting stuff, or the subclass (extending) element does. The g-ribbon / g-selector pair seems to come the closest, but I'm not really familiar with it. It looks like g-ribbon adds a label, and g-selector doesn't actually add any visible elements of its own. As I said, I'm not really familiar with that library of elements, so I'm the wrong person to do such an analysis. But, for sake of discussion, let's stipulate I'm right, and that essentially none of the elements in this library have a class relationship where both base class and subclass contribute elements the user can actually see. One interoperation of such a result is that such a feature is unnecessary in a general purpose UI component library. Alternatively, given the QuickUI counter-examples, it could suggest that the current spec is effectively limiting what the Polymer library can deliver.

Along those lines: I think that having <shadow> distribute its content would be much more useful that the spec'ed behavior of having <shadow> content define default content. I haven't come across a case where non-empty default shadow content would be compelling. If an element ask for <shadow></shadow> and there's no older shadow, it seems to me that showing nothing is a pretty good answer. I don't see a case in toolkit-ui where a <shadow></shadow> instance uses the opportunity to define default content to be used if there's no older shadow.

It sounds like perhaps I'm preaching to the choir. All I'm trying to add to the discussion here is that some degree of hard data from comparable component class libraries might help carry the argument.

[Scott Miles]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22344

These bugs are open for public comment if you want to add some encouragement there.

[Dominic Cooney]

On Thu, Jun 13, 2013 at 4:55 AM, Scott Miles <sjm...@google.com> wrote:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22344

These bugs are open for public comment if you want to add some encouragement there.

This is the first time I've seen this idea. I played around with it today. I think it is a fantastic idea.

--

[Jan Miksovsky]

Scott/Dominic: Thanks! I've added a comment to the bug in support of this idea.

Also, thanks for the suggestion of working around the current limitations by mucking directly around in the shadow subtrees. That gave me an idea for how I could prototype the ability to reproject content into <shadow>. I've posted an example at http://jsbin.com/eturil/2/edit. The sample shows a <icon-button> that can (appear to) reproject content into a <shadow> element. It's sort of a polyfill for this feature proposal.

The comments provide some more detail on the Shadow DOM transformation involved. This supports multiple shadow subtrees. I haven't tried this yet, but this should allow me to write a Quetzal element class that can subclass any element class (including a Polymer element), filling in insertion points in the latter. This isn't a great permanent solution, but might be good enough to unblock my component porting project.

[Dimitri Glazkov]

Commented on bug.

You guys keep stirring up trouble :P

:DG<

[cletusw]

Is it just me, or is this feature no longer working? I've tried this jsbin: (http://jsbin.com/UduXadA/1/edit) in Chrome 33.0.1750.22 dev on Linux and Chrome 34.0.1809.0 canary on Windows with the "Enable experimental Web Platform features" flag on and off and it isn't working for me.

Clayton

[Steve Orvell]

Unfortunately, this feature was removed due to implementation concerns.

It's still planned but it won't be included in the initial version of ShadowDOM in Chrome.

The polymer team considers this functionality very important and will be pushing for it asap.

[Clayton Watts]

Thanks for letting me know. Can this somehow be noted on the chromium bug? https://code.google.com/p/chromium/issues/detail?id=263701

Clayton

2014-01-28 Steve Orvell <sor...@google.com>

[Andrew Brogdon]

Pardon me for showing up seven months late to the party, but does anyone know if this issue has taken up again by the Chromium team?  I'm trying to build a polymer element that will provide a container for a set of elements that extend it, and found this post while hunting around.  Is the current best practice for wrapping subclass template DOM still to modify the superclass's Shadow DOM manually?

-Andrew

[anthonyt...@gmail.com]

Just wanted to chime in and say that I also ran into this issue independently. Any word from the Chromium team? 

On Tuesday, June 11, 2013 8:36:58 AM UTC-7, Jan Miksovsky wrote:

[jonathan...@gmail.com]

Also bumping this thread. Ran into this problem after only a day of serious Polymer development. Spent another half-day thinking about workarounds for our use case but came up short.

[mark.h...@btinternet.com]

Yes, I would love this feature to return. Not having it is probably the single most annoying thing with using Polymer for me.

I started designing an extensible set of UI components in the brief period when the feature was available and it was great! However, shortly afterwards it was removed and I had to instead use containment, which for a lot of situations is not nearly so neat. It seems completely logical to me to be able to inherit the basic look/layout of a component when creating another component that extends from it. 

I'm not entirely sure why the feature was removed as it worked well. I think I read somewhere that other browsers were having trouble implementing it, but if Chrome managed it, I can't see why they couldn't.

Here's hoping there's some news of it's return soon!

Mark

[Jan Miksovsky]

For those still interested in subclassing elements, I've posted a possible solution for web component subclasses. I'd prefer a native, standard solution to this problem, but until that becomes possible, perhaps this can make do.