Element constructors need to "pass through" to HTMLElement when invoked as constructors |
||||||||
Issue description
There are a kind of custom element called "customized built-in elements." They are written like this:
<button is="my-button">
Definitions for these will want HTMLButtonElement on the prototype chain; authors will write something like this:
class MyButton extends HTMLButton {
constructor() {
super(); (*)
this._num_clicks = 0;
this.addEventListener('click', () => this._num_clicks++);
}
}
customElements.define('my-button', MyButton, {extends: 'button'});
We have to make new MyButton() work, which is calling HTMLButtonElement at point *.
For the spec side, see https://github.com/whatwg/html/pull/1404
If we made these constructors just call their superconstructor, I believe everything would work--the HTMLElement constructor already knows to throw errors when the constructor is invoked outside custom elements. But we should probably make this part of the bindings and not write manual constructors everywhere.
There are no custom constructors for subtypes of HTMLElement, which is good. However option, img and audio have constructors. We need to work out how the HTMLElement constructor should integrate with them. First rough idea: the HTMLElement constructor steps turn into a template method or something which delegates to the subtype to actually produce the element. We can make this work.
,
Aug 25 2016
,
Sep 19 2016
Will it also fix the issue with the ```<button is="my-button">``` syntax being ignored (in Chrome v55)?
,
Oct 12 2016
,
Oct 27 2016
yurak is implementing this, see <https://codereview.chromium.org/2424693002>. There's no pass-through, instead each interface gets its own constructor guided by the HTMLConstructor IDL attribute.
,
Oct 31 2016
yurak has implemented the machinery for this in https://crrev.com/e8d4a1b8a06a252894820686f1570f5943bb5947 Now it just needs to be applied to all of the relevant interfaces. Form-associated interfaces will need some care and attention because of the unusual way that they are constructed. Re: Comment 3, this is related to is-syntax but won't directly address that, no. Follow Issue 648828 .
,
Jan 20 2017
Anton is taking a look at this.
,
Jan 25 2017
,
May 18 2017
Hi guys, sorry for delay - was having family issues last few months. Will check the latest chromium today and start again now.
,
May 22 2017
Welcome back! I suggest you take a look at these TODOs: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp?q=html/parser+TODO+htmlconstruction+package:%5Echromium$&l=935 For example, the effect of the reset algorithm should be observable. You could add the HTMLConstructor attribute to HTMLInputElement, then write a failing test that indicates reset is not being called, then make that work in the right place and remove the TODO. Preferably making all of the code simpler in the process.
,
Jun 18 2017
Hi Dominic, thanks! I've got now some time allocated and started with https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp?q=html/parser+TODO+htmlconstruction+package:%5Echromium$&l=935. Will upload a patch this week.
,
Jun 18 2017
Sorry, meant to say next week (19/06 - 25/06) since it is still Sunday here.
,
Jun 25 2017
Hi guys, while making test for resettable elements I came across a problem with parsed custom built-in elements not being upgraded. I made a fix, plz check https://codereview.chromium.org/2954843002.
,
Jun 25 2017
Gerrit review: https://chromium-review.googlesource.com/c/547715/
,
Jun 25 2017
Hi Dominic, I've added a change with a test to invoke reset algorithm on built-in form control elements. Please have a look here: https://chromium-review.googlesource.com/547755. The problem is I couldn’t make the test fail since the value and checkedness are set to the right values already when the attributes are set for the created input element. May be with other resettable elements I can have better luck. Plz have a look if I am moving in the right direction.
,
Jun 25 2017
,
Jan 29 2018
My understanding of this issue: * "pass through" is not necessary any longer because we add [HTMLConstructor] to each of HTML element interfaces * As for resettable element, step 11 is necessary because a custom element constructor can change the element value. Are they right? |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by dominicc@chromium.org
, Jun 9 2016