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>.
Related
I was under the impression that when a browser (generally) searches for an element that has a class it is a depth first search.
Recently I was asked to put some code together for a colleague, and asked to identify forms on a page with the substring of 'webform' in the class. I knew there was a form on a page I tested and used the following JS:
document.querySelector("[class*=webform]")
However, this returned the body element of the page whose class attribute had the substring of 'webform' in it. Generally (this question being browser dependant) is the searching in the DOM for elements containing a certain class depth first? Is it totally implementation or browser dependant (as in querySelector will use one method and another function will use a different method)?
Many thanks.
#hungerstar is right. Apologies for the brain fart, seems I need to brush up on my trees a little!
So in conclusion, it proved that it is depth-first. Great!
I was locating the elements for selenium through the inspect function of my actual browser (chrome) and never had any issues. Now i had a case where the located element couldn't be found and i figured out that in my selenium chrome instance, the element has another ID then in my "normal" one and that's why i can't locate it.
This is the case with some other elements too and i can't spot the pattern.
In "Ikognito"-mode of chrome, i get the same values as in my normal browser, and the ids that my selenium browser gets are the same aswell everytime i launch the programm.
Does anybody have an explanation for this ?
Is this common practise upon web developers and whats the way to go about this issue on future projects ?
Do i always have to run my selenium browser first and then extract the elements IDs out of there ?
Although locating elements by id is the preferred way, it is not the only one, the are way more options like:
name attribute
link text for a elements
partial link text for a elements
HTML tag name
class attribute
CSS selector
XPath selector
The latter one - XPath is the most powerful as it's almost a programming language. Unlike other selector strategies XPath selectors have full awareness of DOM page, can lookup all attributes, text, parent/child objects, traverse axes and if it's not enough you can go for functions and operators to precisely select whatever element is needed.
With regards to dynamic IDs - it's quite a common practice when the page is not deterministic and the content is dynamic. Theoretically you can ask your application developers to come up with a custom HTML attribute which will be used for automation and maybe user tracking, but if for some reason it is not possible - you will have to define another way of locating the element.s
I am using angular-ui-select within a website where the styled select fields are configured with an own tag named ui-select. This works great, but doing a W3C validation leads to this error:
Element ui-select not allowed as child of element div in this context. (Suppressing further errors from this subtree.)
Here's an example code:
<!doctype html>
<html lang="en">
<head><title>x</title></head>
<body>
<div>
<ui-select></ui-select>
</div>
</body></html>
I understand that <ui-select> is not expected to be there but how can I handle this better?
Can I wrap it into a different tag or is there a different approach for ui-select instead of using HTML markup?
W3C HTML5 validator maintainer here. The short answer with regard to the validator behavior right now is, the validator's going to emit errors for any custom elements you use in documents, and currently there's no way you as a user can work around it doing that—and it's going to continue that way for some time longer until we get around to figuring out a solution.
We're having some ongoing discussions about how to solve this. Changing the validator to just ignore any element name with a hyphen is not viable as a complete solution, because the consequence of that is we could then not practically check any child elements it might have—we'd just have to ignore the entire subtree, because to do otherwise would lead to other errors. So that's way short of being an ideal solution.
Anyway, I'd love to find a good way to solve this, so if others have ideas I'd like to hear them. Two good places to send ideas/proposals on this are the public-webapps#w3.org mailing list https://lists.w3.org/Archives/Public/public-webapps/ and the whatwg#whatwg.org mailing list https://whatwg.org/mailing-list#specs
One idea I've thought of myself is, we could just have the validator treat all custom elements in the same way it currently treats the <div> element (as far as where it's allowed in a document and what child elements it's allowed to contain). That's also short of ideal, but at least it would give a way to check for errors in descendant elements in the custom element's subtree.
Update 2017-02-06: the W3C HTML Checker now supports custom elements
So, I added support for custom elements to the W3C HTML Checker (validator) on 2016-12-16 and a few days later refined it to do more detailed checking for prohibited names.
The trick I ended up figuring out to implement it in the checker architecture—which is at its core a RelaxNG grammar/schema-based validator—was to add a pre-processing filter that take any elements that have a hyphen in their element name, and puts them in a separate XML namespace.
Then I updated the RelaxNG schema to allow any elements from that XML namespace anywhere. (Which is ironic because I pretty much hate XML namespaces and all the problems they cause.)
So we’re now looking at doing something similar for custom-attribute names—probably just by defining those as being any attribute names that contain a hyphen (like custom-element names).
But the HTML checker can’t be changed to allow custom-attribute names until the HTML spec is updated to allow them. For that, see the proposal being discussed in the HTML-spec issue tracker.
That's indeed a long-known issue with AngularJS.
A few things you can do:
Instead of using the element <ui-select>, you can use <div ui-select>, but that will still fail on the argument.
An argument prefixed with x- or data- will pass but I am not sure ui-select supports that.
HTML W3C validation is useful, but I think mostly important for HTML emails so they don't get screened as spam. It's also good for search engines, but really not that critical.
If you look at 'why validate', the reasons are mostly for cleanliness, ease of debugging, and overall good practice.
Angular (un?)fortunately expands the realm of possibilities for HTML5, in a way that, naturally, deviates from the latest specifications for HTML.
We are having the same problem using Knockout custom components.
http://knockoutjs.com/documentation/component-overview.html
I added a suggestion how to enhance the validator with a minor enhancement for users wanting to use custom elements even if the specification is not yet final (http://w3c.github.io/webcomponents/spec/custom/#custom-tag-example):
https://github.com/validator/validator/issues/94
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
According to many recent HTML specs, when we are using custom attributes (meaning any attributes not defined in the spec), we should prefix them with data-. However, I see no reason to have to do this (unless you require perfectly valid HTML, obviously). Pretty much all current browsers correctly ignore custom attributes, meaning no conflicts except with identically-named attributes from others' code, and we can ignore even this with custom prefixes or something similar (as suggested on the AngularJS directive page). What, if any, other benefits are there? This question has been asked before, at least twice, but both are pretty old.
I forget where I read it, but some guide said custom HTML tags need dashes, and single-word tags aren't valid. First of all, why? Second, should we do this, and why (besides being valid)? Would there be any problem with underscores or camelCase, etc.? Also, conflicts with existing elements shouldn't be a problem, if, like with data attributes, you prefix or suffix them, etc. See the Angular directive page again.
I'm sure all these questions have been asked before, but I'm combining them into one. Is that a good idea (quick, someone ask on Meta)?
The data-* attributes have two advantages:
It is a convention meaning other programmers will understand quickly that it is a custom attribute.
You get a DOM Javascript API for free: HTMLElement.dataset. If you use jQuery, it leverages this to populates the keys and values you find with .data().
The reason for the - in custom element names is for two basic reasons:
It is a quick way for the HTML parser to know it is a custom element instead of a standard element.
You don't run into the issue of a new standard element being added with the same name which would cause conflict if you register a custom Javascript prototype for the DOM element.
Should you use your own custom element name? Right now it is so new that don't expect it to be fully supported. Let's say it does work. You have to balance the issue of the extra complexity with the benefit. If you can get away with a classname, then use a classname. But if you need a whole new element with a custom Javascript DOM prototype for the element, then you may have a valid usage of it.