fix(ngInclude): correctly add non-html namespaced template content

[caitp]

It is now possible for ngInclude to correctly load SVG content in non-blink
browsers, which do not sort out the namespace when parsing HTML.

/CC @tbosch / @IgorMinar

Closes #7538

[caitp]

hmm, jenkins doesn't like it :(

[caitp]

Yes, this is a terrible test name, will come up with something better

[caitp]

It's hard to debug the failures unfortunately, ddescribe is no longer working, and it's not reproducible with iit

[IgorMinar]

!futureParentElement && !cloneConnectFn

[tbosch]

The approach seems ok!

[caitp]

So there's a problem, Safari seems to have problems with this --- it doesn't create childNodes at all when setting innerHTML of an SVG element =( (it's possible that it's not parsing immediately or something)

// Safari 7 debugger:
> $element[0].innerHTML
< "<rect></rect>"
> $element[0].childNodes
< []

(repro at http://jsfiddle.net/hp2rm4yc/)

[caitp]

There's a bug filed on this already for webkit https://bugs.webkit.org/show_bug.cgi?id=135698 --- I don't mind fixing it in the browser, so after my little conference talk I can spend a few hours on that maybe. But unfortunately that doesn't do much good for fixing this in angular for the legacy Webkit browsers

[IgorMinar]

I agree. overall it looks good.

[caitp]

As a short-term solution to the safari/webkit problem, we could also abandon the test if (!'innerHTML' in SVGElement.prototype). sgty?

[IgorMinar]

add a blank line above this line

[IgorMinar]

could we simplify the check to !$element[0].childNodes.length && ctrl.template.length

[caitp]

The fix as-is doesn't really work well enough anyways (works for Safari now, but not for Chrome/Firefox) --- I think we want to take the SVG path for both chrome and FF --- so we need to tell the directive that it's supposed to be an SVG node.

I guess a quick SVG test for the toString()'d name of the template would be good enough

[IgorMinar]

AFAICT we don't need to call jqLite here.

[caitp]

with the latest fix, (I think) this works correctly --- it's not quite right yet, I'll try to get it ready to land tonight and merge before release

[caitp]

the jqLiteParseHTML addition doesn't matter much, but I don't think it's bad to have it

[caitp]

From local tests, the current iteration is working well on Safari, FF31 and Chrome --- I think it's ready to squash and land --- @IgorMinar can you take a last look at it (the diff is smaller due to the removal of revert of petes commit)