Faster CSS

HTML & CSS
21

It is better from a clean code point of view but slower to parse than having a classname directly on the element.

When checking from right to left .className is matched immediately whereas div p em will take three passes to find the correct style to apply (e.g. em is found but does it have a parent that is a p element? If yes then does it have a parent that is a div? and so on.

Also is the p necessary here? Why not div em? And if you are saying div em then you may as well say just em because div em will hit more or less everything on the page anyway.

As a general rule its better to avoid using em.classname but just to use .classname (although I will occasionally use the selector to aid readability from the stylesheet). However there is rarely ever a need to say div.classname unless you are trying to be too clever and re-use the same class with different styles on different elements. Just use a different classname.

Keep your rules and paths as short as possible and avoid things like div.classname ul li ul li a{styles} when in fact .classname li li a{} will reach the same element.

Everything is a trade off between what is sensible and what is fastest. In most pages neatly written css doesn’t have to be messed with to gain speed improvements as other areas will gain more results.

22

Well, I was thinking about a word being emphasized inside a paragraph inside its div.

I think that the discussion is really interesting and it’s giving me things that I normally don’t have the time to think of. Yet, I find very difficult to follow these rules all the time. Why?

Well, CMSes are widely spread and a template for a CMS has to fit all kind of users. I’ll play devil’s advocate and say the only way to satisfy everyone is doing serious use of classes and IDs so the markup is not changed. If you change the markup you may mess up the whole template so it is better to avoid that.

Also, you have the plugins to add functionality. And, of course, the creator of that plugin doesn’t know where you will be using it so he tries to make it as generic as possible and that means that the plugin will necessarily add more markup than needed.

But if you do change the template’s markup, and even more the plugin created markup, to accommodate your needs and make it more accessible and semantic, everything is going to be messed up again when you upgrade your template or the plugin. That means back to square one.

23

OK, ok… well, I guess in theory you could have

<div><em></em>Whatever</div>

Since the div is already a block element… but Ok, you’re right. Mosts, if not all, em’s are inside p’s :lol: So i guess that div p em is stupid.

And it will probably be better to do div em than p em since it is very likely that you have less divs than p’s :slight_smile:

24

Is there any <em> inside that <div> that is not in a <p> ? If not, there really is no need to have that p in the rule; it only slows stuff down for nothing.

25

DS60, I agree with your approach to sparing divs, but do you find divs mostly semantically meaningless? I’ve had a web developer tell me that when we were discussing the cutting down of code. He’s mostly pro-HTML5, looking to remove all divs in lieu of using some of the newer tags. I can sort of understand his reasoning but as for me, whenever possible I stick just using an h1 for a page header and assign a class to it to style it in. But I don’t know if that’s an appropriate use.

26

DIVs have no semantic meaning. However, I don’t think we’re at the point where we should be getting rid of all of them… they do have a use. However, “div-itis” should also be avoided.

h1 through h6 still have a very important meaning.

27

That is what they are FOR, a wrapping element that does not change or add meaning to the elements they are around. “semantically neutral”. DIV, being a DIVision. It exists solely to divide up content into common sections for styling… said styling may not be present in all targets and again, implies no meaning.

Which is a good thing, because your tags with semantic meaning should be doing the the job when stuff like columns or graphics hung on the content aren’t present!

… when in all likelihood those DIV were unnecessary (especially with CSS3 on the table now) making using those new wrapping tags ALSO nothing more than extra bloat… adding “meaning” on top of the existing meaning of the tags inside them…

When really eventually the CONTENT elements should be speaking for themselves… But then, I’m the guy who still uses horizontal rules to mark the end of sections started by headings, then hide them with display:none for screen. That’s how you were supposed to do it on HTML 2…

… and I quote

HTML 2 spec:
The HR element is a divider between sections of text; typically a full width horizontal rule or equivalent graphic.

html 3.2:
Horizontal rules may be used to indicate a change in topic. In a speech based user agent, the rule could be rendered as a pause.

One of the complaints I have about the actual HTML 4 spec – it doesn’t actually say what most of the elements are FOR… HTML5 being even worse in that regard; funny since I usually rag on HTML 3.2 :smiley:

<h2>Section Title</h2>
<p>Section Content</p>
<hr />
<p>This is not part of the section started by the h2</p>

Too simple? Too clear what’s going on when CSS isn’t present?

Don’t need no steenkeeng NAV, HEADER, ARTICLE, FOOTER… Pointless wasteful bloat.

though I do think some clear structural rules CLEARLY stating how to use the tags we already have could work WONDERS. Right now even with strict, things are WAY too vague and poorly explained… HTML 5 just makes it worse and even more needlessly complicated.