Doing ADA Testing and was wondering if you can target xpath for Pa11y's actions.
For instance:
"click element xpath",
I only ask because there are multiple elements on the page with the same target. No unique identifiers to tell pa11y what to click.
It's not possible to use XPath queries for Pa11y Actions — all of them rely on CSS Selectors instead.
(Specifically, they use document.querySelector under the hood).
Of course with CSS Selectors you can achieve a lot of the same things that XPath can even when there's no unique identifier available; e.g. by using sibling selectors like :nth-of-type. But there is no way to select backwards up the DOM from a child selector to its parent using CSS Selectors.
Related
I am taking practice test for Microsoft 70-480. I came across the question in the image. To select attributes that end in specific given value should be a css attribute selector such as [attribute$='value']. I don't understand how we make that selection with a css pseudo-element. Can some one explain to me why
As you've correctly stated, you need an attribute selector for this (although you would need to use [attribute*=value] instead), and you can't match elements using pseudo-element selectors (that's why they're called pseudo-elements!).
The only explanation for the "correct answer" here being option C is that whoever wrote that test either made a mistake with the options, or doesn't understand CSS selectors. Hopefully the former.
One of CSS lint rules is: "It's better to not use IDs in selectors".
So, what should we use instead of IDs to point to a unique element?
For example, say I have dozens of elements that have a class named my-class, and I want only one of them to have a special CSS property. What can I do?
CSS-lint should be 'fixed' or rather updated to modern standard because its based on more than 10 year old code base where support for IE6 and IE7 where still preferable.
Nowadays everyone should know ID's are the fastest css selectors followed by Classes, Dom tags, adjacent siblings etc. And that CSS reads from right to left. So the shortest selector is the fastest. Since #ID is the fastest selector and #ID (should be) unique its ridicule to not use the #id as selector in CSS.
give them another class for example:
<div class="myClass special"></div>
.myClass.special{
color: red;
}
You could add an additional class to the element and specify it in your css instead of ids. ID selectors have a higher specificity than attribute selectors but using ids in css isn't recommended and can't be reused. CSS classes can do everything IDs can.
According to mdn :
The descendant selector is the most expensive selector in CSS. It is
dreadfully expensive—especially if the selector is in the Tag or
Universal Category.
When Modernizr is up , it adds all the non supported classes to the html tag.
Meaning he can later do :
.myNotSupportedClass .myLastDiv <-- notice descendants selecotr[ ]
{
color:red;
}
But this is absolutely slow operation an operation which can be optimized.... which has to go through all the DOM tree in order to find the div.
I know there isn't another way of doing it , but still :
1) they could have added those classes to the body/form which is closer to the elements. soo there will be less of searching.
Or am I wrong ...,?
But this is absolutely slow operation
Eh.
they could have added those classes to the body/form which is closer to the elements. soo there will be less of searching.
body: how much less searching? 1 level less? How much of a difference does that make?
form: not every page has a form, and pages can have more than one form. The form element itself can be placed anywhere in the page body too, so the elements that should be affected by selectors in Modernizr class context may very well be unrelated to it, making searching completely impossible.
Do whatever you like, but since Modernizr chooses to place classes on the html element, write contextual selectors that make use of those classes and the descendant selector. If you're that obsessive about descendant selector performance, you have the choice not to use Modernizr and lose all the feature detection goodness it brings.
Why it chooses to place classes on the html element is anybody's guess. It could have been the most convenient element to place them on.
Can someone help me explain why:
#id .classname
is worse than:
#id element.classname
from a rendering/performance perspective?
Because the DOM has special functions (getElementByTagName) dedicated to find all elements in a tree by their tag name. These functions use lookup tables and are well optimized. No such method exist for classnames, however, and finding a classname requires to iterate through all the tree(s) and check existing classnames. This algorithm can be made quicker by reducing the size of the trees to iterate, and using an element. prefix does just this: it reduces the size of the trees to look for the classname.
simply because .classname has to check all elements for the specifyed classname, while type.classname only hast to check elements matching the specified type.
I think because in the first example, the browser rendering engine should search for every element with class classname inside the #id element.
The second example would be faster because the engine looks just for every element element with that class.
Sorry for the word game, however this should be non influential from a performance perspective.
It's not.
For the first selector, the browser checks if an element has the class, then it checks if any descendant has the id.
For the second selector, the browser checks if an element has the class, then if checks if the element matches the tag name, then it checks if any descendant has the id.
If the selectors have the same effect, the first selector is better, as the browser has to do fewer checks to match the rule.
More information about efficient selectors: http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
Don't overoptimize your code, make it clear (and this is just about you and your habits, or your team standard) and see about performance later.
When your css selector will be your bottleneck, then you'll have 1 000 engineers working for you.
I am using CSS selectors as the element locators for selenium test scripts.
Now, I want to check if an element has a rel="nofollow" attribute using CSS.
Does any one know how to check this?
The question isn't 100% clear on what you're trying to do, but I'll try to answer anyway.
If I'm reading you correctly, you're working within the Selenium script language, and you want to determine your the Selenium script that the page contains an <a> element that has rel='nofollow' attribute.
According to the Selenium reference page, this should be possible, as Selenium supports most CSS selectors (the exception except pseudo selectors, but they're not relevant for you here).
It also supports DOM references and XPath references, so one way or the other you should be able to check just about anything.
For CSS, the syntax is css=cssSelector, so in your case this would be css=a[rel=nofollow].
This selector will check the page for any <a> element with the rel=nofollow attribute. If you need to check if a specific element has this attribute, then modify the selector to include the ID or class of the element you want - eg a#myspecificelement[rel=nofollow]
This would be used with a Selenium command such as assertElementPresent() to check that the element is present, or a range of other possible Selenium commands.
Hope that helps.
a[rel="nofollow"]
Won't work in all browsers.
A better solution would be to use jquery who selectors are supported in all browsers
$('a[rel="nofollow"]')