shadow DOM

[ghost]

How are you going to handle Shadow DOM?

[jails]

I don't think it would be a great pain to support it with a ShadowTag virtual node. So instead of patching nodes childrens directly ShadowTag will patch the children of the shadowRoot property if not null.

[ghost]

Upcoming ms Edge are going to support it to as it says in the draft. But both react and reactivejs are supportin some of its feature.

And other libs now starting to get issues with e.g. innerHTML property on shadow nodes.

To encapsulate rendering like this, I would guess you need to set it up so a virtual tree can't be reached by others. Imo mounting. Because it's a different dom tree. Maybe that was you ment?

Issues could be to figure out what is fragment and or shadow.

[jails]

This changes https://github.com/crysalead-js/dom-layer/commit/d2ed2145d61c37af24f4c8d18777586645525f78 should be enough to be able to deal with some ShadowTag virtual node implementation.

[jails]

And yeah, since Shadow DOM is tightly related to Web Components another alternative would be to attach to each Web Components its own virtual tree using the mount() method.

[jails]

So we probably fixed Shadow DOM concerns in 15 min ;-)

[ghost]

Almost :) I had to think a litle, and innerHTML are not working on shadows. So if someone consequently render a shadow node, and set a property to innerHTML there will be an issue. Workaround? Maybe check if shadow before setting innerHTML and then set an alternative.

If no workaround, there will be no inner HTML on the rendered node, or I'm wrong?

A less common issue would be your callbacks. InnerHTML and other things that conflicts with a shadow can occur.

[jails]

I don't think it's that complex. Instead of updating a dom element and its children directly, shadow dom requires to have them updated through theshadowRoot property of the dom element (which is a document fragment). Btw if you want to use innerHTML you should be able to do it through domElement.shadowRoot.innerHTML.

So probably replacing:

update(to.element, this.children, to.children, to);

into:

update(to.element.shadowRoot ? to.element.shadowRoot : to.element , this.children, to.children, to);

inside the patch() method would be (in gross) the starting point to have the shadowed element to be updated.

[ghost]

I see this, but this is only updating the children. What about the lines under it? properties, attributes, and NS ? Adding the same to.node check on this lines?

[jails]

Afaik properties, attributes, and NS attributes should be applied on the dom element itself and not its shadowRoot, but I didn't have a lot of opportunity to study shadow DOM in depth so maybe I'm wrong.

[ghost]

There are also issue in the specs it seems with namespaces and SVG for shadow DOM, so your update of namespace can be an issue.

I'm re-searching just now, will come back as soon as I know the answers

[ghost]

First off to me it seems that the shadow DOM need to be in the XHTML namespace. So if you - example only - append something you need to do: append('xhtml:textarea') and not append('textarea')

So to create correct elemnts it seems to need this:

var document = this.ownerDocument, namespace = this.namespaceURI; return namespace ? document.createElementNS(namespace, name) : document.createElement(name);

Some of the stuff you can read here. This is for SVG ( NS ) http://lists.w3.org/Archives/Public/public-webapps-bugzilla/2014Feb/0034.html

There are other issues too, but not so many browsers support this YET, so I think this is not a problem. Only use your patch solution, and maybe the createElement solution, and let people open issues on this if it's a big issue.

My point is, why waste a lot of time that probably a few people use today?

[jails]

Interesting ! And I'm agree, let's see where it leads. But I'm pretty confident the current architecture would support shadow DOM without much effort. And we will fix "specific issues" on time.