Websites built for the future

Matthias Reuter's picture

If you had the chance to build a website from scratch. A website that is going to be launched in the late summer of this year. And an old version of that website already exists, which will be maintained but not developed further...

How would you build the frontend?

I have given that some thought in the last time. And here are the three most important conclusions I came to:

  1. Use HTML5 excessively
  2. Style with CSS3
  3. Drop IE support

While the first two might seem obvious, the third sounds like madness. How can I seriously even think of excluding like fifty percent of the users (less in Europe, more in the US)? It's only logical (and I admit I'll cut that down a little later on). But let me explain the first two points first.

Use HTML5 excessively

HTML5 offeres a broad variety of new structural elements. And the basis for a good website is semantic markup. footer, header, nav, article, time and so on are HTML5's answers to a ton of divs that we used in old (and current) websites. But HTML5 is more, using the audio and video elements you can easily embed multimedia to your site. OK, video is still a mess if you don't want to double encode your content, but that might change in the near future, since Google announced to drop support for H.264 last week.

There are a lot more techniques that help building a light-weight application, part of which are associated with HTML5, but are not part of the specification. Offline-applications, drag and drop, the File-API, local storage, geolocation and more.

Example? Build a blog

If that application was a blog, then the elements article, header, footer and so on come in quite naturally. Using these results in clearly structured, semantic markup. Maybe sometimes I would want to blog about a video I made. Or a song I wrote. I could include these without any plugins and therefore would not need a flash-detection library either. And that would work without Javascript. So if my big paranoid brother, who generally disables Javascript and any plugin in his browser, would want to read my blog, fine. He would be able to view all content. Even if some geeky friend of mine would want to read my blog using lynx, fine too. He would not be able to view the video, but he could download it easily.

Using the application as the blog author would be heavily supported by these techniques. Want to post a video? Just drag and drop it into the browser (using the DnD- and File-API). Write while onboard a train? You'll notice no difference thanks to offline support and local storage.

Style with CSS3

This seems obvious as well. It means, if you want to have rounded corners, don't use a bunch of images, use border-radius. If you want semi-transparent background, don't use a png image, but use rgba colors. If you want animations, use transitions instead of bloaty Javascript code. If you want a shadowed box, don't use images, use box-shadow. You want to use your corporate identity font for headings? Do not use images, use @font-face. And most of all, if you want your application to fit in a mobile browser, use media-queries.

So using CSS3 drastically can decrease the number of files you need and therefore the improve the performance of your application.

There is one drawback, though. CSS3 support is not complete in most browsers. Opera for example does not have gradients. Firefox does not support transitions. That's partly because these specifications still are working drafts. But let's be honest. Does it really hurt, if Opera users have a single background color instead of a gradient? If Firefox users don't have an animated hover effect? Form follows function.

Drop IE support

If you have a look at what browsers support today, you can see that many, many features I would use already are supported in Opera, Chrome, Firefox and Safari. So if we dropped IE support, we could be using them today.

And if you then have a look at what will be, you can see that in mid/late 2011, when IE9 is released, most of the features are supported by all browsers. So I correct myself: Drop IE<9 support.

As I said it. If you build an application that will be launched in the second half of 2011, use HTML5, CSS3 and don't care about IEs.

But how long will it take users to adapt to IE9? My guess is, pretty quickly. Those using IE8 will switch quickly. Those using IE7 or - godforbid - IE6 will probably stick to it forever and eventually die out. You can still send them to the old version of your application (which is a prerequisite of IEs. If you don't have an old version you most likely cannot afford to drop IE support).

In the meantime build the next jQuery

What should be done in the meantime? How should we spend the time until IE9 is released? Build a new javascript library. Large part of current libraries are concerned with selecting dom elements, providing animations, offering functionality that already found its way into Ecmascript 5 (like JSON, Array extras and so on). Throw them away. Use querySelector/querySelectorAll instead of sizzle. Use CSS3 for animations. Ecmascript 5 is widely supported in many browsers today. Again, IE8 is far behind the others, but IE9 is the paragon for ES5 support. It even finally implements the Event model of W3C.

So spend the time building a library that adds the few missing functions. That works around the remaining browser bugs and inconsitencies. Build a library for the future.

A note at the end

When you use semantic markup, media queries and progressive enhancement for the advanced features (and do everything right), then you have a mobile web app almost for free. You don't have to build an extra app for iPhone, Android... Now wouldn't that be nice? Think of all the time (and money) you could save. So go ahead and start.

Comments

 Twitter Trackbacks for Websites built for the future | unit's picture

[...] Websites built for the future | united-coders.com united-coders.com/matthias-reuter/websites-built-for-the-future – view page – cached If you had the chance to build a website from scratch. A website that is going to be launched in the late summer of this year. And an old version of that website already exists, which will be maintained but not developed [...]