Regression #129

[kaste]

New version 1.12.2 broken for Custom Elements. Same CodePen I used for #129 but with updated hyperHTML package.

https://codepen.io/anon/pen/vWBwOx?editors=1010

(Sorry, no time for details. You probably know your way around anyway.)

[cary-smith]

Not sure if this is related, but the Temperature Calculator example also no longer functions in 1.12.2. I have not dug through the finer details yet but it looks like a null value is passed to the createPath function.

[WebReflection]

thanks for filing this. I've reverted general custom elements RegExp and kept only a-frame one around for now.

@cary-smith please confirm with latest everything is fine (also please link me the example you are looking at, thanks)

[WebReflection]

P.S. apologies a patch should never break, indeed it didn't in my tests. I am investigating what's going on with the change I've made since it should not affect working code at all.

[cary-smith]

@WebReflection - The example works as before. Thanks for fast response!

[WebReflection]

let's see how this goes: https://bugs.chromium.org/p/chromium/issues/detail?id=779165

[kaste]

I wonder how they solved this in Polymer 1 bc they used templates then. Aren't v0 element upgrades async?

[WebReflection]

AFAIK Polymer never used V0 while AFrame use my polyfill which brings V0 in every browser but Chrome because it ships V0. My poly with other browsers work, only native Chrome V0 has issues

[kaste]

Pretty sure I used it. Isn't this what you want? Maybe I'm confused.

    var proto = Object.create(HTMLElement.prototype)

    proto.createdCallback = function() {
      console.log('createdCallback')
    }
    proto.attachedCallback = function() {
      console.log('attachedCallback')
    }

    var XFoo = document.registerElement('x-foo', { prototype: proto })

    // create one via template
    var template = document.createElement('template')
    template.innerHTML = '<x-foo></x-foo>'

    // move the element to a live node
    document.body.append(document.importNode(template.content, true))

    assert.equal(document.body.lastElementChild.constructor, XFoo)

[WebReflection]

I might use importNode but it shouldn’t be needed in general

[kaste]

I think, actually you MUST use importNode. Try it. It's the 'right' thing for template elements. And you can remove the ugly regex.

[kaste]

It's actually specced as such :shrig: https://www.w3.org/TR/2016/WD-custom-elements-20160226/#creating-and-passing-registries

[WebReflection]

Custom Elements V1 work out of the box.

Like I’ve said , I’ll have a look.

Not now though, now I’m a bit busy.

[kaste]

T.i. when you do a redundant

template.ownerDocument.importNode(template.content, true)

you get no upgrades. So you actually have to import the nodes into the current document.

[kaste]

With V1 you register against the window, with v0 you register on document. Literally document.registerElement.

[WebReflection]

You register via customElements and its registry which is same used by V0 in Chrome (or they check each other).

Anyway , I will have a look.

Not today

[WebReflection]

Also, with your logic, I register on the document and with same document I create template and content so this looks just bad V0 behaviour . Point is, I don’t care . Whatever works best, really

[kaste]

It's a different document::

[WebReflection]

Live Custom Elements V0 tenst here: https://codepen.io/WebReflection/pen/xXMxEO

Anyway, this is still broken in various ways. I am still trying to figure out how to fix V0 only components which are the only problematic.

[WebReflection]

So, if I use importNode each time I have these pros:

• Custom Elements V0 will work once appended
• Custom Elements V1 will always be upgraded => constructor kicks in, etc ...

and these cons:

• Custom Elements V1 will trigger attributeChangedCallback ASAP with hyper values

To fix this, I need quite some huge refactoring which I believe is not worth in V1 or it will break your same Code Pen

V2 it is then, ugly hack for A-Frame elements only will stay.

Keeping this open until it's properly fixed in V2

[WebReflection]

closing this and will address the issue in V2