I started with this article about the decade that was in web design. (Note: an earlier version of this was done here.) It was not much more than a before and after look at the most popular websites out there. Of course, ten years is a long time in web design so the showcase is a satisfactory way to see how far we’ve come, but not quite enough. There was no discussion on the notable features from the different websites. We don’t redesign sites just because we want a different look, do we? We want them to improve. Answering how those sites improved over the years would be a worthy reference for all the web designers out there. This other one almost nails it, though it focuses on the business of these companies, not web design itself.
I hope the likes of Smashing Magazine or some fabulous curator of web design history would come up with an in-depth study illustrating how web design has evolved over the last ten years. Timelines like this and this could help with that, but still needs mention of developments like:
- the downfall of
<table> layouts in favor of semantic markup
- CSS sprites
- the growth of web typography, from sIFR to
@font-face
- Art Direction in web design
- mobile web design
- the HTML 5 Superfriends
- which website or company popularized which design pattern, from the glossy, candy-colored “Web 2.0 look” to the sleeker, more dramatic “Apple look” (though something tells me Apple is responsible for both)
Here’s another approach to the timeline, and is more of a Q&A over the years, and anybody can ask and answer. It also hasn’t been updated since ‘04, as it was part of the 2005 conference, A Decade of Web Design. Jakob Nielsen also did a backtrack that same year.
I’d also like to look forward. This prediction post is quite adequate (with pictures it would be perfect). I think this passage sums up what’s happened in the past decade and what will happen in the next:
While most these technological improvements tend to make the web a more and more homogenous place, at the same time, there is a tendency to create highly curated design setups that use different designs for each article.
There will always be a dichotomy between standardization and specialization on the Web but it’s only lately that we’ve been able to do so with less crap, more elegance. And I can’t wait to see how doing those two things evolve into even more exciting things in 2010 and beyond.
Need more crystal balls and time capsules? See also:
And by jQuery-esque I mean easy! The premise of Jetpack, Mozilla Labs’s latest creation, is that anybody who knows HTML, CSS and JavaScript can create Firefox add-ons.
It takes 80 lines of code to block ads on websites as shown in the demo above, and 14 lines to edit images from within Firefox. Granted, it just sends the data to Pixlr which does all the hard work, but lowering the obstacles to develop some fairly nifty scripts is a commendable effort, just as what jQuery did with JavaScript, Sass with CSS, and HAML with HTML. It’s made even more compelling with Bespin, Mozilla’s HTML5-powered web-based code editor.
Perhaps I’m still in a “standardize everything” mood, or envy this new doodad since I’m now using Chrome as my default browser, but don’t you sometimes wish all browsers could do this? Do the same set of things? We’re getting to a point where the level of HTML and CSS support is the same across every browser, so it makes me wonder what’s the next step for the idea of cross-browser compatibility.
It will probably depend on what the web browser means to its various makers. Google has unveiled the Chrome OS, which will run on a specialized version of Chrome. Opera is focused on its “web servers for everyone” feature in Opera Unite. (And Internet Explorer is playing catch-up, mostly.) Browsers are basically the gateways to the whole Internet, but they’ve become more ambitious than that and their vendors will attend to those ventures first before convening to create new cross-platform goodness.
Harry Roberts a.k.a. CSS Wizardry tweeted a certain tutorial by CSS Aid (page is dead now), which was enclosed with four little words (“Good lord, wrong much?”) that echoed such alarming levels of horror and shock (considering he tweets about poor examples of HTML/CSS code everyday), that I had to check it out.
First, the tutorial was entitled “Tables Without Tables”. If that doesn’t trigger warning bells in your head, then consider the opening paragraph:
It’s the year 2009, CSS rendering has vastly improved from when it was released, so there is no reason for any website to use tables as layouts. Although you can ditch the table tag when it comes to layouts, you may someday need to use it for what it was made for…or do you? I am going to show you an easy way to make a table with a simple unordered list.
No. Just no. Yes, <table>-based layouts are considered wrong because HTML is supposed to properly represent data. Lists should be lists. Tables should be tables. Layouts that look like tables (grids) can be done in CSS. That’s semantics, the core principle of web standards.
But avoiding the use of <table>s at all costs is no better. Perhaps it’s even worse, since it demonstrates not only ignorance but false expertise, feigning arrogance over an HTML element that has been shuddered at because of its misuse and abuse.
The page has gone down in between the time that I read the tweet and wrote this post. Fortunately the forum thread that seems to be the source of the link is still up, and shows us the author’s reasoning for writing the tutorial. Take post #7:
Because I hate the <table> tag
Is this the extreme dark side of web standards, where we’ve been conditioned to hate <table>s so much that we can’t even think to use them for what they were meant for anymore? A sad, sad turn for us all.
By post #15 he’s already backed down and promises not to use the experiment for real-life cases, but this summarizes things nicely:
It’s a pointless experiment though. It’d be like experimenting making a house out of tampons. Doable but just plain wrong.
It’s bad enough that we have to deal with preaching proper web standards, dropping crusty old browsers from, and adding newfangled technologies to our web design arsenal. Let’s not get sidetracked by punishing HTML elements by twising them into things they weren’t meant to be.
Although we’re now in this transitional stage of shedding off old browsers and web technologies that have been stumbling blocks to creating innovative new websites, there’s still confusion and fear that needs to be quelled. (Some people just can’t get excited that easily.)
Jeremy Keith’s article, Misunderstanding markup, seems like the ideal anchor at this point. First, it points out the differences between XHTML 1.0, XHTML 1.1, and XHTML 2:
- XHTML 1.0 = HTML4 with XHTML syntax
- XHTML 1.1 = XHTML 1.0 with the requirement that documents should be served with the XML MIME type
- XHTML 2 = a whole new specification that has little in common with XHTML 1.0/1.1/HTML 4
- XHTML has two types: pages that are actually served using the
application/xhtml+xml MIME type; and pages that are actually served using the text/html MIME type but follow XHTML syntax.
Confusion? Fixed.
Second and more importantly, it emphasizes what the triumph of HTML5 means for XHTML:
- You can still use XHTML syntax on HTML5 documents; it’s flexible enough and backwards-compatible (unlike XHTML2) that way. You can also go back to old coding conventions like uppercase tag names, optional quoting of attributes, and the absence of trailing slashes, and that’s okay too.
- In fact, you can serve HTML5 documents as
application/xhtml+xml and you get an XHTML document, affectionately called XHTML5. At this point, only XHTML2 is dead.
- Still scared about taking the plunge to HTML5? It’s as easy as replacing that long-winded strict, transitional, or (gasp) frameset DOCTYPE declaration to
<!DOCTYPE html>.
Once you learn items 1 and 2, the third item is all you’ll need to focus on from now on. It’s a comforting message that if you think catching up to HTML5 will be difficult, rest assured that it’s not as scary as it looks.
Fear? Fixed.
Let’s move on, shall we?
In yet another interesting turn of events, two of the biggest issues when it comes to web design and development make way for the newer, better versions of themselves.
Goodbye, IE6!
Asa Dotzler of Mozilla reports that IE6 usage has now been overtaken by IE8, based on the browser tracking data from Net Applications. This happened as recently as June 2009.
Of course, specific demographics on your respective websites will vary, but this trend is a sign of things to come. And we’re not talking about years anymore, but months.
I’d have to commend Internet Explorer team on their great marketing efforts to improve the IE8 adoption rate. Even if Microsoft’s latest browser is up to snuff compared to the likes of Firefox, WebKit (Safari/Chrome), and Opera—see these comparison charts for HTML5—it’s a big step.
This is it, guys. Freedom.
Goodbye, XHTML2!
Slashdot reports that the XHTML2 Working Group charter is expiring by the end of 2009, and it will not be renewed. The W3C has also decided to pour more resources into the HTML5 working group.
Those who weren’t paying attention to this seeming sibling rivalry between XHTML2 and HTML5 can now rest easy. Though I’m not sure if XHTML2 ever stood a chance given how all the web gurus were backing HTML5 as early as last year. Google is on board, too. And everybody else is starting cash in on its growing popularity.
The good thing about XTHML was that it enforced well-formed markup, with strict provisions for lowercase code, quoted attributes, and trailing slashes for empty elements. Thankfully HTML5 this coding convention too, and can be served as a serialized XML document dubbed XHTML5.
At least we wouldn’t be forced to choose between the two anymore. Competition is good, but not here. We need standards.
Unwanted competition eliminated
How convenient is it that we have two less things to worry about now? Very, but now that they’re gone, it’s time to make up for lost time:
- Microformats. (This is the easiest to jump into.)
- Fluid layouts.
@font-face and custom web fonts: this time it’s not just the browser makers that web designers and developers are up against, but the type foundries. TypeKit and Kernest are attempting to bridge that gap.- CSS nested declarations, variables, and operations: LESS
- CSS if statements: Modernizr
- Animated PNGs.
Exciting times, people!
It’s April 9th somewhere around the world and that means it’s time for the annual CSS Naked Day. Just how elegant and semantic is your website’s markup? Stripping out your stylesheets will determine that. Good houses must have good foundations, and so must good sites.
The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of (x)html, semantic markup, a good hierarchy structure, and of course, a good ‘ol play on words. It’s time to show off your <body>.
As an aside, I like that this ‘Day’ is arbitrarily stretched out to 48 hours instead of the usual 24 to accommodate locations all over the globe. I think more worldwide events and holidays should be more timezone-neutral.
We need more standards-focused advocacies like Blue Beanie Day, the countless kill IE6 websites, and this.
The Web Standards Project (WaSP) has just announced that members of the Internet Information Security Consortium (I2SecC) have discovered the real purpose of the infamous Conficker Worm, set to wreak havoc on millions of compromised systems on April 1st.
WaSP has also discovered that the best way to fight this malware is to ensure your websites are standards-compliant:
In order to ensure you do not fall victim to the worm’s botnet, I2SecC recommends immediate validation of the markup and supporting stylesheets for any Web site that you maintain and correcting any errors that are uncovered. As yet, it is unclear whether the worm will target sites that make use of non-standard DOM scripting; however, a message found by I2SecC researchers in an online forum believed to be from the worm’s creator or a close associate hints that it will: “your document.all are belong to us.”
April Fool’s! If only we could save the world from malware with web standards!
Conficker is very real, however, so please exercise caution today.
I know rattling off websites in blog posts are a dime a dozen these days and may not be your cup of tea. But you might want to read and bookmark these sites—you’ll definitely keep coming back to them.
It’s a very short list, so you won’t tire easily reading this, and the sites are more like Position is Everything than Smashing Magazine. (No offense intended; I know that SM does a wide variety of blog posts, not just lists and freebies. I just mean they’re more references than resources, okay?)
Web Design+
Web Design+ contains the solutions to common web standards problems. From choosing a DOCTYPE to implementing CSS hacks, this is a great one-stop-shop for the best practices in web design out there. There are a ton of HTML and CSS cheatsheets out there, but reading them shouldn’t stop there. Refine your markup and stylesheets with the help of this site, free!
When Can I Use…
When can I use… compares support for several web design features according to browser version, from HTML to CSS to SVG to other technologies.
For example: thinking of using CSS3’s rounded corners (border-radius)? It’s not even available on IE8 and Opera 10 yet. Of course, you don’t have to avoid using them just because the conclusion says “not ready”. It’s still a very useful page for recalling which browser version can support what.
On Having Layout
On having layout demystifies the concept of Internet Explorer’s hasLayout property. A lot of the IE-related CSS problems that web designers run into are related to hasLayout, so understanding how it works is essential.
The Ultimate Website Launch Checklist
The Ultimate Website Launch Checklist helps one go over key aspects of a website once it goes live. It’s more for the designer-webmaster hybrid, but regardless of your role in the process it’s a good view of what needs to be done.
Eric Meyer has started poring over the WaSP community’s suggestions for CSS3 with a series of posts on his weblog—3 so far in less than a week. The original feedback compiled by Fantasai is a monstrous read in itself, but all these are worth perusing if you care remotely about the future of web design.
It’s comforting to have one of the gurus like him to really go over this. Although he didn’t promise to address every single point on the list, what I’m seeing so far is extremely comprehensive. More importantly, we have a strong figurehead that’s rolling up his sleeves and setting up these blog posts as the stage for discussion with people who are not necessarily involved with the W3C and other stakeholders like the browser vendors.
Between debating over specific CSS features (e.g., containing floats, center positioning, selector blocks) and looking at the bigger picture…
Maybe CSS isn’t the place for this. Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility. Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.
I don’t have a concrete idea to propose here, because it’s not up to us any more. A solution was worked out over the course of several years and then found wanting by the implementors. Really, it’s up to the implementors to figure it out now. I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest. I might even supply food and water.
…we have to keep talking and stay restless but hopeful. We may not be able to give the final word on the next version of HTML and CSS and the web browsers, but we can talk about what could go into them while the W3C listens.
IE6 is declining. HTML5 is gaining traction. JavaScript libraries and CSS frameworks abstract the process of squashing browser bugs and incompatibilities. And progressive enhancement reassures us that we don’t have to serve up exactly the same features in ancient browsers.
And maybe we can stop acting like the current technologies are our handicap and take the plunge. Okay, maybe splashing water all over might not be a good idea at once. Try dipping your toes. Try your left leg. Try wading. The key is to at least try.
Make love, not war.
Round one: logo vs. title inside <h1>
I like that The h1 Debate was created to tackle a very specific issue in HTML that affects standardistas and search marketers alike. It asks the question what should go inside an <h1> tag, a logo or page name?, then you cast a vote by tweeting.
I expect lot more discussion than that, though; a poll is not enough. How about answering this question: should the <h1> tag appear exactly once on a webpage? For the record, Molly Holzschlag disagrees:
@fineartdavid it is SEO folks who IMO started the “only 1 h1″. I see cases of multiple h1 use such as in projection media: h1=slide header 1
That’s comforting for me to hear, but it might not be for you. But don’t take it as gospel—unless you consider Molly as god! If you’re an SEO guy and have some other god, then by all means.
Round two: generic vs. semantic CSS classes
If you squint long enough, you'll see a dog. And a rabbit.
The h1 Debate reminds me of a recent post at Devlounge that condemns generic CSS classes. Sure, separation of content and presentation is supposed to make webpages more efficient and future-proof, but if you avoid using unsemantic names like “left”, “right”, “center” and end up with convoluted markup, are you really writing sensible HTML? You have a choice between being purist and being practical. As Simon Collinson says:
Leaving the h1 debate now. I do it my way for reasons I believe are common sense. The day there is one way to build websites I will quit.
Which one are you?
Round three: CSS vs. tables (again?)
This is exactly what iamelgringo is talking about.
And for the nth time this millennium, it’s CSS vs. tables all over again. Apparently the case against tables is not strong enough…
CSS is really cool. It is useful for a lot of things. The basic idea of separating content from presentation is sound. But when it comes to layout, the design of CSS is fundamentally flawed. Use tables instead.
…or maybe too strong:
So I don’t ever want to read how web designers who don’t use pure CSS in their layouts are lazy, stupid, don’t care about their craft, backwards or don’t bathe properly. Never again. People who post such things online are heretofore to be known as CSS Trolls and are to be banished from the internets for all time. Begone yea vile fiends!
I completely agree with Simon in that there is not one way to build websites. That’s the beauty of it. Now I won’t go so far as say that we should all go back to tables. I’m somewhat disappointed it’s still an issue but I understand where these people are coming from. Ron Garret is giving up, but iamelgringo is not, and is only pointing out that (1) the biggest websites out there still use tables and (2) the purists (“trolls”) give CSS a bad rap.
Now I won’t be swayed by the source code on Google.com as I don’t think it matters. Does it matter to you?
The winners? It’s your call
What are your priorities? Web standards? SEO? Efficiency? A clear conscience? Sanity? You don’t have to be a purist or a pragmatist all the time, and shifting gears on each project doesn’t mean a sellout either. List those down and rank them based on your needs and your client’s. Then code accordingly.
