Do You Know What’s an Inefficient CSS Selector?

Perhaps! I was curious how can inefficient selectors impact a page performance. To begin with this topic let me say that inefficient selector is referred usually as nested selector:

div span div {
    border:1px solid red;
}

as you can see here there are three nested tags I use to reference the innermost div. If you’re wondering how you’d know about inefficient selectors – well there is a plugin for the Firebug written by a Google team called Page Speed explaining which of your selectors are inefficient. See the image below.

In the demo page you can find what I was trying to achieve and you can play around with that code to measure by yourself the performance of the different selectors.

So who’s faster? Nested, IDs or Classes?

Actually its pretty though to say. Yet another surprise for me was to notice that the notation:

div.my-class {}

was a bit slower than the marked as “inefficient” by Page Speed:

div span div {}

Another good thing to mention is that there is a difference between div.my-class and .my-class

Question’s answer …

In fact div.my-class is always with a higher priority than .my-class even if you’ve the following code:

div.my-class {
    border:1px solid red;
}
 
.my-class {
    border:1px solid blue;
}
 
div span div {
    border:1px solid black;
}

And the computed style for Firefox was …

where “div span div” chain matches the same elements as the previous selectors, as you can see:

so even that div.my-class will be the most important and finally the element will get its red border! It does not depend only on where you put the CSS rules, but also on how they are defined.

direction:rtl

When developing a website for Arabic one of the most common questions is how to get it work with a reverse direction. Actually there is the CSS property direction:

.my-class {
    direction:rtl;
}

which makes the page right aligned.

Floating elements …

However sometimes there are elements on the page which are absolutely positioned and the direction property doesn’t do the job. The solution is something like combining the two settings. Both direction and float. So something like:

.my-class {
    float:left;
}

becomes something like:

.my-class {
    float:right;
    direction:rtl;
}

and of course if you’ve something like margin-left it should become margin-right!

Left to Right vs. Right to Left

As you may know the Arabic language is written from right to left in reverse of Latin and Cyrillic languages and in the web that means you must change the look of the page for that subset of users coming to your site.

One of the main problems are with web forms. Usually we use something like label:input pairs:

label: <input type="text" />

but when it comes to Arabic version it should be turned into:

<input type="text" /> : label

and that’s quite tricky!

The easiest way for me!

Well I simply wrap that chunk of code into a table. That helps me manage the direction with the CSS direction:rtl like so:

1
2
3
4
5
6

<table>
 <tr>
  <td>Label:</td>
  <td><input type="text" /></td>
 </tr>
</table>

When it comes to the Arabic version it can be translated with the simple:

1
2
3
4
5
6

<table style="direction:rtl;">
 <tr>
  <td>Label:</td>
  <td><input type="text" /></td>
 </tr>
</table>

Yes! Style sheets may block the rendering process in IE. When it comes to media different from the screen, as the print is:

media=print

this, lovely, browser stops the rendering until the sheet is loaded. This is pretty strange when it comes to such media, just because it is not used to render the page in a browser. In fact as Steve Souders says the normal behavior of the browser should be don’t block or even delay the sheets for media that is not the current one.

However for further reading see this post with many thanks to Steve Souders again.

Well I was writing these days about rounded corners and some cross browser techniques that help you do this job. But what’s actually a topic now is that most of the web developers are speaking about making different versions of a site for different browsers. Now this begins to look normal, but it isn’t. The ideal solution is to have everything working fine, in that case rounded corners to be rounded, on every browser.

As I wrote recently there is a way to do this in IE with the use of VML, but yet again this is not working on Opera, and puts another chunk of markup in your document, that leads to more difficult maintain.

The solution can be done with another approach that can be considered as one level beyond the VML usage. Thus you have scripts only in IE and clean CSS.

Everybody now’s using both:

-moz-border-radius
-webkit-border-radius

and now’s coming the new wave with:

border-radius

property in CSS3, but as we know it will be maybe present in IE9 and any older MSIE will be discarded.

What the .htc means?

It stands for HTML components file, which is completely JavaScript code that’s included via CSS as:

behavior: url(border-radus.htc);

Of course you can find such .htc predefined files everywhere on the web and it’s completely working.

The problem

is that sometimes after using many HTML tags with border radius IE appears to crash, which is nothing new, but however not desirable.