The U.S. has granted a patent (via) to a design company, Balthaser Online, for Rich Internet Applications, including AJAX, Flash and Java.

Reading the abstract in the actual patent closely, it seems to me they've only patented the creation of rich applications from over the Internet. Their main product, Balthaser:fx, is used to create Flash movies over the web. This seems to fit my interpretation. However, the news article I linked to suggests the patent might include all rich internet applications.

What does this mean for the web? Who knows. It'll be up to this company, and the U.S. courts, to decide what this patent includes and doesn't. Nonetheless, I think this is another great example of why software patents are total bullshit.

That's right, Google's Toolbar PageRank seems to be updating today. It seems really uneven though. Some pages are updated, others aren't. Perhaps it'll take some time to finish updating. Currently this site is still sitting at a PR2. Let's see what happens by the end. :)

By the way, you can see the different PageRank values with this Live PageRank tool. It'll give you an idea of how your pages are doing across different data centres, and compare Toolbar PageRank to "Live" PageRank. Good luck!

Update: Live PageRank is now a thing of the past. It is reporting 0 for every domain, and Matt Cutts doubts this will ever change. Well it was fun while it lasted.

Semantic HTML means using HTML tags for their implied meaning, rather than just using (meaningless) div and span tags for absolutely everything. Why would you want to do this? Depending on the tag, the content in the tag can be interpreted in a certain way. Here are some examples.

Header tags

If you use <h1> instead of <div class="header">, and <h2> instead of <div class="subheader">, et cetera, Google and other search engines will interpret your headers as being important titles in your page. This way, when people search on the words in your headers and sub-headers, your page will be considered more relevant (and rank higher). Plus, it's much shorter and cleaner.

This works both ways: don't use header tags for anything except headers, especially not increasing your font size or outlining your search engine keywords. This way, your page can be parsed for structure (you can do this with the W3C HTML Validator). This structure can then be used by screen readers or other tools to build a table of contents for your page.

Form labels

The <label> tag is so sadly forgotten. It's not immediately clear what the point of using it is, so very few web pages take advantage of it. The label tag is used to identify a label for an input field, for example "E-mail Address". It can either be used be wrapping it around the text and input field like: <label>First Name: <input name="fname"/></label>, or it can be used with the for attribute like so: <label for="fname">First Name:</label> <input id="fname" name="fname"/>.

Why use the label tag instead of <div class="label">? Well, it's shorter and cleaner. But it also let's screen readers and other tools identify the text associated with an input field. Without using the label tag, it can be very difficult for some people to know what is supposed to go into your form fields.

Tables

These days, everyone's moving away from using tables. This is great because tables aren't intended for structuring the way your web page looks. But tables still have a very important purpose. Any time you need to display data that would go in a spreadsheet, tables are here to help.

When using tables, there are a number of tags and attributes that aren't widely used, but are very important for accessibility. Use the summary attribute to give a longer summary of the data in the table. Use the <caption> tag to give a brief title to the data. Use <th> tags to identify the column and row headers in your table. Then, you may want to use the headers attribute on the <td> tags to identify which headers apply to that cell. For more examples and details on accessibility with tables, see the W3C's Accessibility Guidelines.

Lists

Lists are the new tables. Whereas tables are intended for grids of data, lists are intended for lists of content. This is great for us, because most web pages are essentially lists of different things. For example, look at this site. On the front page, I have a list of blog entries in the centre. On the sides, I have lists of links (archive, categories, et cetera), and the sides themselves are lists of lists. If I had used tables, I would've been saying "this stuff on the left has something to do with the stuff in the middle", but it doesn't, really. By using lists, I'm simply saying "this stuff is a list of items that have something to do with each other", which they do.

You have three types of lists to choose from, but choose wisely. There are Ordered Lists (<ol>), Unordered Lists (<ul>), and Definition Lists (<dl>). Only use Ordered Lists when the entries have some kind of order. Only use Definition Lists for definitions (eg. for a glossary). Use Definition Lists any time you need name/value pairs, or when you need to break your list up into sections. The rest of the time, Unordered Lists are a safe bet.

Lists not only give structure to your page, they're incredible handy for styling. You can just put an id or class on the outer tag (eg. <ul>), then style both the outer tag, and the inner <li> tags.

Conclusion

Try to use the full variety of HTML tags whenever possible. Sometimes you'll be stuck with using <div> tags, but try to limit them to whenever you can't find a suitable HTML equivalent. At the same time, try to avoid using HTML tags for anything except their intended purpose. By doing this, your HTML will be cleaner, and its structure will be more readable and understandable -- not just to people but to screen readers, search engines, and other programs and tools.

As I've said before, and I'll say again, the last thing the web needs is Buzzword Hell. All buzzwords do is distract from the real tangible ways we can improve the web. So now, I introduce a way you can help save the world from Web 2.0 buzzwords!

Buzzword Hellfire

I just had a look at the WayBack machine for thefutureoftheweb.com. Turns out someone else had it before. Creepy.

Have you ever wanted to prevent a JavaScript event from firing when it has been bubbled up from a child element? For example, let's say you have an onMouseOver event for a parent element. Anytime the mouse moves over any of the children elements, the parent's onMouseOver event will keep firing. Or, let's say you have an onMouseDown event on a parent and another on its child. Both onMouseDown events will fire when someone clicks the child. Sometimes this can be a real pain.

Anyway, enough examples, let's look at a way to avoid this. We need a way to fire an event only when the element with the event handler is the target element of the event. Here's the solution event handler:

function eventHandler(e) {
     e = e || window.event;
     var target = e.srcElement || e.target;
     if (target != this) return;
     
     // the rest of the function
}

Simple enough, once we have the code. Let's look at what it does.

First, we find the event object. In Firefox and Safari, it's a parameter to the function. In Internet Explorer, it's in window.event.

Having that, we need to find the target in the event object. This is the first element the event fires on, the inner-most or top-most element. In Safari and Firefox, it's target, but in Internet Explorer it's srcElement.

Finally, we will compare against the element the event is attached to. The element the event handler is attached to can be accessed easily with the this variable.

For more information on event handlers, I highly recommend the excellent resources at QuirksMode:

• Events order (event bubbling vs. capturing)
• Event Properties
• Event compatibility tables

Update: you need to do a little bit more if you are dealing with mouseout events. If you move the mouse into a child, this triggers the mouseout event on the parent. In this case, the target will match the parent. So, you'll also have to get the 'related' element (the child) and make sure the target isn't one of the ancestors. Here is the updated function for mouseout events:

function mouseOutEventHandler(e) {
     e = e || window.event;
     var target = e.srcElement || e.target;
     if (target != this) return;

     var related = e.relatedTarget || e.toElement;
     while (related != this && related.nodeName != 'BODY')
          related = related.parentNode;
     if (related == this) return;
   
     // the rest of the function
}

Special thanks to QuirksMode's Mouse Events page for helping me figure out that one!

I know, this question has been answered thousands of times. Even still, nobody can agree on what it is exactly. Here's my take.

Web 2.0 obviously implies the "next version" of the web. Ask Tim O'Reilly (who coined the term to promote a conference), and he won't really be able to summarize it either. He'd rather define it by example. DoubleClick is Web 1.0, Google Adsense is Web 2.0. Personal websites are Web 1.0, blogs are Web 2.0. Content Management Systems were Web 1.0, wikis are Web 2.0.

Web 2.0 is said to include everything from tagging, Ruby on Rails, AJAX, peer-to-peer, RSS, the perpetual Beta, and user-contributed data. Let me propose this: Web 2.0 includes anything that was done successfully on the web in 2005. There, I've said it. Now, I'd like to propose something else: Let's focus on the different ways the web has improved, and let's never use the term Web 2.0 again. Seriously, starting right now. Who's with me?

Having said all this, the many different definitions can finally be read without that nauseous feeling. Don't worry any longer that your website is running the wrong version of the Internet, just relax and take a look at how far we've come. It's not worth much to say "This website follows the new trends in web sites, this one doesn't". There's certainly no need to start a new industry over it. Instead, let's just see what works and what doesn't.

If we spend all our time defining such a vague marketing term, we're going to severely miss the point. There is no Web 3.0, and there needn't be a Bubble 2.0. We have a lot of really great examples to follow, and there's still a lot that hasn't been done. So let's just keep doing what we do best.

So let's see what we can do with Folksonomies, let's find things every web site can learn from blogs, and let's see what new directions we can go in in the future of the web.

Over the last few posts, I've been trying to redefine "Web Standards", or rather, expand the definition to include things outside the validation of HTML and CSS. I wanted to talk about the larger picture of doing things the Right Way. Then, Jim left this comment:

I have to admit, he's absolutely right. "Web Standards" refer to the actual specifications for web technologies, notably HTML and CSS. Indeed, the Web Standards Project are only advocating adherance to the W3C Standards for XHTML, XML, CSS, etc.

I asked Jim for a better term, and citing this blog post he suggested "Best Practices". This really expresses the intention here, that we should be doing things a certain way because it's the best way.

I've been thinking about this a lot since, and went back to Molly's infamous post where she coined the term "New Web Professionalism" to describe this Right Way Of Doing Things. This is just expressing the same concept in different words, and it's never the words that matter. It's what the words represent. As an industry, we need to encourage a certain level of quality, a certain, shall we say, standard.

So, Web Development Best Practices? Web Professionalism? Web Professional Standards? I hate buzzwords as much as anyone, but it seems like we need one here, some piece of jargon that lets everyone else understand what it is we're talking about. Don't we?

Then again, a buzzword is the last thing we need here. It would only distract from the underlying point. We can still refer to Accessibility, Web Standards (that is, valid HTML and CSS), Semantic Markup and Unobtrusive Javascript. And by doing so, we won't forget what it is we're talking about. We won't end up with some empty marketing speak promising something as vague as "Best Practices" when they have completely ignored Accessibility.

I won't go so far to rename my last posts, but for now on I will be much more clear when I talk about these and other Best Practices, and will forever hestitate to throw around the term Web Standards to mean anything except valid code (which, to be honest, is the least interesting topic amongst Best Practices).

Right now, A List Apart is asking its readers what they love or hate about the web. I just sent off mine, but I thought I'd put it here so it doesn't go to waste if they don't include it in their next issue:

What do I love about the web? Anybody can have a voice. It just takes one person with something to say to make a huge difference. The whole world is having a discussion at a round table. Everybody is an expert. Education, social status, location, race, gender, etcetera are completely irrelevant. All that matters are thoughts and ideas.

Not merely an ideological utopian vision, we are already living this reality. Blogs are not simply a new trend in marketing and journalism, but the beginning of a fundamental shift in the way the world interacts. We, the people, run the world. We are growing less reliant on government and big business to get things done and are doing things ourselves. Together, we can do anything, and nobody can stop us.

If you want to submit yours, they say:

Update: Indeed, mine was included. I even got to have little AJAX and DOM sweethearts beside mine :)

Why do web standards matter? It's easy to say that web developers who ignore standards are unprofessional, but it's not so easy to explain why.

(If you haven't yet, read my last post to see what I mean by 'web standards'.)

Web standards are fun, cool, exciting. Right? This might be reason enough to use them on your own web sites, but you won't be able to convince your clients to use them just because they're cool (that is, unless your clients really wants to impress their web developer friends).

What do your clients care about? Visitors, of course. The people actually using the web site. If they don't notice a difference, what's the point, really? Sure, your visitors might judge your web site with the W3C Validator, but face it, only other web developers are ever going to view source. On this web site, my visitors ARE web developers. But what about the 300 billion other web sites?

Now, hold on a sec, I didn't just say we should go back to designing with nested tables and invisible GIFs! I'm just saying we need to focus on the goal here: benefiting our visitors. So how do web standards benefit our visitors?

1. Faster web pages.

   The site will download faster because the HTML will be smaller. If there is a single external CSS file for the entire web site, visitors can download it once and cache it, making the whole site download faster. Also, browsers can draw borders and background colours using CSS a lot faster than downloading border and background images.

2. Usable by more visitors.

   If you've separated design from content, users without CSS can still get the content and use the website. If you've separated the site's behaviour from the content, users without JavaScript will still be able to use the site without a problem. If you addressed accessibility, you allow visitors with disabilities to access the site. The last thing we want to do is turn visitors away just because of how they choose to surf the web.

3. Search Engine Optimization.

   How can people benefit from your web site if they can't even find it? (That is, unless your web site doesn't benefit them at all, in which case web standards aren't going to make any difference.) The search engines don't award points for design. All the extra tags and attributes will just distract away from the content. Using text instead of images and using semantic HTML (especially h1 tags) lets the search engines better index the content and interpret the structure, and this will help the page rank higher in search results.

These should be reasons enough to stick with web standards when creating web sites, and certainly enough to convince sceptical clients that web standards are the best choice. Next, I'll list some ways using web standards benefit web designers and developers.

Update: When I say 'web standards', I really mean 'Best Practices'. Read more here.