Internet Mobile

It isn’t strange that the internet is becoming more and more mobile. When it matters to news sites I think most of the mobile versions are better than the “desktop” versions of the site. Take a look at Huffingtonpost.com or LeMonde.fr.

Mobile Ads

The first thing that makes impression when comparing both mobile and desktop versions of a site is the layout. Of course the lack of ads on the mobile version, or if not the absolute lack at least the small number of appearing ads, seems to be quite pleasant.

The thing is that as the web grow and as the web 2.0 is becoming a reality most of us will prefer to use it on a mobile device, just because it’s

1. easier to use
2. easier to find
3. easier to follow

Here’s a nice example of what mobile phones are now.

Now lets take a look on how the mobile web will grow in the near future.

That graphics describe quite well what will happen in the upcoming years. Is there now a question: should I make a mobile version of my site?

PPK is right! Stop developing everything as a iPhone app. First that doesn’t work on any device except iPhone and it’s difficult to maintain. In reverse you should begin doing your mobile web site version. Hopefully with HTML5.

Do as Twitter did … or you’d be looking at http://m.digg.com – that’s the right way.

Now continuing from the JavaScript libraries post, let me ask you who’s your server side language of choice?

1. ASP
2. PHP
3. Python
4. Other

Please feel free to share your opinion!

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 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.