<div style="width: 800px; margin: 1em auto; font: bold 1em/1.2 Verdana, Arial, Helvetica, sans-serif">
<div style="float: left; width: 400px; padding: 1em 2em; font-size: 0.9em">
<span id="get-shit" onclick="callSomeFunction()">News</span>
What is so bad with it?
Except for not being very pretty code, and hard to get a good overview of it, there are some real disadvantages to this:
- HTML file size
- Your HTML code will weigh more, i.e. a web page riddled with similar code will have a KB size that is a lot larger than necessary.
- Lack of caching
- Poor accessibility
example, it’s applied to an element which doesn’t have any built-in
fallback interaction handler (i.e., like a link takes you to the URL specified in its
- Difficult code maintenance
- When it comes to making changes to the code, I’m sure every web developer would agree on that having code in just one centralized location is a lot more preferable than changing exactly the same kind of code snippets spread all over the files in the web site. Maintaining similar code to the above for an entire web site would be hell.
- Company proxy servers filtering out code (for example, read An important lesson learned about AJAX and accessibility).
How you should develop
The only acceptable dependencies are through
Taking the above bad example code, let’s rewrite it properly:
A bit nicer, isn’t it?
When to use
id and when to use
Basically, it’s very simple. An
id is unique for a web page, i.e. it should only appear once. The
class attribute, on the other hand, can be in a document as many times as desired. My rule of thumb is that normally I use the
id attribute for larger blocks in a web page, like site container, navigation, main content etc. Otherwise, I always use the
The code in the example is the old DOM Level 1 way of applying events to an element. It works fine for one event per element, but not if you have multiple events you want to apply, or the risk that someone else’s code will overwrite your event (or vice versa).
But what about major players, like Google?
So, by now you have hopefully agreed with all my arguments and is ready to take a plunge into the brave new interface developing world. But, just out of curiosity, you take a look at the most popular web site in the world, Google, and think:
Wait just a minute now! Robert is having me on.
In August a couple of years ago, my friend Roger rewrote the Google code with real proper code, and he goes more into detail explaining what he did in his post.
At the end, though, we need to consider the ridiculously high amount of visitors Google get every day, and for them it’s all about performance, performance, performance (for anyone interested in delving deeper into that, please read Improve your web site performance - tips & tricks to get a good YSlow rating). For them, cutting down any HTTP request is crucial, although that’s no excuse for not having valid code.
The most sensible option for Google would be to have one
style block located at the top of their HTML code, and one
class attributes to connect that code to.
In the end, though, I really think that the benefit of having the code whatsoever anywhere in the HTML code is negligible, and besides, as soon as we’re talking about returning visitors (for instance, I visit Google each and every day), having external includes would be more beneficial and vastly better for performance as well as bandwidth usage. Also, in comparison, the Google Mobile page is in a much better state, so having the regular one being so poor does really have any valid motivation - I think it’s more of a left behind that hasn’t been seen to properly yet (they’re probably terrified of changing it).