Polymer's paper-input element allows two way binding of value attribute when used with shady DOM. But it does not allow two way binding with Polymer 2 because Polymer 2 uses shadow DOM
<paper-input label="User Name" value="{{username}}"> </paper-input>
There is a possible explanation here https://github.com/PolymerElements/paper-input/issues/297
But I am not sure if I understood it correctly or I am missing something. It is little hard to believe that paper-input was never intended to be two way bindable?
<paper-input> works with two way binding. Tested with Polymer 2.
b.t.w. The github issue was closed over a year ago...
Related
Certain elements, like iron-list, require template elements as children.
However, Polymer 3 strips templates of its content.
How are these seemingly conflicting principles supposed to work together?
See the jsbin examples # https://www.webcomponents.org/element/#polymer/iron-list (they don't work due to the empty nested template).
The preserve-content leads to missing binding capability, so that's no viable solution.
What's the reason for this template-stripping anyways? (Docs just say "better performance".)
The given examples have been updated and work now.
It seems like the combination of v3 elements and v2 polymer-core caused the failure.
Also my personal guess is that template-based elements are manually Templatizer-ing their child templates to stamp the content of the template even though the template's actual content is undefined.
Templatizer seems to access the cache content that is noted in the docs.
This is a follow up question from an earlier post. In this post I ran into a problem where I could not get the value from a <select> element. The solution turned out to be embarrassingly simple. Use lowercase <select> in the Angular template instead of uppercase <SELECT>.
We all know HTML is case insensitive, which leads me to my question. Why was I unable to get the value of the select when the element was <SELECT>, are Angular templates case sensitive?
When I inspect the element in the DOM regardless of whether I used <SELECT> or <select>, the element is always rendered in lowercase. Which from my understanding is expected standard browser behavior. This further leads to my suspicion that the behavior I experienced is a result of something Angular is doing.
I've scoured the internet trying to find an explanation for this, but have been unable to find an explanation. Almost immediately after asking the original question, user JBNizet, was able to point out my mistake in the HTML. It is that level of insight and understanding of the relationship between HTML templates and Angular I am trying to gain.
Are template components case sensitive?
Yes, the templates are case-sensitive in Angular. You have to write ngIf, for example, in order to trigger parsing it as a directive with the selector [ngIf]. ngif or NGIF would not work.
Using SELECT works as expected wihout a problem. The culprit is the control value accessor for the select element, which has a selector specified as something like select[formControlName], which does not match <SELECT formControlName=foo>.
Is the <firebase-login> element available in Polymer 1.0?
The documentation here for the <firebase-element> makes no mention of the <firebase-login> element. However it does mention <firebase-auth>.
On the other hand, my Polymer Starter Kit (PSK) ships the <firebase-login> element.
Which is the correct element to use? Do I need to update my PSK?
What's going on here?
You have to use <firebase-auth>.
Github Demo
Documentation
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Custom attributes - Yay or nay?
Is it appropriate to create custom attributes for HTML elements as so:
<input type='text' value='name' custom_attribute='value'>
This seems a little hacky and I'm not sure if it is supported largely or exactly how it would be accessed via DOM.
Check out html5 data atrributes.
Mr Resig explains more
A new feature being introduced in HTML
5 is the addition of custom data
attributes. This is a, seemingly,
bizarre addition to the specification
- but actually provides a number of useful benefits.
It's formally supported by HTML5: http://www.javascriptkit.com/dhtmltutors/customattributes.shtml
Your code will not be valid if the attribute is not in the spec. I suggest looking into storing data on elements using jquery's data storage: http://ejohn.org/apps/workshop/adv-talk/#8
thats DIRRRRRRTY!
it will work, but there is a lot of better and different ways you can achieve the same thing.
you can create a hidden input next to it that holds the desired value.
It does not follow strict guidlines, but you can do it. The Dojo Library uses that technique all over the place.
Good question. I've thought of it as a little hacky. It depends on how it's used. In many cases a hidden field will work instead.
In all cases where I have seen custom attributes use the internals of the system have bled into the html.
The answer to this one might be a bit subjective, but I'll share from my experience. Every browser I've ever used appropriately ignores any extra attributes that aren't part of an HTML spec - even very early versions of IE did this correctly. I've found it a handy technique for DOM manipulation, and recently as a helper for jQuery selectors. However, it's got some drawbacks and should be used sparingly. One of the drawbacks would be if you're using XHTML. In that case, you can't just make up your own stuff - you'd have to have a DTD or XSD that defines the attributes and then reference the schema definition as an XML namespace.
Just as an alternative suggestion... if it feels a little off to you to fake your own attributes, perhaps you might consider assigning a unique ID to your HTML elements using the ID attribute, which is valid on most if not every tag. Then, you can use a javascript dictionary to associate your element IDs with the variables you're trying to embed. The only reason you're using this is for javascript, right? I can't imagine any other reason this technique would be useful.
One more alternative would be to use a hidden tag as another poster suggested and then use jQuery's .next() selector http://api.jquery.com/next/.