889230 - (custom-elements-initial-release) [meta] Implement Custom Elements (from Web Components)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Michael[tm] Smith [:sideshowbarker]]

Implement the Custom Elements spec:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

The spec has already been published as a W3C First Public Working Draft and Blink/Chromium has an implementation in progress:
https://code.google.com/p/chromium/issues/detail?id=234509

Custom Elements are a part of the overall Web Components feature/mechanism. High-level explanation here:

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#custom-element-section

Markup example for a simple case:

<element extends="button" name="fancy-button">  <!-- definition -->
    …
</element>

<button is="fancy-button">  <!-- use -->
    Do something fancy
</button>

Comment 1

[Michael[tm] Smith [:sideshowbarker]]

Note that the declarative markup mechanism for creating custom elements (using the HTML <element> element) has been dropped from the Custom Elements spec:

https://dvcs.w3.org/hg/webcomponents/diff/2adb12001a1a/spec/custom/index.html
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

But the rest of the spec remains the same; there's still an imperative script-based mechanism for creating custom elements.

For background, see http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0287.html

Comment 2

[Pomax]

giving this a small bump, since at the time of writing this comment Chrome Canary actually has native support for CustomElements and ShadowDOM, and turned on by default.

Comment 3

[Pomax]

additional bump; CustomElements is now landing in the Chrome beta channel, with ShadowDOM landing in the release channel.

Comment 4

[Potch [:potch]]

Do we have implementors lined up for this bug? Would be good to know who to talk to about the ongoing work.

Comment 5

[(no longer active)]

(In reply to comment #4)
> Do we have implementors lined up for this bug? Would be good to know who to
> talk to about the ongoing work.

Please check with wchen.

Comment 6

[Potch [:potch]]

Custom Elements seems to be implemented and working behind the dom.webcomponents.enabled flag. Is there more work to be done, or is this bug being open an oversight?

Comment 7

[Pomax]

needinfoing as per Ehsan's bugzilla name instruction =)

Comment 8

[(no longer active)]

(In reply to Mike "Pomax" Kamermans [:pomax] from comment #7)
> needinfoing as per Ehsan's bugzilla name instruction =)

See comment 5.

Comment 9

[William Chen [:wchen]]

We have an implementation of custom elements in the tree but it is pref'ed by dom.webcomponents.enabled and disabled by default. It is not being shipped because we are not confident in the current specification, we offer it as an experimental API to collect feedback from developers.

Comment 10

[Luis Garcia]

Bug: document.registerElement returns class without 'prototype' property.

var A = document.registerElement('custom-element')
A.prototype === undefined

Firefox 35.0a1

Comment 11

[Anne (:annevk)]

FYI, the description in comment 0 is no longer accurate. The feature we want to implement is defined across DOM https://dom.spec.whatwg.org/ and HTML https://html.spec.whatwg.org/multipage/ these days. The following wiki pages have pointers to the relevant sections:

* https://github.com/whatwg/dom/wiki
* https://github.com/whatwg/html/wiki

Comment 12

[ExE Boss]

(In reply to Olli Pettay [:smaug] (high review load) from bug 1205323 comment #33)
> I'm marking this fixed, since this was really a tracking bug for shipping.
> Bug 1438607 is new things and tracking for regressions and such.
> Perhaps bug titles should be changed a bit.