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.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Wishlist: set properties of Custom Elements in templates #16235
Browser: [all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Hmm. That specifc format is definitely only possible inside $compile. However, you could write your own directive that binds a key value map to the element. That's a bit clumsier obviously but a more flexible workaround.
It seems that there are valid security concerns with implementing this.
In the same spirit as @Narretz's plnkr, you can have a custom directive that looks very similar to what you want (but you take all the responsibility for using it securely 😛):
I'm not sure I understand what the security concerns in @Narretz plunkr approach are. The attributes that get assigned come from template, not variables / user input, so you can't assign to innerHtml unless innerHtml is one of the keys in the template.
First of all, there is no restrictions on where the expression comes from. The property names can be hard-code in the template, or be computed keys on the template, or the whole object can come from the controller (in which case it can be a result of user input).
Further more, by having a directive that can set any property, there is a lot of API surface to keep secure (innerHTML, src, onload, onerror, etc). Having this as a built-in directive, we can't rely on it being responsibly used. We would be providing a great opportunity for people to shoot themselves in the foot.
Having it as local directive, on the other hand, you will be responsible for using it securely. Which is much easier to do on a per project basis, because you can limit it to specific properties or otherwise ensure that it is not abused.
Activity
Narretz commentedon Sep 21, 2017
Hmm. That specifc format is definitely only possible inside $compile. However, you could write your own directive that binds a key value map to the element. That's a bit clumsier obviously but a more flexible workaround.
http://plnkr.co/edit/7gvw0cqICfYZFAPi6bcG
Here's a bit more info about the problems with an ngProp directive: #10072
Btw could you change "Angular 1" in your blog post to "AngularJS"? That's the preferred name. :)
gkalpak commentedon Sep 21, 2017
It seems that there are valid security concerns with implementing this.
In the same spirit as @Narretz's plnkr, you can have a custom directive that looks very similar to what you want (but you take all the responsibility for using it securely 😛):
Demo
vivainio commentedon Sep 23, 2017
I'm not sure I understand what the security concerns in @Narretz plunkr approach are. The attributes that get assigned come from template, not variables / user input, so you can't assign to innerHtml unless innerHtml is one of the keys in the template.
gkalpak commentedon Sep 23, 2017
First of all, there is no restrictions on where the expression comes from. The property names can be hard-code in the template, or be computed keys on the template, or the whole object can come from the controller (in which case it can be a result of user input).
Further more, by having a directive that can set any property, there is a lot of API surface to keep secure (
innerHTML,src,onload,onerror, etc). Having this as a built-in directive, we can't rely on it being responsibly used. We would be providing a great opportunity for people to shoot themselves in the foot.Having it as local directive, on the other hand, you will be responsible for using it securely. Which is much easier to do on a per project basis, because you can limit it to specific properties or otherwise ensure that it is not abused.
(That's my understanding at least 😁)
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…
feat($compile): add support for arbitrary DOM property and event bind…