polymer attribute data binding with "$=" not working - polymer

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.

Related

VSCode: In a html file, when I type 'a' suggestion has 'anfn' for anonymous function at the top of the suggestion list

The next item in the list is the one I want: 'a' for 'anchor'. Why would such a suggestion show up in an HTML context? This is an annoying time-waster. I have not been able to track down where this setting lives.
[edit]
I am looking for a way to remove 'anfn' from the suggestion list when I type 'a' in an HTML page.
[edit]
Apparently, this is not possible to do in VSCode.
The anfn is showing up when you type 'a' as part of the IntelliSense and autofill in Visual Studio Code. While anonymous functions may have no use in HTML, they certainly do in JavaScript, which is commonly used with HTML to build webpages. This article should help you in seeing that there is a link between anonymous functions, JS, and HTML. This article should help in customizing IntelliSense, there may be a setting for what you want to do.

Angular: Are template components case sensitive

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>.

What does this mean: data-component-bound="true"?

What does data-component-bound="true" mean?
I've found this within a collapsed element but adjusting the value doesn't do anything. I've tried looking for the attribute "data-component-bound" on Stack Overflow and on Google but it points to a limited set of various jquery articles which are over my head and which take it for granted.
[edit post some answers]
Ahh, I see now that i should have been searching for "data-" to solve this. In so doing, I found this useful article which could help the next person: http://www.sitepoint.com/use-html5-data-attributes/
data- attributes are extensible: the author of the code can make up any data attribute they like. In this case, from a quick look, it seems it is used for the internal workings of websites to know when the 'component' (i.e. DOM element) is 'bound' to something - an event, an interaction, etc.
In general, data- attributes are used for that: data. They store any data, so are often used to substitute non-standard attributes that would otherwise flag up in a validator.
HTML data attributes allow you to set custom data for an element. The meaning of data-component-bound is determined by your code or some css or javascript framework that you might be using.
Search the codebase for 'component-bound' to see if it's being used. If you don't find anything, Google it to see if it's a popular attribute from some framework. If it's not, then you're safe to remove it.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes

What does the html attribute "opts" mean?

I found the following code snippet on a ajax-website:
About
I've never seen the attribute opts before. It's hard to find something in google.
For what is it?
It means nothing. It is non-standard and invalid. Presumably it is being used by JavaScript in the page.
The standard way to store data for JavaScript would be with data- attributes
I did a little research on Google and it appears they are using a Custom Document Type Declaration or Custom DTD.
http://www.htmlhelp.com/tools/validator/customdtd.html

HTML element's id after sanitization

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.