Polymer: Type-extension polyfill for Polymer 2.0

[nazar-pc]

I'm very sad to see type-extension support being removed from Polymer.

<!-- good (`style` prefix or suffix), but not working for multiple reasons -->
<custom-style>...</custom-style>

<!-- bad -->
<style is="custom-style">...</style>

<!-- ugly -->
<custom-style>
 <style type="custom-style">...</style>
</custom-style>

Could Polymer team consider maintain (at least optional) support for type-extension?

Polymer have being pushing boundaries with Web Components in past, so having this feature in developer's toolkit might convince Webkit to implement it at some point too. Otherwise without having cross-browser support it might die eventually (which would be a small disaster).

[kevinpschaaf]

Per rationale under 3rd bullet here, Polymer-vended elements such as custom-style will not leverage type extensions until a potential point in the future when there is cross-browser consensus around the feature, to ensure _we_ are not making a choice that will force polyfill requirements on users indefinitely.

However, we do plan to bring support back to Polymer and the v1 polyfills in conjunction with Chrome shipping type extensions in v1 custom elements (the feature did not make the implementation cut for the first Chrome release with v1 custom elements, but support is still planned). This is so that users can still choose to create their own type-extension elements (but with the knowledge that they will be forcing polyfill requirements on their users).

[nazar-pc]

I've read all of the notes from 2.0-preview branch already (thanks for that, linked repository is private, but I see that it is what was merged into 2.0-preview branch), thanks for confirmation that the feature is indeed planned.
Should I close this issue or leave it for future reference?

[madeleineostoja]

Seems to be a discrepancy between this and the new 2.0 Preview docs on polymer-project.org (first line in Type-extension elements - _"Polymer 2.0 doesn't support type-extension elements"_). Are those docs incomplete/inaccurate, or this issue out of date?

Extending built-ins is crucial for us, and with recent movements by Mozilla and Edge to support it, and the ability to potentially ponyfill it with custom attributes, we're okay with the tradeoff and not having the support in Polymer would be a dealbreaker.

[arthurevans]

@seaneking Docs should say, "doesn't _currently_ support type-extension elements."

[nazar-pc]

The issue here is that some people have already built type-extension elements. And recalling 0.5->1.0 transition, it is scary that 1.0 development basically stopped already, but we will not be able to migrate to 2.0 without major pain to not only rebuild elements (which is fine and expected), but also all the places where they are already used.

I was expecting generic extension of custom elements in 1.0 and it didn't happen at all. So I'm personally really afraid that if 2.0 will be released without (even optional, but official) support for this feature it would make our life, as developers, very difficult again for indefinite amount of time (hopefully, not forever).

[TimvdLippe]

@nazar-pc on the Polymer summit the upgrade path to 2.0 has been explained. I would highly recommend you watch the talk if you havent already.

These custom type extensions are blocked per Apple not supporting them afaik. I think the plan is that the polymer upgrade tool will transform them automatically so upgrading should not be a big hassle.

[nazar-pc]

I've started watching videos, but anyways I'm well aware of Webkit position. I have no problems with updating elements themselves, but updating their usage is much bigger problem for me.

[madeleineostoja]

Is there an official roadmap/ETA for support (before v2 stable?) or is it more of a 'someday in the future' thing?

[sorvell]

We'll consider supporting is type extension in Polymer 2.x if/when browsers support this feature and/or the custom elements polyfill does.

If there is still interest in getting the polyfill to support this, please file the issue here: https://github.com/webcomponents/custom-elements.

[madeleineostoja]

@sorvell there's already an open PR on webcomponents/custom-elements for supporting customized builtins? https://github.com/webcomponents/custom-elements/pull/42

[bedeoverend]

I might be missing something here, but assuming the polyfill does accept that PR, as far as I can see, I could do the following with Polymer 2.0 as is:

class FancyButton extends Polymer.ElementMixin(HTMLButtonElement) {
  static get is() { return 'fancy-button' }
}

let fancyButton = document.createElement('button', { is: 'fancy-button' });

Thanks to the new mixin structure of 2.0 - is there much Polymer needs to do if / when the Polyfill supports it?

[nazar-pc]

I suspect styling wouldn't work in all cases, from JavaScript point of view it might actually work

[madeleineostoja]

@nazar-pc what would the issue because with styling? Don't the ShadyCSS and ShadyDOM v1 polyfills shim shadow roots and custom cars/mixins globally?

[nazar-pc]

@seaneking, I imagine there will be problems when using native Shadow DOM, since elements extended from native wouldn't have their own Shadow DOM (at least accessible to developers).

[bedeoverend]

@seaneking @nazar-pc I guess in scenarios where it extends from an element which doesn't support a Shadow Root e.g. img - if Polymer tries to create a Shadow Root as per usual, it would fail. Having said that, the _attachDom method that would throw that looks like it won't get called if the user doesn't have a template to be stamped into the root - which they shouldn't do anyway if they're extending an element which doesn't support a Shadow Root.

[madeleineostoja]

Yeah that's a more general issue with extending certainly built-ins, not really polymer or the polyfill's thing

[nazar-pc]

Just started converting type-extension elements used with Polymer 1.x to wrapper elements for Polymer 2.x. Compare following examples that do exactly the same thing:

<button is="cs-button" type="button" icon-before="home" primary>Home text</button>

<cs-button primary>
    <button type="button">
        <cs-icon icon="home"></cs-icon>
        Home text
    </button>
</cs-button>

Explicit? Maybe. Convenient? No way!

Hate Apple for forcing me to do this.

[kevinpschaaf]

To re-iterate our position here, we feel that the spec for is (type-extension elements) is at risk and could ultimately be abandoned if browser implementors never go through with an implementation, hence our reluctance to push forward with full-blown support for is. Please see https://github.com/w3c/webcomponents/issues/509 for the ongoing spec-level debate on the feature.

We totally understand and believe in the use cases for is, and are pushing for a follow-up with browser vendors to try and address the use cases left on the table by not implementing is.

We'll go ahead and re-open this issue to allow tracking status of this feature (or any alternatives that come up).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.