Page is a not externally linkable
SuzyUK - 11:06 pm on Mar 9, 2011 (gmt 0)
[edited by: alt131 at 3:21 am (utc) on Oct 17, 2011]
heh alt,
out of interest, have you run your test pages through web page analyser [websiteoptimization.com] to get a "feel" for how they perform according to more generally understood definitions of "performance" and "efficiency"?
Yes I've run them through every optimsation known to man I think :) settled on the GTMetrix vlaues as I can download a history and see what changes what. I'm not really bothered about it as an exact science if you get my drift.. I know it's common sense really - I'm just concerned more about people who descend on the CSS forum thinking the unused/inefficient CSS warning is any easy "out" that they can cope with.. and also as an aside I'm a learning as always, what all this means with an interactive site.
.. for instance just now I was tackling a Forum page.. - I've no longer got "inefficient warnings btw. at least not ones that I'm willing to tackle yet - but on this page sitting at a PS score of 83 - (not finished yet! haven't minified or compressed) - I had just completed the "optimisation" of images as suggested and was awaiting a big score change LOL - it did .. it went down!
that I wasn't expecting as I had an awful time getting my uncompressed page to come out of the 70's , that turned out to be solely down to one unoptimised image, a single button in the WSISWYG editor for replies/posts.. after that I considered the rest a formality having done most of the leg work.. but this latest one just made me spit coffee! it's gone down because now instead of asking me to optimise it's asking me to sprite and giving me a lower "score".. btw I have got no intentions of spriting a set of Forum icons, on forum that I need to update anyway.. so I'll DataURI them eventually
nearly there though,
And this would be .
That no matter if you can (it's awfully easy to pop open that editor and modify/fix a provided CSS or image), .. do not mess with core, find a way to isolate the file or folder then tweak to your hearts content, if all fails you can just restore it to the provided files.. also it tells me that we do not live in perfect world and that provided modules and plugins are not perfect, hehe if they were there would be no issue queues or help forums I suppose so I'm not complaining except about the people who try to benchmark this stuff
So do your tests show if there is a score differential between
# just id's versus just classes,
# just classes versus multiple classes
# specific descendent selectors versus just id's versus just classes
so far..
no differential between ID's and classes, though the more descendant classes you have, the bigger a "parent" chain you need to make it VERY efficient (unique)..
a selector with only one descendant will be deemed "inefficient" no matter whether its parent is an ID or a class.. which surprises me, an ID with one descendant should be absolutely fine.. even two or three for goodness sake
think tables.. to make a table selector efficient, you can't say table#mytable td {} - because not only do you get the "over qualified by an element" warning but a td is one of two possible descendant trees for a table and even if you remove the qualifier (reduce specificity) you get the same warning.. the tree from that could be #mytable>thead>tr>td or it could be #mytable>tbody>tr>td
now put two classes on the <tr> say "tr class="even bold" and no I don't advocate naming a class after an effect but I can only describe so much in type!
now what does that do for the amount of selectors required to make it "very efficient" yes rhetorical
multiple classes are good if as a CSS'er you use them in Cascading order, so far I haven't found the need to "chain" any of my classes.. but I would if I had to, I find that re-factoring the stylesheet into a kind of "nested" structure means the Cascade can use the multiple classes as intended.. obviously - but that if you than take the time to "group" your selectors and by that I don't mean comma separate I mean with a comment or something (i'm using hidden comments) to spell out the HTML chain if these selectors are then beside each other in the stylesheet (gasp! rather than grouped selectors) it's much easier to see..
as to your last point/question no matter how specific you make your HTML with as many classes/descendants as possible if you don't write them as child selectors you will not see the benefit & if you do write them as required you will lose the benefit of CSS, you will be writing a style per selector.. that is in fact what I'm doing to "beat" that rule .. and if that does indeed turn out to be the case (I will be able to tell fairly easily!).. I will give up as CSS will have been spoiled.. may as well call it SS
and the biggest and I mean biggest downside to all of this is that you will need to repeat yourself in the stylesheet. Think now about nested lists as well as tables that might need the same CSS applied to various levels.. easy peasy in descendant selector language, but as they're apparently the biggest CSS penalty giver .. all I can only say I'm lost until the figures show themselves at the end of this little experiment
for now, one of the top CSS "wants" is that we should be able to nest selectors to save repeating ourselves and maintain readability.. try it, get something like LESS or SASS, both of which work as intended, but is the way CSS is supposed to work?.. darned browsers, still got their own agenda! btw my site is super fast on IE8 after all this time they start to get it right and apparently are not entering the "browser wars" as far as lowly CSS is concerned, they actually deal with it better, FF is the worst, Opera can't manage it all, though it does what it can quite fast.. and Safari is just hovering between FF and IE..
and lastly it's quite weird to peer inside a provided module and see some of your own code staring back at you :o
less emotion and more figures will follow!
[edit reason] Thread Tidy [/edit]