Why does this.querySelector("#hello") not find my element and this.$.hello does find it?
Most likely the element you are looking for is in your element's Shadow DOM. Try
this.shadowRoot.querySelector('#hello');
this.shadowRoot.querySelector('#hello')
is not the recommended way, a better way is to use the built-in Polymer function:
this.$$('#hello')
Why?
It is a lot shorter and
It runs the build in Polymer function Polymer.dom(this.root).querySelector(selector), which is optimized for the use with Polymer
And for completeness, you could just use this.$["hello"] if you can't use this.$.hello or just don't want to
Related
I have a simple button that I want to trigger something when pressed. I gave the button an id and created a listener for id.tap. This works fine, but when I put my button inside a template[is=dom-if] it stops working. Is this meant to work like this? How do I solve this?
Elements inside a dom-if don't exist yet when the element is created, so they're not accessible using this.$. Either give the element an on-tap attribute, or use Polymer.dom(this.root).querySelector to find the element.
FYI, the documentation recommends against the liberal use of dom-if.
Since it is generally much faster to hide and show elements rather than destroy and recreate them, conditional templates are only useful to save initial creation cost when the elements being stamped are relatively heavyweight and the conditional may rarely (or never) be true in given usages. Otherwise, liberal use of conditional templates can actually add significant runtime performance overhead.
Usinghidden$=condition might be the best solution.
I am trying to bind data to the link's href attribute instead, polymer just returns the code as is.
Expectation
Reality
Can someone help me understand why it's not working so that I may fix it?
thank you.
I just made a very similar question, I think it may apply to yours as well. Apparently the string interpolation is not supported yet so you may want to try with computed properties.
I want to validate a custom polymer element. To do this, I want in javascript to access all my nested polymer elements to see if they are valids.
I can't find an easy way to do this.
this.querySelectorAll does not find my inputs that are nested in other polymer elements. It seems I can't use "/deep/" in these selectors.
Is there an easy way to do this ? Or do I have to do a recursive javascript methods that will call a querySelectorAll in all elements with shadow roots ?? (I guess performances will get ugly...)
Thanks for your help.
If there is no fast solution, I will probably try the other way around (have my inputs register to the parent)
Answer:
element.querySelectorAll() will find some elements when using /deep/, however, it only goes so far (1 shadow dom level). This would indeed necessitate recursive calls from each ElementNode.
Note:
This type of behavior largely goes against the core tenets of HTML (i.e. that the web page works no matter how well-formed the content is). In other words, all elements are valid no matter their placement.
As an example, I have made a custom element that only renders specific child elements and hides all others. This still keeps in line with the above tenet, as an element's base rendering is controlled by the element/agent, but allows for the developer/designer to customize its presentation aside from the standard presentation.
I've been working on a web app with UI built using the Html Service. It's known that HtmlServices uses Caja Sanitization in pre-processing. As a result of this I see that id's of HTML elements are mangled, '-caja-guest-0___' is append to the original id.
I wonder 2 things:
1) What are best practices if I need to be able to get elements by their id's?
2) Can I rely that that suffix will always be '-caja-guest-0___'? Or is there a rule for it?
Thank a lot for all your responses.
You shouldn't rely on any specific things that Caja does because we are and will be making lots of improvements to Caja, which may change how things are implemented. I'd think of any Caja specific changes as private variables in a class you're using: don't rely on them to stay the same.
When working with element IDs, $("#elementId") should just work as expected in jQuery. I would recommend doing this.
I've tried using jQuery's "$" function to select elements by the ids assigned in original un-sanitized code and it worked as expected. I think that CAJA also applies the changes to your code so the IDs match
Yes, and document.getElementById should work fine as well. Rule of thumb; don't worry about Caja.
So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?