You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
The elements contained within the template are always created in the HTML namespace. Whilst this is probably fine for the fast majority of cases if someone ever uses AngularJS with another XML document like SVG this could cause some problems.
Take the following plunker http://plnkr.co/edit/WNSc7Ux99MJWf9yPQpQf. When you view this (Chromium Version 31.0.1650.57 (235101) snapshot version of Angular) you should see two red squares side by side, but nothing comes up. If you open up the inspector inside chrome and look at the SVG element you should see two SVG paths that create the squares. If you right click on one of the paths and go to "Inspect DOM properties". If you look at the namespaceURI property of the object returned it has the HTML namespace "http://www.w3.org/1999/xhtml" and not the SVG namespace "http://www.w3.org/2000/svg" it was created inside.
If you contrast this to the two path elements that have been commented out by uncommenting them. Then two squares should then display. These two squares have exactly the same markup as the rendered directive the only difference is that these ones are in the correct SVG namespace.
Use case:
This is a problem for a project that I am working on where I have bound my Angular model onto SVG elements inside of a ng-repeat. At the moment I am not using directives and just the plain SVG constructs. However some of these are quite large and make the markup look like a mess and I would like to abstract this mess into a directive.
The text was updated successfully, but these errors were encountered:
I have submitted some code for this on pull request #5419 feat($compile, jqLite): Change directive definition object to allow temp...
I thought I would have an option to link that pull request to this issue but I did not see any. So sorry if I have created a duplicate issue. If I have feel free to close this one.
templateNamespace has been part of the directive definition for a long time and there's also some auto-detection going on. I guess this issue is resolved.
The problem:
When you create a new directive that has directive definition object as follows
myApp.directive('myDirective', function(){
return {
replace:true,
restrict: 'E',
template: 'some-html-content-that-git-hub-flavored-markdown-wont-let-me-paste-in'
}
});
The elements contained within the template are always created in the HTML namespace. Whilst this is probably fine for the fast majority of cases if someone ever uses AngularJS with another XML document like SVG this could cause some problems.
Take the following plunker http://plnkr.co/edit/WNSc7Ux99MJWf9yPQpQf. When you view this (Chromium Version 31.0.1650.57 (235101) snapshot version of Angular) you should see two red squares side by side, but nothing comes up. If you open up the inspector inside chrome and look at the SVG element you should see two SVG paths that create the squares. If you right click on one of the paths and go to "Inspect DOM properties". If you look at the namespaceURI property of the object returned it has the HTML namespace "http://www.w3.org/1999/xhtml" and not the SVG namespace "http://www.w3.org/2000/svg" it was created inside.
If you contrast this to the two path elements that have been commented out by uncommenting them. Then two squares should then display. These two squares have exactly the same markup as the rendered directive the only difference is that these ones are in the correct SVG namespace.
Use case:
This is a problem for a project that I am working on where I have bound my Angular model onto SVG elements inside of a ng-repeat. At the moment I am not using directives and just the plain SVG constructs. However some of these are quite large and make the markup look like a mess and I would like to abstract this mess into a directive.
The text was updated successfully, but these errors were encountered: