Page is a not externally linkable
Fotiman - 7:34 pm on Dec 9, 2009 (gmt 0)
I understand what you're saying. However, reading the actual warning message, I am in no way urged to add classes to anything. So I don't think that's a valid argument to make. More on this later(1). Again, I see what you're saying. Yes, changing your CSS in such a way could break pages if you are reusing class names to apply differently to different elements, and/or by reducing the specificity such that a rule that had lower specificity now has greater specificity. This is a new tool, and like many new tools it may need some tweaking and clarification as far as what the messages mean. There was alot of confusion around HTML and CSS validator messages, which have improved with time, and I expect these messages will improve with time as well. But my guess is that Google assumes that if you're using this tool, then you are a CSS expert and know exactly what you're doing (and yes, that is a poor assumption). See, I don't entirely agree. I think it really depends on your site. In certain cases, it certainly will make more sense to include longer specificity chains. However, often times I see developers do things like: As for what Page Speed considers inefficient: Note, I hadn't read this page before my previous post. I had assumed that the "Tag key" was the "ul", but in fact it is the rightmost "a". I now understand exactly where you are coming from. In fact, you're right, they do explicity say: (1) My initial misunderstanding of part of what the warning message was saying points out that they need better warning messages. Also, it seems that they ARE in fact wanting you to add classes and/or ID selectors to more elements. I understand their argument that it is more efficient if the rightmost element of your CSS selector (the "tag key") is an ID or class, as it will mean less traversal up the DOM tree when matching selectors. But you are certainly correct! Adding classes and IDs to every element is NOT efficient from a markup perspective, and I think they need to do a better job explaining this, and validating it with actual performance numbers. I will say, though, that it makes sense to the extent that if you have a tag name that already has a class or id value, then you would be better to use that id or classname as the rightmost selector of your style rule (but I wouldn't go adding a bunch of IDs and classes for that purpose alone). (2) The suggestions to remove the redundant qualifiers is, I think, a good suggestion (and the documentation even says "Class selectors qualified by tag selectors (when a class is only used for one tag, which is a good design practice anyway)." (Emphasis added is mine). I think armed with this knowlege, developers might create NEW sites that use more efficient CSS. Modifying existing sites can be tricky, and as I mentioned above, it's up to the developer to know what sort of impact a change like that will have. So I'm changing my tune slightly. I think some of what those warning messages say may be correct, but I now understand why you thought it was suggesting classes on every element. :)
The opening post illustrates the perception of these speed "warnings" precisely, and while someone may know how to interpret them and even take the decision to treat them as no more than alerts, unfortunately not all will and that is going to confuse people to the end that they will, or might, revert to classes just to see, or rather not see any warnings
...then they just might add divs and classes all over the place in order to NOT see warnings...
however
if you're going for smallest code possible, then this would suffice:
.tabs a
is very dangerous, sweeping advice to give/take based on such warnings, it could break pages.
the information that these "warnings" are giving is contradictory to efficient CSS and they are even calling it inefficient
div.foo ul li a
When div.foo will never contain any links outside of the lists, and .foo will only ever apply to a div (so it could be shortened to .foo a). It all depends on your content, and what practices you and/or your organization are exercising. But I don't think it's fair to say that ALL of those warnings are "contradictory to efficient CSS" (More on that later(2)). Efficient CSS, in my opinion, means using the least amount of specificity required, allowing the cascade to work (don't redundantly define styles that are inherited), and avoiding code bloat (in both the HTML and the CSS)... it's up to the developer to know whether or not changing the CSS specificity will impact other areas of the site.
Avoiding inefficient key selectors that match large numbers of elements can speed up page rendering.
[code.google.com...]
Make your rules as specific as possible.
Prefer class and ID selectors over tag selectors.