JavaScript and Market Share?!

It’s kind of strange to speak about JavaScript libraries and market share, so lets called it “popularity”. Have you ever been interested on which is the most famous JS library.

I’d guess everybody has the answer in his head, right? jQuery is becoming for the JS community something like Google for the web or IE6 on the browser’s market in the beginning of the century. How odd?!

However here’s a short list of who’s first.

1. Robert Nyman’s poll:

Note: original poll page’s here.

Clear enough jQuery rocks. As I personally use jQuery I still think that its success is based on his easy to start nature. However lets see another result chart.

2. Chris Coyier from http://css-tricks.com is showing almost the same result:

Note: original poll can be found here.

3. Finally Polldaddy’s hosting a poll, where the results are even more interesting.

Note: original source of the poll.

From these results I get more surprised not so much from the jQuery big advantage, but more from YUI. It’s a really very very powerful JavaScript library, perhaps misunderstood maybe because of it’s native complexity, don’t know?!

Benefits from Cookie-Free Domains

Lately most of the web developers are talking more and more about optimization. One of the practices everybody’s supporting is to use cookie free domains for static content. First of all, what’s static content. That, in breve, are all images, JavaScripts and CSS. That’s everything that’s transmitted to the client with no change from the server at all. In a typical PHP/MySQL site everything generated on the server site is considered dynamic, while every component that’s given to the client with no change is static. That’s why they don’t need cookies in the request.

That’s what Yahoo! YSlow says:

In a short example, lets say you’ve a web page with 10 background images used by its CSS file. Here’s a good practice to combine them in one or even use base64 for them, but that’s another talk. So in that scenario you’ll send all the cookies you’ve on the site with this images, but actually they don’t profit at all from this. The question is why you should send all this data with no need? Won’t you benefit from sending it with no cookies.

As it sound logical I read some articles recently describing that the benefit from putting the static content on a non-cookie domain doesn’t pays back. OK it may be strange, however every 40 ms or whatever of page load is important, aren’t they?

Setup a Cookie Free Domain

The problem is that if you’d like to setup a cookie free domain the things are becoming a bit harder. You’ve two options:

1. Move all your static content on a different domain, where no cookies are set.
2. Move your static content on a different sub domain and set all the cookies to the www subdomain. (Here’s a bit tricky).

All this indeed a bit tricky! So let me proceed with the next topic.

Benefits from CDN

A CDN or Content Delivery Network is a term become famous with the growing web. Now big sites have servers in almost every continent and perhaps country. CDN is an abstraction of all this. The good thing is that there’s supposed to be stored static content. Think about the YouTube’s video files. Another good thing is that this domains are cookie free by default. The thing is …

Why don’t You Combine Them?

You’ll benefit from both ideas. Cookie free domains with CDN. In one side the web page will benefit from the closest location of the server and the CDN and in other side all this will come with no cookies to you. That’s really nice and most of the time people thing of CDN for only storing large scale data, such as video files, but no one says you cannot put your CSS, JavaScripts and background images there!

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.

Do You Use LABEL?

Have you ever mentioned the existence of the LABEL tag? Have you ever used it? I guess the majority of us don’t. Let’s take a look of the following chunk of code:

<label>username:</label> <input type="text" name="username" />

It looks familiar to every web developer, but the most common usage in web forms is:

<div>username:</div>

or

<span>username:</span>

How Looks a LABEL Tag?

In fact if you use LABEL for the form instead of DIV or SPAN you’ll get the exactly same result as layout, beside that most common usage is a DIV or SPAN in place of the forgotten LABEL?! Why is that?

Can you see the difference between LABEL and SPAN?

For me the usage of DIV has become critically enormous. It may sound strange that there is a debate about the usage of one or another HTML tag, but don’t you think every little text label in a web project is surrounded by a DIV. Actually that makes clear that if you’d like to be semantically correct, than you should use LABEL.

The funny thing is that almost every project is loading its labels in a PHP array or object or whatever and there they are called “Labels”, but when it comes to HTML they are put into a DIVs.

Why Semantics Matters?

In fact this is important because this is really good for web robots. If this is not important for the human eye it is for a machine “eye”. That’s why there are two tags for bold text.

STRONG vs. B

You can see that most of the browsers display both tags exactly the same by default.

Why’s that? Because STRONG is semantically more important than <B>.

So if you want to make a text simply looking bold, wrap it in <B>, but if you want to make it important both for the human eye and for the machines, than use STRONG.

Source: complete demo.

Sites for mobile

Have you ever noticed that once you start designing a site for mobile, as iPhone and Nexus One from Google are, the site is looking really ugly! These two devices in particular, as may other using Opera Mini for instance, scale the site, because only than you can view the entire layout and than zoom to a particular part of the page.

This is nice because news sites as cnn.com or lemonde.fr are full of text & image information and once zoomed in they fit the screen – very nice feature of the browsers. However if you’d like to design a site for mobile the bad part comes here. Yeah you know how to detect the browser, that was a topic of one of my previous posts, but even than you fully functional, but less decorated site is scaled again and looks more ugly than the full version of the site.

How to make a site visible in mobile …

Look at the http://mobile.twitter.com – the problem is that if you open this link with a normal browser, not from mobile, you’ll get redirected to the twitter.com and you cannot see the difference.

You can see how it’s made on …

The digg’s mobile version. Look at http://m.digg.com. This time you can see the different approach just by looking at the source code. Pay attention to meta tag in the head – it simply says – “don’t scale”. Nice thing to notice!

Don’t scale my site anymore:

<html>
 <head>
  <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>
 </head>
...
</html>