Asymmetric templateNamespace of directives

[djfd]

Hi,
when handling directives having NS set to SVG in HTML context, all is going fine.

But if we have a directive with NS set to HTML and handling it inside SVG context we still get SVGElement.

Please check http://codepen.io/djFD/pen/NRWQxR

Angular: 1.5.7
browsers: FF 48.0, Chromium 51.0.2704.79

[gkalpak]

Interesting. Currently we only use templateNamespace to handle svg and math in a special way, but we don't do anything for html. There would be a performance hit involved in fixing this, unless there is an easy, cheap and reliable way to detect the document type of the elements container.

A possible work-around is to embed the SVG-contained HTML inside a <div>. Is it even valid to have HTML content inside an SVG container?

[djfd]

well, lets start from a performance hit. Check starting from this

Currently if i have defined a directive for say <text /> tag, then any such tag encountered will be recompiled (to be exact will be wrapped, then new jqLite subtree will be created), regardless of where it was found, in SVG context (and thus has already type of SVGElement) or in HTML context (in this case it is actually need to be re-made).

So yes, reviewing the logic will increase performance for a such cases.

It seems, that it have to be something like to

if (currentCtx !== directiveCtx) {
  wrap();
  redo();
}

for those directives where template name spaces are defined explicitely and leaving it as is if it has it unset.

As for foreign content inside SVG, there is a special tag for that. BUT there are a cases (eg see angular/material#9478) where it is just convenient to have such ability to directly insert tags to be fully transcluded, without wrapping them into <foreignObject /> at first

UPD In generic case, it is invalid of course. E.g. Firefox, chromium, when known HTML tags (<span /> etc) are found, do remove them from svg, placing them aside of it and breaking all document layout. Or maybe it is a result of interaction with angular, I am not sure. UPD2 it is not angular related, demo - compare original layout and that we see after rendering, so browsers, at least FF and chromium, do move such well known HTML tags outside of svg container on their own

[djfd]

BTW, this check does not work in IE11 (EMU IE10, IE9), as toString.call(node) returns [object Element] or something like this.

I do use next for a such testing

var contextSvg = !! (node.namespaceURI || node.toSting()).match(/svg/i);

[gkalpak]

Wrt performace, (like I already said) if there is an easy, cheap and reliable way to detect the document type of the context, then it shouldn't be a problem (as we would only wrap html when the current context is not in HTML). If someone would like to investigate that, be my guest 😄

BUT there are a cases where it is just convenient to have such ability to directly insert tags to be fully transcluded, without wrapping them into <foreignObject /> at first

This particular usecase sounds like hacking around the spec (and looking for trouble). There might be other legitimate usecases, but I am not very motivated by this one 😄

this check does not work in IE11 (EMU IE10, IE9), as toString.call(node) returns [object Element] or something like this.

I tried it it worked for me. It returned [object SVGSVGElement]. Can you provide a demo?

[djfd]

well, not exactly demo, just a screen shot. it is under Win7, IE11. Need to say that last OS updates there were ~2016-03. But it seems under real hardware Win8 (up to date) the situation is the same, I will check after reboot.

UPD Windows8.1 + IE11 (all up to date) do produce the same result

You can see it yourself as well, there is a demo

It happens for a non standard SVG tags, which are perfectly allowed, as per HTML Standard's 12.2.5.5 The rules for parsing tokens in foreign content (subsection 'Any other start tag')

UPD2 After a few thinking I concluded that 'Any other start tag' algorithm of HTML standard is describing all these legitimated use cases of non SVG dedicated tags inside SVG.

[djfd]

Wrt detecting current context of a node, browser already did it for us

1. Checking node.namespaceURI would give desired result (but need to have RegEx involved)
2. node.constructor.name

Also we can simply scan up until opening <svg> or <body> is found

Neither of them is both fast and reliable simultaneously?

[djfd]

Well, I am feeling that my part of the job is completed here. BUT one question is still unanswered, or am I failed to see it?

Namely, compare this and this

Need not this last one look as

var namespace = directive.templateNamespace;

?

Just because this check does not work, as !namespace always evaluates to true and we perform [costly enough] testing for every node to be compiled?

[gkalpak]

@djfd, no it doesn't, because the returned function may be run multiple times (but namespace only needs to be detected once).

[djfd]

@gkalpak, oh I got the point, thanks

but it wont work if we will supply different future parents (thru options) upon every call of publicLinkFn though. it can happens that parents have different NSes, one is html, next one is MathML, and we are linking a few subtrees copies in interleaving mode. just thought