Does CSS selector .class-xyz:not(.class-xyz) ever match? - css

Given any CSS with a selector like:
.class-xyz:not(.class-xyz) {
...
}
Is it possible that it ever matches any element?
What about augmenting it with things like ::after, ::placeholder and so on?
My intent is to simplify a bunch of huge CSS sheets, with lots of selectors like this.

That selector will not match any element, regardless of namespace (since, even with namespaces present, the outside .class-xyz represents the default namespace, and the one inside the negation always considers the same namespace as the outside selector).
Since that selector will not match any element, it follows that no pseudo-element will be matched. For a pseudo-element to apply, elements need to be matched in the first place.
If you wish to hide a CSS rule without outright deleting the rule or tampering with the original portion of the selector, a shorter way to do so using the negation pseudo-class would be :not(*) (or, if namespaces are present, :not(*|*)). This use case is explicitly given in the level 3 and 4 specs.
But the shortest and clearest way to hide a CSS rule by far is to comment it out.

Related

How to use a pseudo-element to select links to domains ending in foo?

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.

"Don't use IDs in selectors (CSS)" then, what to use instead of IDs?

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.

CSS selectors, tagname + class vs class

Lets imagine very simple case:
div.className{}
vs
.className{}
Which option is faster and why ?
.className{} is faster in downloading, because of smaller size of the css file.
It is also faster when rendering page, because it is not necessary to look for div elements.
A guideline from google:
Avoid qualifying ID and class names with type selectors. Unless
necessary (for example with helper classes), do not use element names
in conjunction with IDs or classes.
Avoiding unnecessary ancestor selectors is useful for performance reasons .
One very important difference between div.classname and simply .classname is in something called selector specificity. It is a set of rules which defines which selector gets more weight once the browser starts going through all the selectors that potentially have influence on a particular element.
ne of the most basic rules of CSS is that selectors can be redefined in a way that whatever definition comes last and has influence on a particular element its the one that is going to be used (the sole exception being when using !important which always takes precedence).
Now in the above example redefining the .class selector should actually hide the text but instead its still visible. How is that possible if we said that latter rules always take precedence? Its because the div.classname rule has a higher specificity that .box since it actually gets points for containing both an element (div) and a class selector (.class) in its selector declaration (div.class).
Of course the div.class rule will be applied only on a div element but since class selectors are often reusable pieces of code there is plenty of situations when they are used on divs.
Although the rules in the official W3 specification are not that hard to understand they are sometimes pretty hard to remember. That's why I would like to recommend an excellent article on CSS selector specificity which can be found here.
In my opinion selector specificity is by far the most important thing to master when it comes to tracing inheritance problems with CSS stylesheets.
For Example
Find some more info
Follow Up

Why .classname is worse than element.classname

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.

Correct way to do Hover/Focus/Visited on links with a class?

Which is the correct way to specify a hover/focus/visited state on a link which has a class?
a:focus.class{}
or
a.class:focus{}
Both seem to work, just wondered which is considered the right way.
Both are correct since the pseudo-class can appear anywhere in there.
From the CSS2 spec:
Pseudo-classes are allowed anywhere in selectors while pseudo-elements may only be appended after the last simple selector of the selector.
Personally I prefer the second though, for readability mainly, that and it may change as you go, e.g. :hover, so I prefer having all the static then dynamic, not a mix...just makes more sense I guess.
Both are fine according to the CSS2.1 spec:
A simple selector is either a type selector or universal selector followed immediately by zero or more attribute selectors, ID selectors, or pseudo-classes, in any order.
A pseudo-element (:after, :before) is only allowed at the end though,
Pseudo-classes are allowed anywhere in selectors while pseudo-elements may only be appended after the last simple selector of the selector.
Personally I would keep the pseudo-classes at the end as well, as I think it improves readability.
The only example of this I could find in the spec was this:
a.external:visited { color: blue }
Like Nick, I prefer this way.
I think for readability I'd use the second. Declaring the pseudo class first could be easily missed during maintenance.
I personnaly use the second one, here is how I view this :
You must think of that with the semantics, you would say
"When <a> of class <class> trigger the event <hover> I want <that> to happen."
not this :
"When <a> trigger event <hover> check if it is of class <class> then do <that>."

Resources