Unexpected Google queries

Yesterday I downloaded from Google a CSV file containing the top search queries for my main web site, starting from July 2009. If you have a Google account, I recommend you to do that because it's very important for having a clear idea about how users find your site. Further, these queries show also the frequency of keywords during a certain period of time. For example, in July I got many queries about specific topics related to web development (particularly to CSS) but later the frequency decreased significantly and, with a little surprise, also my page rank (one point).

This is probably due to the fact that I didn't update the contents of my site for several months. Google loves fresh content, so you should plan content updates on a regular basis. But the big surprise were... images! Many people stumbled on my site during their Google searches just by typing something like "skeleton face"! So here's another point to consider: always use the alt attribute for images and a proper file name (this should include some keywords related to your content), obviously when convenient. Google, as always, is a source of big surprises.

Firefox 3.6 source code: part 1

After receiving an email from Boris Zbarky where he said that some components of Gecko are no longer available (allowing me to correct some wrong ideas about Gecko), I decided to download the latest version of the source code to keep me up to date. You can find everything at ftp.mozilla.org (anonymous login). I've just finished to download it and, due to the enormous amount of files and libraries, I'll need a lot of spare time to look through it! Anyway, I'll let you know.

Obtrusive JavaScript

We all know what the expression unobtrusive JavaScript actually means, but it's not clear what obtrusive means.

Web developers usually think that separating markup from behavior is the only aspect to consider when dealing with a proper JavaScript coding. But there's another aspect that is often overlooked: accessibility.

Obtrusive JavaScript is writing our code disregarding the accessibility issues that may arise during the development process. In a nutshell, there are browsers that don't support JavaScript at all (such as Lynx, a textual browser). For example, if you create an Ajax feed reader on your pages by injecting the parsed XML file into the DOM, be aware of the fact that nothing will be rendered in a browser that doesn't support JavaScript.

You should always make sure that JavaScript is not used to handle information that are relevant for a proper understanding of your content or, even more important, that JavaScript is not used to create relevant content. In other words, you should use JavaScript only to manage accessory information.

Ask yourself this question: is this content or information necessary to understand or use my site? If not, you can use JavaScript for that purpose. Remember that accessibility is really important and can make our sites a better place for people with disabilities. And, of course, a better place for the whole web community.

Overuse of web fonts considered harmful

There's been a lot of talking on css-discuss and www-style about the newly supported CSS3 feature related to web fonts. Through the @font-face statement, now authors can insert and display uncommon types of fonts in their documents.

This means that all the CSS replacement techniques can be avoided by using this brand new technique. Despite the obvious enthusiasm for the adoption of a new feature, there's an issue that cannot be overlooked: if I can insert any type of fonts, what about the overall legibility of web documents?

In short, if accessibility really matters, we should avoid some types of fonts that, for example, are difficult to read for low-vision users or, alternatively, provide a different layout with more common font faces. I'm not saying that web fonts are evil, but that we should use them carefully, avoiding an overuse that might be harmful for users with disabilities. For example, we could use web fonts only on headings and not on the main text of our page, provided that the font of our choice is legible.

Supporting legacy browsers

I don't have access to the browser stats related to my web sites, so I have to get this kind of information from another source, such as search engine sites or page ranking services. The problem with these sites is that they provide only information about the number of visits within a given time range.

However, these sites also report the geographical area my visitors belong to, and I have to say that this kind of information is very useful. I've found out that the majority of my visitors come from Italy (about 60%), followed by a significant number of English and American users who share the remaining 40%. That's fine, but the underlying problem remains the same: I don't know what kind of browser they use.

Since my sites are about web standards, it's likely that my visitors may use a full standard compliant browser, such as Firefox, Safari or Opera. That's true if we consider my visitors only as colleagues, but it might be false if we take into account also clients. In fact, clients may surf the web with a legacy browser (Internet Explorer 6, or even worse) and when they find your site broken, they may think: "so you're a web developer, huh? Fix your own site first!".

In that vein, I followed a radical approach with CSS Zibaldone by keeping structure and layout as simple as possible. The result is practical but ugly: don't follow my example if you want to get some interesting jobs! So I decided to create a stronger structure and a finer layout for this web site. To accomplish this task, I wrote down a practical browser testing order, which includes:

  1. Firefox
  2. Internet Explorer (6, 7, 8)
  3. Others (Safari, Opera, Camino, etc.)

The order is relevant: when I test a site, first I view my results in Firefox, then in Internet Explorer and finally (only finally!) in Safari, Opera, Camino, etc. Supporting legacy browsers such as IE 6 means only one thing: testing, testing, testing!

As a rule of thumb, never trust the results achieved on your local machine, because IE behaves differently on a remote server (this is particularly true for Ajax and any XML-based language). And remember: test first, fix later.

Reusable CSS classes

Reusability is the key to keep our code organized and easy to maintain. When dealing with CSS class names, two are the points to keep in mind:

  1. semantics of class names
  2. cascade and specificity

Semantics of class names

You should avoid presentational class names, such as bold or red. Instead, use descriptive names that specify what is the purpose of a particular class, such as evident or highlight.

Cascade and specificity

Classes can be combined together to form cumulative styles. For example, suppose that you have the following class:

.highlight {
  background-color: #ffc;
  font-weight: bold;
}

Then you can specify another class in your stylesheet:

.note {
  background-image: url("note.png");
  background-repeat: no-repeat;
  height: 100%;  /* IE6/7 hasLayout */
  padding: 1.2em;
}

Finally, you can combine them in your markup:

<div class="note highlight">..</div>

The final result is an element whose styles are the sum of the rules specified in the two classes. Of course you can use a single class or both classes on different elements, because we didn't specify an element type on our class selectors. Only remember to avoid clashing style rules, because if you do so, then the rules for specificity will be applied.

XML: a misunderstood standard

More than five years ago, Mark Pilgrim wrote an interesting article about the problems encountered by XML during the first years of its life (the XML standard was first published in 1998). I have to say that Mark correctly pointed out that one of the main problems of XML is related to the fact that many developers simply ignore how this format should be served. However, this is not the only problem.

After five years, browsers have improved their XML support. All major browsers now understand XML and treat it properly. However, the problem doesn't lie in the implementation itself, but in how this implementation has been developed. Simply put, the implementation of Firefox, Safari, Opera and Chrome is very similar or, in other words, interoperable. Instead, Internet Explorer implements XML in its own, proprietary way. So web developers are forced to duplicate their code in order to make even a simplest XML document work on all browsers.

That's why many developers don't like XML and prefer alternative formats, like JSON. Because of the lack of interoperability, XML cannot fullfill its goal: a semantic, universal web. A couple of months ago I took a seminar at the SMAU in Milan. I spoke on the possibility of having our blogs entirely written in XML. I got no feedback, in the sense that nobody criticized or praised me for my ideas. They simply asked me: "Does this stuff work in IE?". Well, if you put this in these terms, you missed the point of XML, you missed the point of why I'm here today. Maybe this stuff is only a dream, but I like to stick to it. I understand and love the XML standard.

Browser discrepancies: when interoperability fails

There's nothing worse with the full adoption of a web standard than the lack of interoperability between applications. I'm currently developing a new web site, after finishing this, and I have to say that this site works even on Solaris with Firefox/Mozilla. But this is an exception.

The sad thruth about interoperability lies in the fact that this word doesn't necessarily mean "you have to implement a standard so that your implementation is fully compatible with other implementations". This is the current point of view of the W3C, not the point of view of some companies. Some browser vendors tend to implement a standard in a way that only some developers are able to follow, that is, only those developers who use and adopt their technologies.

For example, XML's implementation is currently interoperable between Firefox, Opera, Safari and Chrome. Internet Explorer, instead, decided to implement it through the MSXML library, that works together with Trident. By doing so, even XSLT, SVG, MathML are supported only if you install a special plugin that is able to connect itself to MSXML. The following tests of mine, XML and DOM tests and XML and CSS test, show clearly what I mean: the overwhelming majority of them fails spectacularly in IE.

We need to wait. I think that only time will tell if the word interoperability lies in a vacuum or is something more.