WIP: Initial work for Custom Elements support #1872

tbranyen · 2017-05-29T02:40:51Z

Changes here paired with jsdom/webidl2js#44 will
enable ./test-web-components.js to work. You will need to npm install before running node ./test-web-components.js.

Changes here paired with jsdom/webidl2js#44 will enable `./test-web-components.js` to work. You will need to `npm install` before running `node ./test-web-components.js`.

domenic · 2017-05-29T11:27:17Z

Please be sure to follow the HTML and DOM Standards when making these changes. For example they do not look up properties on the instance, but instead store them at definition time. And CustomElementsRegistry needs to be defined with Web IDL, not inline in the Window constructor. Etc.

This is a big ambitious project, but it sounds like you're interested in sinking some time into it, so that's great! Just please follow the spec, and use official web platform tests, not ad-hoc ones.

tbranyen · 2017-05-29T15:59:19Z

Awesome @domenic. I'll work on spec-compliance and cleaning up my implementation. I wanted to at least make sure it was even do-able and what the path of integration might look like. So I didn't take into account standards or doing things the-right-way.

That said, I'm a bit stuck on how to get the associated defaultView from the HTMLElement constructor or document.createElement. Lets say you have code that looks like this:

customElements.define('hello-world', class extends HTMLElement {
  constructor() {
    this.innerHTML = `<b>Hello world</b>`;
  }
})

document.createElement('hello-world');

How can we make the HTMLElement-impl and Document-impl aware of where customElements are defined? Assuming I tie everything in with the IDL and let the generator scaffolding out the source, is there any clean way to reference the customElements registry from the output? I'm doing global.window currently which sucks since end users need to do that global.window = window.

I'll check the HTMLConstructor specification and see if it lends any clues as to how it finds the associated window.

tbranyen · 2017-05-29T16:03:22Z

Hrm:

Let registry be the current global object's CustomElementRegistry object.

Similarly, the current global object is the global object of the current Realm Record.

Before it is evaluated, all ECMAScript code must be associated with a realm. Conceptually, a realm consists of a set of intrinsic objects, an ECMAScript global environment, all of the ECMAScript code that is loaded within the scope of that global environment, and other associated state and resources.

Sounds like the vm.createContext(window) code, vm == realm?

Sebmaster · 2017-05-29T16:07:52Z

Sounds like the vm.createContext(window) code, vm == realm?

Sadly, that doesn't work in jsdom because we don't define HTMLElement in the VM context.

document.createElement is easy, since it goes through our own code. Anything where the on-page code can directly new up an interface directly, we have to cheat in some way. We mostly do it by wrapping the constructor. The code that implements Window contains a lot of these tricks. See the definition of Image and XMLHttpRequest for example.

snuggs · 2017-05-31T01:32:35Z

This is awesome @tbranyen

durandj · 2017-07-19T19:32:05Z

I don't suppose this PR is still active is it? I was really hoping to use this for testing my web components.

tbranyen · 2017-07-19T20:02:21Z

@durandj you should be able to use jsdom-wc (from npm) to test certain features. I will be taking another stab at this soon. Real life in the way ATM though.

majo44 · 2017-08-22T17:28:41Z

lib/jsdom/living/nodes/Document-impl.js

+    let Constructor = null;
+
+    if (Constructor = this._global.window.customElements.get(name)) {
+      return idlUtils.tryImplForWrapper(new Constructor());


@domenic
Hi, I trying to test similar implementation by web-platform-tests, and I have strange problem.
If I will run in node code like

import {JSDOM} from 'jsdom-wc'; const dom = new JSDOM(`<!DOCTYPE html>`); global.HTMLElement = dom.window.HTMLElement; global.window = dom.window; global.document = dom.window.document; class A extends HTMLElement { constructor() { super(); console.log('AAAA'); } } new A();

Everything works fine.
But if I want to run similar code from web-platform-tests I have a error:

TypeError: Illegal constructor at CustomElement.HTMLElement (...\jsdom\living\generated\HTMLElement.js:14:10) at ... at Object.<anonymous> (http://w3c-test.org/custom-elements/attribute-changed-callback.html:6:31)

I putted similar code to create-jsdom.js just before window.shimTest = () => { and I see similar result.
The 'window.HTMLElement' is a function from ...\jsdom\living\generated\HTMLElement.js so calling of new is throwing same exception.
In most of wpt there is no direct call of the elements constructors (instead of this document.creatElement is called) that why I think this is not occurs on other tests. But for custom-elements we have to call the constructor directly, and I do not know why on wpt this is no working. Any suggestion ?

@majo44 We do not support jsdom-wc.

@TimothyGu
Hi, I do not ask you support jsdom-wc. Forget about the previous question it was my mistake (this is expected behavior which fallow spec).

durandj · 2017-08-26T23:43:55Z

lib/jsdom/living/nodes/HTMLElement-impl.js

@@ -28,6 +29,20 @@ class HTMLElementImpl extends ElementImpl {
    });
  }

+  attachShadow(options) {
+    switch (options.mode) {


This appears to be missing the delegateFocus option that the spec allows for to allow focus changes through the shadow root.

caridy · 2017-10-03T22:00:36Z

@tbranyen do you have plans or time to continue pushing for this?

tbranyen · 2017-10-03T22:15:40Z

@caridy at this point not really, my implementation with jsdom-wc works pretty well and if others want to improve on that I'd be happy to push out releases on npm, but I don't have the time to go through the IDL/specification dance to get this implemented properly to land.

mraerino · 2017-10-25T10:51:29Z

I'd be willing to pick up on this.
@domenic do you recommend continuing the work done by @tbranyen or rather start from scratch?

caridy · 2017-10-25T15:53:29Z

@mraerino it seems that @TimothyGu and @domenic are in agreement on how to move forward based on #1030 (comment). We can also help once we have a clear direction on how to move forward. Can you work on a concrete plan?

TimothyGu · 2017-10-25T23:45:32Z

Work-in-progress that may be of interest:

https://github.com/TimothyGu/webidl2js/tree/bundle (webidl2js part is fully working)
https://github.com/TimothyGu/jsdom/tree/vm-hah (need to generate a browserify bundle manually; many places not working)

mraerino · 2017-10-26T12:37:31Z

Ok, so let's continue this in #1030
My current progress is in https://github.com/mraerino/jsdom/tree/custom-elements-spec

domenic · 2017-10-29T01:29:41Z

Let's close this and roll future work into #1030. Excited to see such progress!

tbranyen added 4 commits May 28, 2017 19:39

Initial work for Custom Elements support

f9b90d2

Changes here paired with jsdom/webidl2js#44 will enable `./test-web-components.js` to work. You will need to `npm install` before running `node ./test-web-components.js`.

Fix returned impl value & examples

29ec85f

Added connectedCallback and attributeChangedCallback

866d5f4

Added disconnectedCallback and initial shadow dom

7a0686c

lastmjs mentioned this pull request May 29, 2017

Support for WebComponents API #1030

Closed

treshugart mentioned this pull request May 31, 2017

support server side rendering Polymer/polymer#3955

Closed

This was referenced Jul 6, 2017

User Settings Being Overridden by <template> settings devpunks/snuggsi#87

Closed

<to-do> devpunks/snuggsi#85

Closed

majo44 reviewed Aug 22, 2017

View reviewed changes

durandj reviewed Aug 26, 2017

View reviewed changes

domenic closed this Oct 29, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: Initial work for Custom Elements support #1872

WIP: Initial work for Custom Elements support #1872

tbranyen commented May 29, 2017

domenic commented May 29, 2017 •

edited

Loading

tbranyen commented May 29, 2017 •

edited

Loading

tbranyen commented May 29, 2017

Sebmaster commented May 29, 2017

snuggs commented May 31, 2017

durandj commented Jul 19, 2017

tbranyen commented Jul 19, 2017

majo44 Aug 22, 2017

TimothyGu Aug 23, 2017

majo44 Aug 23, 2017

durandj Aug 26, 2017

caridy commented Oct 3, 2017

tbranyen commented Oct 3, 2017 •

edited

Loading

mraerino commented Oct 25, 2017

caridy commented Oct 25, 2017

TimothyGu commented Oct 25, 2017

mraerino commented Oct 26, 2017 •

edited

Loading

domenic commented Oct 29, 2017

WIP: Initial work for Custom Elements support #1872

WIP: Initial work for Custom Elements support #1872

Conversation

tbranyen commented May 29, 2017

domenic commented May 29, 2017 • edited Loading

tbranyen commented May 29, 2017 • edited Loading

tbranyen commented May 29, 2017

Sebmaster commented May 29, 2017

snuggs commented May 31, 2017

durandj commented Jul 19, 2017

tbranyen commented Jul 19, 2017

majo44 Aug 22, 2017

Choose a reason for hiding this comment

TimothyGu Aug 23, 2017

Choose a reason for hiding this comment

majo44 Aug 23, 2017

Choose a reason for hiding this comment

durandj Aug 26, 2017

Choose a reason for hiding this comment

caridy commented Oct 3, 2017

tbranyen commented Oct 3, 2017 • edited Loading

mraerino commented Oct 25, 2017

caridy commented Oct 25, 2017

TimothyGu commented Oct 25, 2017

mraerino commented Oct 26, 2017 • edited Loading

domenic commented Oct 29, 2017

domenic commented May 29, 2017 •

edited

Loading

tbranyen commented May 29, 2017 •

edited

Loading

tbranyen commented Oct 3, 2017 •

edited

Loading

mraerino commented Oct 26, 2017 •

edited

Loading