Spring Intern | January 5, 2009

Clearleft is looking for a keen intern to join our team for 10 weeks this spring. We’re looking for somebody with a real interest in front end development. Somebody who is passionate about the quality of their code and willing to go that extra mile to see it implemented correctly. You’ll be the type of person who reads all the blogs, subscribes to all the Twitter feeds and owns at least a couple of our books :-)

This is a hands on position so you’ll need to be willing to roll up your sleeves and get stuck in. We’ll be buddying you up with our superstar programmers, so you’ll get chance to pair program with Natalie Downe and argue semantics with Jeremy Keith. It won’t be a cakewalk either, so expect to have everything you know about web standards challenged.

After 10 weeks of working on real world projects with some of the best front end developers in the industry, you’ll have developed a level of HTML, CSS and Javascript knowledge that would normally take years to accrue. So this is an excellent opportunity for all those web standards enthusiasts and budding front end developers out there.

If you’re interested in the internship yourself, or know somebody who would be, here’s the official job spec.

Comments (8)

Has Internet Explorer Just Shot Itself in the Foot? | January 22, 2008

If you haven’t read the latest posts on A List Apart, you should pop over now. Don’t worry. I’ll be here when you get back.

Oh hello! So what did you think then? If you’re anything like me your first reaction was probably a mixture of intrigue, confusion and disbelief, followed by an expletive along the lines of “what the f#@k”!

To quickly summarise, the Internet Explorer team have floated the idea of setting a meta tag in your document to defines what version of their browser your site has been designed for. The logic is somewhat similar to the current process of DOCTYPE switching, but with more granular control. So if you’re worried that your site may break on IE8, you can add the following line of code at the top of your document, freezing it to IE7 style rendering.

<meta http-equiv="X-UA-Compatible" content="IE=8" />

I’m not exactly sure how the browser plans to implement this, but I imagine it would involve multiple rendering engines or a really complicated set of rules and exceptions. This seems like extra work for the IE team, but it’s an interesting idea.

This idea has come about because Microsoft are worried about “breaking the web”. Essentially they’re concerned that new browsers will stop rendering older pages correctly, annoying site owners, browser users and—probably more importantly for Microsoft—corporate customers. If we look at the bigger picture, this logic does make a certain amount of sense. If I, as a regular Joe user, download the latest version of IE, I expect it to do etter job at displaying websites. I don’t expect my favourite Geocities page to suddenly break.

Backwards compatibility is a legitimate concern, and one that keeps cropping up in the discussions over HTML5. After all, we do risk losing some of our digital heritage. However this issue obviously needs to be put in perspective. By constantly worrying about the past we risk missing out on the possibilities of the future. Imagine if all new media players had to be backward compatible? We’d end up with a device that could play anything from 8mm film right the way through to Blu-ray disks. It would be nice, but incredibly bloaty. Eventually we’d start dropping support for old media, or just stop inventing new ones.

But I digress. As developers what we want is the ability innovate and use new tools to create better experiences. One of the great things about CSS is the way it allows us to use the concepts of progressive enhancement or graceful degradation to seamlessly supply different experiences to different browsers. This forward compatibility is one of the fundamental tenants of the web standards movement, so if something comes about to threaten that, it’s understandable the developers would react badly. Browser targeting appears, on the surface at least, to threaten this, so developers are understandably a little miffed.

Now the main problem isn’t with the concept itself. After all, if developers want to freeze their site at IE7, that’s all fine and dandy. The problem is the default behaviour. Logic would suggest that unless a developer actively chooses to freeze their browser version, the browser should go on rendering a page in the fail-tolerent way they always have. If a site then breaks—usually because of browser specific coding—the developer can add in a single line of HTML in order to fix the problem.

Unfortunately the default behaviour doesn’t currently work this way. Unless you explicitly set a version number or use the “edge” keyword to target the latest version, the browser will automatically render in IE7 mode. My esteemed colleague Jeremy Keith, puts it thus.

“Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.

When you put it that way, it does sound kinda nuts. No matter what future version of IE you’re using—be that IE8 or IE80—if the developer hasn’t added the appropriate meta tag, you’ll be viewing the site as if in IE7.

While I disagree with this default behaviour, I do sort of understand where it comes from. It’s all to do with fail-safes and perspective. From a developer perspective, unless I’ve asked my browser to behave differently, the fail-safe should always be to act in the most open, modern and standards compliant fashion possible. However from the average users perspective, the browser should always attempt not to break stuff that used to work just fine. This forms a bit of an impasse and it the crux of the problem.

The big irony is that, by doing this, Microsoft have set up the ideal conditions to marginalise their own browser. Clueless developers won’t know about this behaviour so every new site they build will automatically be rendered as IE7. Clued-up developers will use this as an excuse to freeze support for IE and turn their attentions to better browsers. Users will see less benefit from upgrading and will be more likely to turn to other browsers. In fact the only people to benefit are the small minority of web standards developers who use Internet Explorer as their primary browsers.

No matter what great leaps forward the Internet Explorer team make from now on, the majority of developers won’t use them and the majority of users won’t see them. By doing this the Internet Explorer team may have created their own backwater, shot themselves in the foot and left themselves for dead.

Comments (23)

Snapshot 2007 is not CSS2.2 | October 26, 2007

While browsing my feeds the other day, I got really excited by this post on the CSS working group blog.

There was a lot of discussion earlier this year around Andy Budd’s proposal for a CSS2.2. The basic premise was that the Web needs a halfway point between CSS2 and The Complete CSS3 that is taking forever, so that the key features web developers need now can happen sooner. The structure of CSS3 is actually set up so that this can happen, but the CSS Working Group has realized that this is far from obvious to anyone outside the working group. So we’ve decided to publish a CSS2.2.

Wow, I thought to myself, I can’t believe that the W3C are going to implement an interim specification. That’s fantastic news!

Unfortunately, despite the attention grabbing headline, Snapshot 2007 doesn’t appear to be anything approaching CSS2.2. What I was hoping for was a list of all the selectors, properties and values that the working group felt were stable and ready for implementation. That way, browser manufacturers could start implementing and testing new features, under the knowledge that they weren’t going to change. Similarly, us web developers could start playing with these features and baking them into our more avant guarde projects.

Unless I’m very much mistaken, Snapshot 2007 doesn’t do this. Instead, it’s more of a “State of the Union” address that gives a general indication of where CSS3 is, without supplying the necessary level of detail. While it’s nice to see the “introduction” and “table of contents”, what I want to see is CSS 2007: The Definitive Spec.

Hopefully that will be coming soon.

Comments (8)

Whither W3C? | June 17, 2007

I’ve been a strong proponent of web standards since first being introduced to them back in 2000 by Jefrey Zeldman. I started discussing standards on my local mailing list, then on my blog, and finally at conferences and events. I even wrote a book on the subject.

Over the last seven years I’ve seen web standards go from relative obscurity to industry best practice. Browser support is now extremely good, and I can’t remember the last time I saw a job advert for a front-end developer that didn’t require a thorough knowledge of CSS. We no longer talk about them with such fervour on our blogs or at web conferences, preferring to talk about design, typography or user experience instead. Like all good standards, they have started to become invisible.

This invisibility is partly due to their widespread adoption. However it is also down to their slow rate of change. A few years ago we were seeing new CSS techniques appearing almost weekly, as developers tried to push the boundaries. However we’ve now reached a plateau with what can be achieved with the existing technologies, and need to look towards the future. Towards the people building the next generation of web standards.

The W3C has come under quite a bit of criticism of late for the slow development of CSS3, the wrong direction it took with XHTML2.0, and the mess it made with WCAG2.0. High profile developers have called into question everything from the organisational structure and decision making process through to the lack of transparency and the way it engages with the wider community.

To help address these issues, several people have set out on their own paths with greater or lesser success. As a response to the bloated and unworkable XHTML2.0 specification, the WHATWG set out to create something more relevant for today’s web application developers. Operating as a benevolent dictatorship, the WHAT working group was open to the views of the community, while managing to avoid getting bogged down in endless political discussions. While I’m not sure the model could work for other projects, the results have been pretty impressive. The working group has now become an official W3C working group, and the draft specification has been renamed HTML5.

Unlike other W3C working groups, anybody can join the official mailing list as an “invited expert”. From what I understand the list is very highly trafficked, and the technical level of the discussion is quite difficult to follow by your average web developer. However this willingness to engage seems to be baring fruit, and many of the less palatable ideas like reserved class names have been dropped. Apart from the working groups insistence on keeping the font element, everything else I’ve seen has been pretty impressive so far. In a recent post, Ian Hickson suggested maybe doing the same for CSS.

Taking a different approach was Joe Clark and his WCAG Samurai. A relatively secretive group of individuals, the Samurai were tasked with amending the existing web content accessibility guidelines. These guidelines were written a very long time ago and have been showing their age for years. With WCAG2.0 in development hell at the time, amending the existing spec seemed like a very sensible idea. The resulting guidelines have recently been published along with two “blind” peer reviews. While I doubt WCAG1.0 +Samurai will ever become an official guideline, it makes a lot of sense on first examination and I applaud Joe for his persistence and hard work.

I’m not sure if WCAG1.0 +Samurai has had any affect on the official accessibility working group, but they seem to have addressed most of the original concerns with WCAG2.0 which is very positive.

My own personal bugbear is CSS3. We’ve been waiting for CSS3 now for seven years, and while some of the modules are nearing completion, others may never see the light of day. I’ve listened to a lot of the arguments why CSS3 is taking so long, and I do understand. It is a very complicated project being developed primarily by volunteers, so is bound to take time. One of the most illuminating articles on the subject comes from invited expert, Elika Etemad, and is well worth a read.

I recently proposed an interim specification called CSS2.2 which would include all the CSS3 selectors, properties and values that had at least one existing browser implementation. This would include things like multiple background images, border images, border radius, web fonts, text shadows, box shadows and multi column layout.

By concentrating on already implemented features, this should be a relatively easy specification to produce. The documentation has already been written for CSS3, and the test cases and implementations are in place. Any extra work that needs to be done on these new features will need to be done for CSS3 anyway, so it seems like the job is more editorial than technical. Unless I’m missing something crucial it should be as simple as transposing these new features into the completed CSS2.1 spec and creating a new point release.

This interim spec would then give browser vendors something to aim for, and provide developers with the features we need to innovate. We could then start thinking about what new, as yet to be implemented features we’d like to see in a future point release. This would make the whole standards process much more iterative and get the popular or easily implemented features out in the wild faster.

Reaction to the idea seems largely positive. Most of the developers I’ve spoken to welcome the idea of an interim specification, and I was pleasantly surprised to hear Hakon Lie promoting the concept at both Reboot and @media London. In fact, it seems to have provoked some interesting discussions inside Opera. I’ve also had people contact me suggesting we start up some kind of grassroots movement to promote the idea of CSS2.2 or even draft a specification ourselves. However specification writing is a complicated process that requires specialist skills, so is best left to the experts.

I’ve heard that reaction inside the CSS working group is mixed, but with a closed internal mailing list and little in the way of external communication, it is very difficult to tell what they are thinking. They recently launched a new blog to help improve communication, but the first post doesn’t fill me with confidence.

The argument I always hear from the W3C is, “if you want to get involved, you should join one of our public mailing lists”. However this seems more like an avoidance strategy than a real desire to communicate. The W3C must know that signing up to a high traffic technical mailing list provides just enough of a barrier to entry to put the majority of people off. I actually joined their CSS mailing list a few years back, but quickly left after every suggestion I made was brushed off with instructions to check the archive or read a three year old thread.

Mailing lists may still be popular amongst academia, but I think it shows a distinct lack of understanding about how people use the web these days. Rather than being critical about people posting their thoughts to their blogs, if the CSS working group really want to elicit feedback they should embrace the developer community. Do what the WHATWG does and set up watchlists for common terms like CSS3 or CSS2.2, post regularly to their blog and set up an official wiki. If the CSS working group really want feedback, they need to start by offering more transparency and make it easier for people to contribute.

Comments (18)

CSS2.2 | May 6, 2007

The early pace of CSS development was pretty impressive. First proposed by Hakon Lie in Oct 1994, CSS1 became one of the first W3C recommendations in Dec 1996. Nipping at its heals, CSS2 became an official recommendation in May 1998, just 18 months later. By June 1999 the first 3 draft modules of CSS3 had been published, and in their ground breaking book published that same year, Bert Bos and Hakon Lie postulated that CSS3 would arrive sometime in late 1999.

Over 7 years later, and we’re still waiting. This begs the question, what went wrong?

For a recent conference, I decided to do a talk on CSS3. While researching all the cool CSS3 features modern browsers support, I became intrigued why things were taking so long. I started reading up on the W3C, how it was structured, how you became a member and exactly who was on the CSS working group. I started speaking to existing members and invited experts, reading blog posts from critics and people who had resigned, and looking at every bit of public information I could find.

Organisations pay thousands of dollars to join the W3C, and in return get to set the agenda on forthcoming technologies. While most of the companies involved are eager to shape the future of the internet in a positive direction, they all have their own agendas. Some obviously want to build better browsers, while others are worried about backwards compatibility and engineering problems. Some organisations have a vested interest in technologies such as SVG, while others are more concerned with opening the web up to different platforms like mobile phones and TV. By paying to be a member of the W3C, companies are able to get some of the brightest minds in the industry working on the issues important to their business, and who can blame them?

CSS3 has been in development in it’s current form since early 2000. There are currently 5 modules in “Candidate Release” status, and a further 6 are in “Last Call” status. This sounds good, until you realise that the selectors module was in “Candidate Release” as far back as 2001, and got rolled back to “Last Call” in 2005. Some of the current modules are set to be rolled back, while other modules like the “Box Model” module haven’t been touched since 2002. Of the 40 or so modules, only the TV profile and media queries modules are nearing completion. Lucky us.

There are various reasons why this is taking so long. Many of the issues are technical and can’t be avoided; problems when testing, issues with backwards compatibility and bugs with browser implementation. However there also seems to be a lot of politics involved. Discussions are getting bogged down in the same old arguments that occur time and again, priorities have been given to the wrong areas, and companies have been pursuing their own personal agendas.

Despite being broken down into separate modules, the scope of CSS3 is vast. As well as trying to look at the needs of the current web, the W3C are trying to anticipate the future. One of the big issues is internationalisation, which brings up problems most of us haven’t even heard of before. Tibetan style text justification anybody? Also with the project taking so long, the W3C are working in a constantly shifting environment. What may have been true about the web back in 2000, may not be true today, next year or in the next decade.

My fear is that the W3C has bitten off more than it can chew, and this is having a negative effect on the web. We currently live in a world of live texture mapping and rag doll physics. And yet as web developers, we don’t even have the ability to create rounded corner boxes programmatically. The W3C are so concerned with shaping the future, I’m worried that they may have forgotten the present. Forgotten the needs of the average web designer and developer.

I’ve been thinking about this for a while, and wonder if we need an interim step. If CSS3 is as big and complicated as the development timeline suggests, maybe we need something simpler? Something that gives us designers and developers the tools we need today, and not the tools we need in five or ten years. Maybe we should take all of the immediately useful parts of CSS3 such as multiple background images, border radius and multi-column layout. Maybe we should take all the CSS3 properties, value and selectors currently supported by the likes Safari, Opera and Firefox. Maybe we should take all of this information and build a simpler, interim specification we can start using now. Maybe, just maybe, it’s time for CSS2.2?

Over to you.

Comments (64)

CSS Support in Email Clients Still Pretty Poor | April 26, 2007

While speaking at web design world, one attendee asked me a question about styling emails with CSS. I gave my stock answer that as a technical person I had a strong dislike of HTML/CSS emails as I feel they were against the spirit of the medium. I really like the simplicity of text as a communication medium, so hate email messages that pretend to be web pages. If I want to read a web page, I’d much prefer to be sent a link.

To me, most HTML/CSS emails are the online equivalent of junk mail, so I have styling turned off by default. If one of these emails gets through my spam filters I have an almost Pavlovian reaction to hit the junk button, before even reading the mail. I’ve spoken to many technically savvy people, and this seems to be the common reaction.

However I did agree that from a purely marketing perspective, HTML/CSS emails do tend to produce slightly higher conversion rates than regular text emails. So if you want to bombard people with marketing offers they probably don’t want or need, I guess HTML/CSS is the way to go. However for the 0.2% of people who respond, you’ll probably end up pissing the other 99.8% of people off. Obviously I didn’t say that last part out loud, but you know what I mean.

Personal opinion aside, my understanding is that styling emails with HTML/CSS is incredibly difficult. This is due to the shear number of email clients out there, and their poor support of web standards. You would imagine that webmail clients would be better, but in many cases they are actually worse – disabling all CSS in emails to prevent clashes with their own style information. So my advise was simple. Avoid HTML/CSS emails if possible.

As a speaker, you occasionally get to see feedback from your presentations. I was pleased that my sessions were reasonably well rated, but amused by the following comment.

I hate that Andy was brought in as CSS expert and he totally balked at the html email question. Giving guidance to avoid html emails it’s too hard—doesn’t reflect the reality we face as marketers.

I have to admit that I’m no email expert. I also feel sorry for any reality that involves having to work HTML/CSS emails on a regular basis. However, if you want the low-down on current CSS email client support, the nice people over at Campaign Monitor have put together their latest finding on the subject. The bottom line seems to be, if you want your emails to work in Outlook, you need still to do table based layout.

Comments (23)

HTML 4.5 Anyone? | January 24, 2007

HTML was created for document mark-up, and it still does a pretty good job. However as websites become more application focused, it becomes harder to use HTML to model complex user interfaces. We have the basics in the shape of form widgets, but there are a number of key UI elements missing. You only have to look at the average desktop application to see the wide variety of widgets on display, from push-in buttons to vertical and horizontal sliders. You can “hack” some of these elements using CSS and JavaScript, but it always seems like a less than ideal solution.

One of the benefits of application development with Flex 2.0 is its wide range of interface elements, or components. The developers have thought about the needs of modern web applications, and created a really handy toolkit of widgets. The widgets are essentially a combination of markup (MXML), styling (CSS) and behaviour (ActionScript), so are not dissimilar to the widgets we have currently. Developers can also create their own widgets, which is both a blessing or a curse. It’s a blessing because if you really need a particular widget you can create it yourself. It’s a curse because it could also lead to a proliferation of non-standard widgets which could ultimately lead to a reduced user experience.

The feeling that the web is outpacing (X)HTML and CSS development has been growing on me for some time. While commercial organisations are quick to react to client feature requests (not always a good thing), it seems that the W3C is getting bogged down in internal politics and the desire to please a diverse group of stakeholders.

As a reaction to this, a group of web developers creating their own “standards” working group called the WHATWG. The result has been a HTML derived a draft specification called Web Applications 1.0. The draft spec includes some very interesting suggestions, along with some more controversial ones.

One recommendation is predefined class names which just smells wrong to me. Class names have always been a way of authors adding their own meaning to a document, and to that end are very powerful. You see them being used very successfully with microformats, which is a good thing. However it is their looseness and flexibility that really gives them their strength, so predefining them seems wrong. We had this discussion in the office and Jeremy rightly pointed out that if you need to mark something up as a copyright message, you should create a copyright element instead.

Looking through their spec, they have recommended a number of new GUI elements and attributes that could prove very helpful.

In part as a reaction to the WHATWG, and in part due to calls from the browser vendors, the W3C have set up a new HTML working group to look at developing HTML further. I’m interested to see what comes of this, although I do worry that 2010 may be a little late.

I’m also interested to see the crossover with the new HTML working group and the web forms working group. Web forms are basically an extension of the existing form controls and adds some interesting features like validating or requiring input and auto completion. Here are some of the additions that look interesting to me, although I’m sure there are more.

This progress is good, but I think there are a lot more useful elements you could add to both lists. Here are some of the elements I’d like to see in an application focused mark-up language.

This is just a start, but I’d be interested to hear what UI elements you think are missing?

Comments (27)

First London Web Standards Group Meeting | July 17, 2006

I had the pleasure of speaking at the first London Web Standards Group meeting on Friday. This was a particular honour for me as I was one of the first people in the UK to join the WSG mailing list in Feb 2004 and there are now over 400 UK members.

Being a WSG meeting, I assumed that everybody there would be a member, and therefore a die-hard standardista. I could have done a talk exposing the virtues of web standards, but was conscious about these events becoming one big back-patting exercise. As such, I decided to do something a little controversial and gave a talk on why I think web standards are no longer important.

I may have misjudged the audience slightly, as there were quite a lot of people new to standards at the event. However reading the blog posts afterwards, at least a few people got the gist of my talk.

I started off discussing the history of the screw and how it became one of the first official industrial standards. Incidentally, the first standard screw was proposed by one of the key engineers behind the difference engine, and I quite liked the fact that somebody responsible for the first computer was also ultimately responsible for web standards. I know some people wanted less screw-ing around and more CSS, but I say nuts to that (did you see what I did there!). As the first WSG talk I thought it would be interesting to talk about the history of standards and indulge myself in a spot of whimsey. I’m sure all future presentations will be overflowing with CSS goodness.

I then talked about the different types of standard, and the benefits that standardisation brings. I finished the talk by having a look at the good and bad points of web standards, before my main assertion that standards become irrelevant once they reach a certain level of ubiquity, and it was time for us standardidtas to stop worrying about standards and get on with the important job of building better websites.

Now if Molly had been in the audience, she almost certainly would have disagreed with the idea that the battle had been won, and standards were now ubiquitous. However in the context of a room full of standards geeks, I felt it was important to stress that standards are just the start of the journey, rather than the destination. Something that many of us forget.

If you read my previous post about public speaking tips, you’ll be amused to know that I failed to do pretty much all of them on this occasion. I’ve been really busy at work the last week, so didn’t have time to run through the slides beforehand. Consequently I felt decidedly under prepared and ended up tweaking the slides all the way up to London. It was a blistering hot day, so I decided to go in my shorts and new cork’d t-shirt and ended up somewhat under dressed . And if that wasn’t enough I managed to um and er my way through the talk, which may not have shown on the, er, day, but definitely stands out on the, um, podcast.

I had a really good time on Friday and would like to thank everybody who attended the event, and especially Stuart for organising such a great night out.

Comments (14)

A Sad Farewell to the Web Standards Awards | May 30, 2006

A few years ago, when standards based sites were still a novelty, I decided to document all the well designed sites I could find. This was partly for my own benefit as design inspiration, and partly as a means to show fellow developers that well designed CSS sites were a possibility. That list is still in existence, and can be found in the links section of my site. Looking at the list now, many of the original sites look old and dated, but at the time, they were cutting edge.

The CSS Zen Garden had recently launched, and helped prove that CSS sites need not be dull. However, while this provided the inspiration needed for forward thinking designers, managers and clients were a much harder sell. These were the days when tableless sites felt like a risk, and decision makers needed to be convinced that other companies were embracing web standards and creating beautiful looking sites.

What I wanted to do was set up some kind of CSS showcase, highlighting the best designs around. Not experimental designs such as those found in the Zen Garden, but real world designs being used in the wild. However time is always the enemy of invention, and I never managed to get my idea off the ground. This is why I was excited when a young designer from Sweden sent me a link to a project he was working on called the Web Standards Awards. The design was super-sexy, and the fact that something was already in the works meant that I didn’t have to do it myself.

Every few weeks I would bug Johan to see how the project was progressing, but like most good web developers, he was far too busy on client work. After about three months of me hassling him, Johan admitted that he was too busy to complete the project and was considering dropping it. At the same time, Cameron Adams had blogged about the need for a web design awards site, so I told him about the WSA and suggested that the pair of us helped Johan out to get the site up and running.

The designs and CSS templates were already set, so while Cameron wrote the site copy, I knocked together a quick Movable Type blog to power the site. This took a few weeks to organise, and by the time we were ready to launch, a new site called the CSS Vault had appeared. Still, despite not being the first CSS showcase site out there, we were the first, and to my knowledge, the only awards site around.

When we started, myself, Cameron and Johan would award one site a week, and then, at the end of the month, our team of judges would vote for the best one. This process worked well for around six months, but after a while I started to run out of steam. I had no problem finding sites to award, as standards based design had really started to take off. My problem was finding the time to go through all the suggested sites and pick a winner. I struggled on with my workload, but after a while just had to give up. I passed the baton onto Andy Clarke, and retired to become a monthly judge.

The web standards awards ticked along nicely for another 12 months, but as the other weekly judges workloads increased, the quantity of awards decreased. We tried to get some fresh blood on-board, but everybody we approached were too busy with their jobs, blogs and other commitments. After much debate, we came to the sad, but inevitable conclusion that it was time to close the doors on the WSA.

I think Cameron final post to the site sums up our collective feelings.

Web design has come a long way in the two short years that the Web Standards Awards have been running. When we published our very first award (The 85th PGA Championship) we had to search high and low for sites that could meet our high expectations of both design and coding. Since then we’ve awarded exactly 99 other sites that have carried on that same spirit of technical and aesthetic achievement that we set out to highlight.

Now we’ve arrived at a situation where beautiful sites with beautiful code are being produced by the hundreds; every month, every week, every day. It’s no longer a myth that you can produce a stunning site with Web Standards, and the most that our team can hope for is that the Web Standards Awards played at least a tiny part in helping to dispel that fallacy.

Effect or not, we feel that our mission is complete, that Standards have now ensured their rightful place in the process of Web design. So, it’s time to hang up our spurs and focus our attention where it’s needed most.

As a testament to the work of the pioneers who we applauded, this site will remain open as a record of 100 sites that helped shape a period in the Internet’s development that we were — and still are — excited to be a part of.

Thanks for watching…

It’s sad to see the WSA go, but it was better to close it now than continue to watch it wither on the vine. I’d just like take this oppertunity to thank my fellow judges, visitors, and most importantly, award winners, for making the site possible.

Comments (8)

Win an iPod Shuffle with cssmastery.com | February 26, 2006

iPod Shuffle on a copy of CSS Mastery

If you’d like the chance to win an iPod Shuffle, check out the new competition over at cssmastery.com. To enter, all you need to do is get a picture taken of yourself with a copy of my new book, CSS Mastery: Advanced Web Standards Solutions. Post the picture up on cssmastery.com and the best, funniest or coolest pic wins. Simple as that!

To check out the rules and post up your pics, head over to the iPod Shuffle competition page now.

Comments (11)

Egotistical B@5£@rd! | February 24, 2006

Well it’s now official. I have the second biggest Ego on the web. Bigger in fact than the combined egos of Robert Scoble and Jon Hicks.

Screenshot from egosurf.com showing me as having the second highest ego!

Who’d have thunk it eh?

Comments (12)

Take a Look Inside CSS Mastery | February 15, 2006

My book, CSS Mastery finally arrived today and I have to say that I’m over-the-moon with joy. It took around 8 months to write and there were times when I never thought I’d make it to this stage. But I have, and I can’t tell you what a relief it is.

I’m really pleased with how the book’s turned out. The cover design looks great, and the illustrations and screenshots have come together really well. If you haven’t already got your copy and would like to take a sneak peak inside, check out my CSS Mastery Flickr set.

inside cssmastery

I hope you enjoy the book and look forward to hearing your thoughts, suggestions and feedback. If you spot any typos, please drop me an email and I’ll make sure they are corrected. If you enjoy reading the book, please drop me a line or leave a comment below. Alternatively, please feel free to blog about the book or post up a review on Amazon

Comments (41)

Win a Copy of CSS Mastery: Advanced Web Standards Solutions | February 7, 2006

To celebrate the publication of my new book, CSS Mastery: Advanced Web Standards Solutions on the 13th of February, I am giving away two FREE copies to a couple of lucky readers. All you have to do is answer the following question in 30 words or less.

“I want a copy of CSS Mastery: Advanced Web Standards Solutions because…”

The top two answers, as judged by yours truly, will win a signed copy of the book. Points will be given for humour, creativity, desperation and sheer smarminess.

Comments (197)

What I Want From CSS3 - Part 3 | January 24, 2006

As you probably all know, the box model looks like this.

CSS Box Model

You start with the content area, then you have your padding and border, followed lastly by your margin. When debugging your code you can get an idea of how elements are interacting by giving them a border or a background colour. This will tell you what is happening with the space formed by the content area, padding and border, but gives you no information about the elements margins. There is simply no way to see what an elements margins are doing.

This is a big problem as margins can collapse with other margins, causing all kinds of weird and wonderful effects.

Margin Collapsing

I think two new CSS features would be extremely useful. Firstly I’d like to be able to add a margin-outline to boxes in order to show exactly how their margins are interacting. Secondly, it would be great to have control over margin collapsing, in the same way as you can control table border collapsing. So you could turn on and off the collapsing behaviour by doing something like this:


body {margin-collapse: none;}

p {margin-collapse: collapse;}

Now that would be cool

Comments (14)

What I Want From CSS3 - Part 2 | January 22, 2006

CSS allows you to move down through the document tree and select elements based on their ancestry. So you can style one element that is a descendant of another element. For more control you can use the child selector to style the direct children of particular element, rather than all of its descendants. The child selector is usually used in situations where you know the parent and want to style the children.


<div id="parent">This is the parent
  <div>This is the child (I want to style this)
    <div>This is the grandchild</div>
  </div>
</div>

#parent>div {...}

The problem is, I often find myself in the reverse situation, where I know the child and want to style its parent.


<div>This is the parent (I want to style this)
  <div id="child">This is the child
    <div>This is the grandchild</div>
  </div>
</div>

Currently the only way you can do that is to identify the parent by using a class or id name.


<div id="parent">This is the parent (I want to style this)
  <div>This is the child
    <div>This is the grandchild</div>
  </div>
</div>

#parent {...}

However this means adding extra mark-up to your documents and forms a bit of a code dependancy, where removing the child necessitates removing the identifier on the parent. This can be done programatically, but is less than ideal.

What I really want is a parent selector. That way, you could simply do this:


div<#child {...}

It’s a little more difficult to read as it doesn’t follow the current expectation that the right most selector refers to the element being styled. However it wouldn’t have an adverse effect on the cascade and could come in extremely handy in certain situations.

Comments (25)

Common CSS Bugs in Safari, Firefox and Opera | November 30, 2005

Every CSS developer has probably come across the double-margin float bug, the three-pixel text jog bug or the duplicate character bug at one stage or another. However all of these bugs revolve around Internet Explorer. I would like to know what are the most common bugs you experience on other browsers such as Safari, Firefox and Opera.

Over to you.

Comments (66)

What I Want From CSS3 - Part 1 | October 25, 2005

I’ve been thinking about liquid layouts recently and have decided how useful min-padding, max-padding, min-margin and max-margin would be.

Generally in liquid layout you will set padding/margin using percentages to create a liquid gutter between elements. However once the layout is reduced beyond a certain width, the gutters start to get too small. As such it would be great if you could set a minimum gutter width to maintain the separation of elements, and hence legibility.

Conversely, on a wide screen, gutters can become ridiculously big, causing a disconnect between content elements. Setting a maximum gutter width would prevent this problem and help keep elements visually associated.

Considering there is a min and max width, it seems like an oversight not to have an equivalent for for padding and margin.

Comments (13)

Why I Don't Care About Opera | August 31, 2005

I don’t want to be the kind of person that sits on the fringes of a birthday party, bitching about the host, but I really hate Opera.

Now before I start, I just want to explain something. I really wanted to like Opera, I really did. When I first became aware of Opera in late 2000, Firefox wasn’t even a twinkle in its fathers eye. Opera was being billed as a fast, reliable and standards compliant browser, possibly even an IE killer. What developer wouldn’t be supportive.

And yet, Opera never lived up to the promise. In a time when the web standards movement was in its infancy, Opera 4 was without doubt more advanced that both IE4 and Netscape 4. However since then, the move to web standards seems to have out paced Opera development at every step.

I started developing standards based sites around the same time that IE5.2/Mac came out. At the time, this was the most standards compliant browser available, and the first browser to really show that CSS based layout was possible.

Opera 5 was supposed to be standards compliant, but it felt very buggy by comparison. Macromedia used the Opera engine on Dreamweaver for the “Design View” on OS X. If you’ve never used the design view in Dreamweaver 4, it was really bad, to the point of being unusable for CSS based layouts. Is it any wonder why people were slow to take up CSS development when CSS layouts don’t even work in the most popular authoring tool. Im not blaming this totally on Opera, as I believe the Windows rendering was pretty bad as well. However it didn’t make me feel particularly warm to Opera.

Opera seems to have had a major update at least every 12 months. Operas 5 came and went, as did Opera 6 and Opera 7. All were slight improvements, but all still had major CSS bugs. If you used a standards based approach to your coding, things just didn’t work as they should. More annoyingly was the consistency of things breaking. Fix something in Opera 6 and it would break in Opera 7. Fix it in Opera 7 and it would break in Opera 6.

People are notoriously slow at upgrading their software, and browsers upgrades are no different. Due to the regularity of Opera updates, the developer is left with a mass of buggy browser versions to contend with. Once Opera 5, 6 and 7 have been retired, I’ll be a lot happier.

Opera started to become the bane of my web development life. Layouts would work “out of the box” in Firefox and Safari. They would work pretty well in Netscape, albeit it with the odd tweak here and there. Internet Explorer is a pretty buggy browser, but because of its market share it is an important and well known browser. As such, bugs get found, documented and often fixes or workarounds are discovered. No such luck with Opera.

At first I started to care about Opera. But as each successive site I built failed in Opera, I started to care less and less. At the start I tried to find workarounds, these days I don’t bother. Now days I expect CSS based sites not to work properly in Opera, and it rarely disappoints me. As such, Opera is my nominated “to fail” browser. If I have to choose between something breaking in one browser, but working in everything else, I choose Opera.

For a web browser that is 10 years old, up to version 8, and developed by one of the inventors of CSS, I had honestly expected more. Opera 8 is now finally a reasonable browser. It still has odd CSS bugs, but nowhere near as many as it’s ancestors. Unfortunately I’ve been let down by Opera so many times, I no longer care.

So happy 10th birthday Opera, but I really couldn’t care less if you made it to eleven.

Comments (61)

Internet Explorer and the Box Model | August 4, 2005

Everybody knows that Internet Explorer gets the CSS box model wrong. According to the specs, the width property relates to the width of the content area. Padding, borders and margins are added to this, in order to calculate the total size of the box. Internet Explorer incorrectly sees width as the sum of the content width, padding and borders, adding only margins to calculate the size of the box. This means that if you specify a dimension and then add padding, the box will be smaller in IE than every other browser.

Many people have berated IE for this flaw, however I actually think Microsoft got this one right. I personally think the W3C box model is flawed and feel that Microsoft’s original approach makes much more sense. Here is the reason why.

Quite often I’ll have a floated element, inside another floated element. I’ll want the child element to take up the full available width, so I set it to be 100% wide. Now I want to create a fixed width gutter on the inside of the element to let the contents breath. To do this you’d naturally think about giving the element padding. However wait a minute, the total width of your box is now larger than the width of the parent and your layout is shot to hell.

There are ways around this. For instance you could apply your padding to the elements children, either explicitly or using the child selector. Alternatively you can add in an extra element. However both these methods are messy and a bit of a hack. If the parent element has a known width, what I usually end up doing is setting the width of the child explicitly to account for my desired padding. However this seems really unnecessary and always makes me feel slightly uncomfortable.

This issue is probably the main reason why I shy away from flexible layouts. Sometimes you just don’t want to set your padding as a percentage, the available options are all less than satisfactory. It would make so much more sense if padding was applied on the “inside” rather than the “outside”, the way IE5 does.

Failing that, I’ve often wished I could include simple sums in my width declarations. Maybe something like this.


#wrapper {
  width: 100% - 24px;
  padding: 0 12px;
}

Now something like that could come in very handy.

Comments (63)

Remote Rollover Demo | July 16, 2005

I’m just preparing my slides for Tuesdays training course and thought I’d post up a couple of my remote rollover demos.

The basic set-up is very simple. You take a regular unordered list and wrap an extra, non-semantic span around the link text.


<ul id="pic">
<li class="rich"><a href="#"><span>&raquo; Richard Rutter</span></a></li>
<li class="dan"><a href="#"><span>&raquo; Dan Cederholm</span></a></li>
<li class="dunstan"><a href="#"><span>&raquo; Dunstan Orchard</span></a></li>
</ul>

You then apply your background image to the list, and set it’s position to relative.


#pic {
  margin: 0;
  padding: 0;
  width: 640px;
  height: 480px;
  list-style: none;
  background: url(rich-dan-dunstan.jpg) no-repeat;
  position: relative;
}

In the first example I’m using the anchor elements to produce the rollover effect.


#pic a {
  display: block;
  width: 100px;
  height: 140px;
  text-decoration:none;
  color:#003399;
}

#pic a:hover {
  border: 1px solid #fff;
}

I’m then positioning the anchors using floats and margins


#pic a {
  float: left 
}

#pic .rich a {
  margin-left: 80px;
  margin-top: 40px;
}

#pic .dan a {
  margin-left: 90px;
  margin-top: 50px;
}

#pic .dunstan a {
  margin-left: 140px;
  margin-top: 60px;
}

and positioning the text links absolutely


#pic a span {
  position: absolute;
}

#pic .rich a span {
  bottom: -2em;
  left: 0;
}

#pic .dan a span {
  bottom: -3.2em;
  left: 0;
}

#pic .dunstan a span {
  bottom: -4.4em;
  left: 0;
}

Positioning the anchors using floats and margins works if the items you want to roll-over are all roughly in a line. However if they are not, you need to position them absolutely as well. You can’t position the anchors absolutely, so you need to add an extra, non-semantic span inside the anchors.


<ul id="pic">
<li class="rich"><a href="#"><span class="box"></span><span class="link">&raquo; Richard Rutter</span></a></li>
<li class="dan"><a href="#"><span class="box"></span><span class="link">&raquo; Dan Cederholm</span></a></li>
<li class="dunstan"><a href="#"><span class="box"></span><span class="link">&raquo; Dunstan Orchard</span></a></li>
</ul>

You can then absolutely position those elements as well.


#pic .rich a .box {
  top: 30px;
  left: 80px;
}

#pic .dan a .box {
  top: 60px;
  left: 270px;
}

#pic .dunstan a .box {
  top: 70px;
  left: 520px;
}

This is how the second example works. Both these examples are fairly rough. They haven’t been extensively tested so I wouldn’t be surprised if they break on IE. However I think they provide an interesting example of what can be achieved using some fairly basic CSS. Throw in some pure CSS rollovers and you’d have something akin to the way flickr displays comments on images.

Comments (20)

Background Image Positioning Bug | May 3, 2005

A few months ago I was building a navigation menu using a list. I’d created a nice little arrow bullet which I wanted vertically centred and indented by 10 pixels. Pretty simple stuff I though, I’d just do something like this.

background: url(images/arrow.gif) no-repeat 10px center;

However when I checked, neither Safari or Netscape were displaying the image. I played around a bit and realised that these browsers refused to display the background image if I mixed units with keywords – something that’s allowed in the spec. This wasn’t a huge problem as I could simply do this:

background: url(images/arrow.gif) no-repeat 10px 50%;

So I noted the issue down and promptly forgot about it.

Browsing my “To Blog” list last week I came across the issue again and thought it was worth sharing. I knocked up a quick test case and ran it through browsercam.

All the versions of Netscape I tested failed to display a background image when I mixed keywords and units in the background property. The same was true for Opera 7. Opera 6 however displayed the background image but incorrectly centred it horizontally. Older version of Safari also displayed the bug, but it seems to have been fixed in the latest release.

Using the background-position property proved slightly better.

background: url(images/arrow);	
background-repeat: no-repeat;
background-position: 10px center;

Safari 1.2 now displayed the background image correctly as did Netscape 7.2. Netscape 6.2 and 7.1 along with Opera 7 displayed the image but didn’t try to position it.

It’s not a particularly interesting or important bug, and is one that’s easy to avoid by not mixing keywords with units. However I thought I’d mention it just incase anybody comes across the same issue and wants a bit of a sanity check.

Comments (19)

Heading Elements, Semantics and the Spec | February 7, 2005

Many people have taken to using the h1 element to describe the site a particular page belongs to. This usually involves wrapping a h1 tag around the site name, hiding the containing text from browsers using CSS and possibly swapping in the site logo using an image replacement method.

I can see the logic to this. Many people see a website much in the same way they see a book. Each page on a site is like a chapter in a book, so each page gets it’s own headline. However that chapter is part of a collection of chapters and it’s important to know what that collection is called. How else would you be able to buy it off Amazon? In the same way, people feel that a webpage is naturally part of a collection of pages called a website, so the main heading of all the pages on a site should be the name of the site.

The spec says “A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.”

The purpose of the heading element therefore is to describe the structure and content of the current page, not to describe the structure of the site or how this particular page fits into a larger hierarchy. By using the H1 element to link a document to a group of documents the web author is almost trying to create their own meta data. However that isn’t necessary as HTML already provides us with the means of doing this using the link element.

Most web authors are using the H1 element this way in order to increase the meaning of the document. However in many respects they are actually doing the opposite and adding superfluous information. For instance, much in the same way that a sighted user will scan a pages headings looking for information, an experienced screenreader user may have all the level one headings read aloud. This is because they know that level one headings should accurately describe what a page is about. If the site author has decided to use the level one headings to describe the name of the site instead, screenreader users may naturally assume that the pages don’t contain the info they are looking for and go elsewhere.

A lot of web authors also mistakenly believe that there should only be a single h1 per page. This makes sense if all the information on the page is about a single subject but it makes less sense if the page has groups of unconnected information. For instance, this article is primarily about headings, however the side bar contains unrelated information. Unfortunately because the sidebar doesn’t have it’s own h1, this information is structurally considered part of the headings article, even though it has nothing to do with it.

Comments (29)

Most Common Browser Bugs | January 10, 2005

As we all know there are a lot of buggy browsers out there. Some browsers are more buggy than others and some bugs are more prevalent than others. The first CSS bug most people experience is Internet Explorers 5’s box model problems. This bug is so common that many people learn to hack it before they even understand what the box model is.

The second most common bug I experience is the IE Doubled Float-Margin Bug. Once you’ve experienced this bug once it’s a pretty easy one to spot, especially if the margins in question are big. The next most common bug I experience will be familiar to anybody who’s tried to turn a list into a vertical nav bar. I’m not sure of it’s official title, but it’s one that causes gaps to appear in IE5 between the list items. It could be some variant of the IE Three Pixel Text-Jog, the final bug in my “most common” list.

Most of the other bugs I experience are random one off bugs. Some of them are known bugs like the bizarre Duplicate Characters Bug but the majority are ones I never manage to identify.

What are the most common bugs you come across? The ones you’ve had to deal with so many times you know what they are immediately when you see them?

Comments (16)

The Power of User Stylesheets | November 19, 2004

I saw a great post this morning on Mac OSX Hints that really demonstrates the power of user stylesheets. A chap called Lee Noble noticed that the main nav on the Sainsburys site broke on Safari. Rather than choose to do his grocery shopping elsewhere, Lee had a look at the code and fixed the problem using a simple user stylesheet.

How cool is that?

Comments (9)

Most Common CSS Problems | August 3, 2004

I’m always surprised to see the same CSS issues coming up time and again on lists like CSS-Discuss. What, in your opinion, are the most common problems faced when moving to CSS based layout and what advice would you give? What issues left you pulling your hair out in frustration and what issues do you wish somebody had told you about right from the start?

I’m sure most people here have a GMail account by now, but I’ll be offering 3 free accounts to the best problems and answers (as judged by yours truly).

Comments (64)

Separating Behavior From Presentation | July 26, 2004

I’ve developed a renewed interest in Javascript the last couple of months, due to articles like these, and more recently, an excellent SkillSwap talk by Jeremy Keith and Richard Rutter.

Over the weekend I decided to make a few little enhancements to the comment form on this site. I tidied up the live preview and added a “Make It Bigger” button to resize the comment field.

I really like the idea of separating behaviour from presentation. On a very basic level the site should still work smoothly if you turn off Javascript, CSS or both of them. For instance, at the moment, If you turn off Javascript, the “Make It Bigger” button won’t display, neither will the live comment preview. However I feel this separation should happen in the code as well as for the benefit of the user.

While scripting this button I realised there were essentially two ways of doing it. I could either affect the style of the form element directly using the style property, or I could apply a class to the field. If I use Javascript to affect the styles directly, that would be mixing presentation into the behaviour layer. To return the form element to it’s initial size I’m setting it’s height to be 100px. If I choose to set the initial height to something different in the stylesheets I have to remember to also alter this in the Javascript.

To get round this I thought about setting a class instead of directly setting a style. That solves the problem of presentation being mixed in with the Javascript. However it presents another problem. Turn CSS off but keep Javascript on and, even though the “Make It Bigger” button gets displayed, It won’t actually do anything.

So it strikes me that, while it’s possible to create separation for the user, the act of setting styles using Javascript makes this separation impossible for the developer.

Comments (24)

Heading for Trouble | July 20, 2004

There is an interesting discussion going on over at Jogin.com about the correct use of headlines. I’ve always seen headings as an indication of importance. If you look at this site you’ll see that the main headline for each post is a <h1> and any sub heads are <h2>’s. If you look at the side bar, all the headlines there are <h2>’s as well.

However Thomas points out that if you run such a site through the W3C validator with outline mode checked, you get an interesting result. Outline mode seems to be similar to documents outlines in Word which � if you’re lucky enough never to have used Word � provides you with a structural outline of your document. Looking at the outline of my homepage you’ll see that items in my side bar are being shown as structurally subordinate to the last post on my homepage. This obviously isn’t the case.

So it seems like headings are more to do with structure than importance. If you look at the specs they say

There are six levels of headings from H1 (the most important) to H6 (the least important).

Fair enough. This is probably why I, and many other web designers, have always seen heading levels being related to importance rather than structure. However you’d have thought that this being in the “structure” section of the specs would have been the first clue. The second clue for me is this line.

Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.

Thinking about it logically, the only way a user agent would be able to do this is if � like the validator outline display � the user agent used the heading levels to extract structural meaning from the document.

So rather than my document structure looking like this:

<h1>Article Headline</h1>
<h2>Article Subhead</h2>
<h2>Article Subhead</h2>

<h2>Sidebar Headline</h2>
<h2>Sidebar Headline</h2>

It should look like this:

<h1>Article Headline</h1>
<h2>Article Subhead</h2>
<h2>Article Subhead</h2>

<h1>Sidebar Headline</h1>
<h2>Sidebar Subhead</h2>
<h2>Sidebar Subhead</h2>

The thing is, you may not always want to display a main sidebar headline. This is another reason why people have chosen to use headlines to denote importance rather than structure. However following the whole “markup first, style later” philosophy, it would seem logical to create the correct page structure and then use CSS to hide any elements that you don’t want to visually display.

What do you think?

Comments (34)

Validation | June 28, 2004

Recently there has been quite a bit of discussion about validation. Some people feel that validation is extremely important, and that all sites should validate without exception. Others feel that validation is just another tool in a developers armoury, to be used if and when they please. My take on validation lays somewhere between these two extremes.

When I build a site, I start by building a number of generic templates. I first mark the content up and then slowly add layers of style. When I’ve finished a template I’ll run it through the validator as a final check to make sure everything is OK. I’ve been coding standards complaint HTML for a while now, so have a pretty good idea what is and what isn’t valid. Most of the time my templates are fine. If they don’t validate it’s usually because of some minor grammatical error that’s easily fixed.

Occasionally bugs do crop up. If it’s a particularly strange bug I’ll run the template through the validator just as a sanity check. It’s always good to tick off obvious problems before starting more in-depth bug busting. For less seasoned developers however, the validator really should be your first port of call. I’m amazed by the number of people who post “browser problems” to mailing lists when in fact the problem is down to invalid code.

Once the templates have been accepted and signed off by the client, it’s time to start building the site proper. This is the time when small validation errors are most likely to creep in. One area that errors occur is in dealing with copy. Clients will supply you with the site content, often in word format, and you’ll simply copy and paste this content into the page/database. However when you do this you can end up entering incorrectly encoded characters like a ” instead of a &rdqou;.

On most jobs you’ll have more than one developer working on the site and not everybody will be as up to speed with web standards as you. Because the templates are already done, it’s usually only minor errors that creep in at this point. Things like image tags or breaks not being closed properly. Authoring tools can also be a source of validation errors, although they are getting more standards friendly with each new release.

Once a site is built I usually give it a quick once over with the validator. On small sites I tend to validate every page, however on large sites this isn’t always practical. It would be handy if the W3C validator had a “batch option”, however until that happens the WDG HTML Validator” is quite useful. Some authoring tools have validators built in but in my experience they tend not to be very accurate.

When the site launches, It’s quite easy for validation errors to creep back in. A very common error being unencoded ampersands in links to external sites. If you’ve built a custom CMS, you could check and correct the errors on input (If you use MT, there are plug-ins that will do this). However this will add to the cost of the build and to be honest, most clients don’t care about validation. They are much more interested in the business objectives of the site and their ROI. The closest I’ve ever come to clients caring about validation is clients who want their site to adhere to priority 2 accessibility checkpoints, and this in it’s self is fairly rare.

The reason I validate sites is mostly out of professional pride. It’s nice to know that you’ve done a good job and created a valid site. However until people start serving up web pages as xhtml instead of text/html there really isn’t the need to encode every ampersand and close every break. I’m not saying that you shouldn’t strive for validation as it really is best practice. Just that sites are living, breathing things that are there to be used, and it’s not always possible to catch every last validation error.

Comments (23)

Box Model Hacks | June 17, 2004

I’m not a huge fan of CSS hacks. In fact the only hack I ever use is Tanek’s box model hack, and then, only when absolutely necessary.

I’ve noticed that developers have started using different hacks to get around IE box model issues, so was wondering what’s the current preferred method and why?

Comments (30)

An Objective Look at Table Based vs. CSS Based Design | May 12, 2004

Over the years there have been many great articles extolling the virtues of CSS based design and bemoaning table based design. However there have been very few articles looking at things from the other side of the fence. This is probably because you really have to understand and use CSS based design before you can criticise it. Yet once converted, few (if any) people go back to the old way of coding.

In order to bring some balance back to the equation, and to have a bit of fun playing devils advocate, I’ve decided to write an article about why in some instances, traditional table based design can be as good, if not better than CSS and standards based design.

The Demonisation of Tables

Before tables came along, the web was a pretty dull place. Using tables for layout opened up the possibility of visually “designing” a page. It could be argued that table based layout was responsible for the popularity of the web and the field of web design. That’s right. Without tables, all us web designers would probably be without a job.

Yet over the last few years, table based layout has become demonised. Web purists will tell you that tables were never meant for layout so you shouldn’t use them for such. However history has shown us many examples of technologies that started out life with one purpose, only to ended up finding more practical applications as something else. The web itself was never intended to be anything other than a way of sharing research data, and yet it’s become a channel for entertainment and marketing as well as information and education.

The Comfort Factor

As web designers, we’ve been laying out pages using tables for years. It’s a skill most web designers have, and most are comfortable with. Using tables in this way leads to very predictable results. By using a few very simple hacks, such as spacer gifs, we can pretty much guarantee that our sites will look the same on the widest range of web browsers out there, from the lowliest version of Netscape 4 to modern browsers such as Safari.

Despite the fact that pioneers have been talking about web standards for a long time, the majority of web sites are still developed using tables and non standards compliant code. Because of this, user agents will be forced to handle table based layouts for many years to come. This effectively negates one of the biggest selling points for web standards. That of forward compatibility. It’s highly unlikely that in the near future, any of the big browser manufacturers (um, that’ll be Microsoft then) will release a browser that renders the majority of sites unusable.

So most web designers really don’t feel there is an overwhelming need to start developing sites using CSS based layouts and standards compliant code.

Changing the Barriers to Entry

One of the reasons the web has been so successful, is it’s low barrier to entry. HTML is a simple “language” to learn and browsers are very forgiving about poorly formed documents. This makes it incredibly easy for anybody to publish on the web. Even your 12 year old nephew could knock up a simple site using the copy of Frontpage that comes bundled with Microsoft Office.

Compare table based design to CSS based design. Sure the syntax of CSS is pretty easy. Nobody in their right mind would argue that you need too be a rocket scientist to learn CSS. However, some of the concepts can be quite tricky to grasp. On the face of it, the box model is pretty simple, yet I still get tripped up by margin collapsing on occasion. Floating and clearing can be conceptually difficult to grasp, as can positioning. In my experience, there is probably around a 6-12 month learning curve from knowing basic CSS to actually being able to develop CSS based sites competently.

Then there is the problem of browser support. Once you’ve been doing it for a while, you get to know what browsers support what, and what the common browser bugs are. However, there are so many bugs, even the “experts” find themselves spending an inordinate amount of time bug fixing. For a novice this must be extremely frustrating. Not knowing if the problem is down to your misunderstanding of CSS or some obscure browser bug. Is it any wonder why the same questions come up time and again on list like CSS-Discuss?

When the browser manufacturers finally get their act together, developing sites using CSS will get a lot easier. Still, I think most people would agree that CSS development has a much higher barrier to entry than table based design. In an odd way, I think this is one reason why CSS based design is becoming so “popular” amongst web professionals. It allows them to differentiate themselves from the amateur “FrontPage Cowboys” and take back the web for themselves. Perhaps this is why many people see web standards as “Ivory Tower” and why many web standards advocates come across as having a sense of superiority and a zealous attitude towards web design.

Some Things Are Just Easier with Tables

I’m sure we’ve all found ourselves writing fairly complicated CSS to do something that would be trivial using tables. Take form styling for example. It’s possible to lay out even very tricky forms using tables in just a few minutes. You can achieve similar results by floating elements with CSS, but it’s a lot more involved. |f you’re a CSS guru it’s all part of the fun. However if you’re a regular mortal and your boss is breathing down your neck because they don’t understand why their “simple form” is taking so long, it can be incredibly frustrating.

If you have the knowledge and patience, you can do most things using CSS that you used to do using tables. Sure it may take you longer, but you’ll get there in the end (or die trying). However there are some things which, try as you might, you just can’t seem to crack. One such thing is page footers. I regularly see posts from frustrated CSS authors trying to create page footers than “stick” to the bottom of the viewport if the content doesn’t fill the whole screen. It’s pretty easy to do using tables, but try doing this using CSS alone. Is it any wonder why web developers turn their back on CSS when even simple things are rendered so complicated when you stop using tables.

Overstating the Benefits

There are lot’s of good reasons for throwing away tables and adopting CSS based layouts instead. However in their rush to push web standards, many people have overstated the benefits. It’s true that switching a large site to a CSS based layout can save a huge amount of bandwidth. However, for most sites, this saving would be insignificant.

People want fast loading pages and many advocates have suggested that CSS helps accomplish this. For most sites, the “design” is spread evenly across the whole site. However with CSS based sites, the “design” is usually held in one or more external files. These files can be pretty complicated, and even for a simple site, can get big, fast. A recent site I designed uses 4 stylesheets weighing in at around 12k (albeit including formatting and comments). By using CSS you’re actually front loading the design, rather than spreading it evenly across the site. The means that the first page you hit can actually take longer to download than the equivalent table based page. Once the styles have been downloaded, they will usually be cached and not need downloading again. However the first page on a site is the one page that you really don’t want to see such a performance hit.

Client buy-in

The sad fact is, most clients don’t care how a site is coded. Yet for some reason web designers feel the need to “sell” web standards to their clients. One way people do this is through the carrot and stick approach. The carrot is more often than not, search engine friendliness, while the stick is accessibility.

It’s true that the search engines like semantic pages. It’s also a widely held belief that search engines like lean code. Building a site using CSS and web standards can definitely encourage the development of search engine friendly sites. However it’s no magic bullet. There are many table based sites out there that score very highly in the search engines. It’s equally possible to build a CSS based site that gets a terrible search engine ranking. The most important thing for high ranking is content and inbound links, not whether a site uses tables or CSS for layout.

More concerning is the number of people who try to sell web standards and especially CSS based design by playing on clients accessibility fears. There isn’t anything inherently inaccessible about table based design. As long as tables make sense when linearized, their content is easily accessible. Screen reader technology is pretty good these days, and most screen readers are proficient at handling table based sites. While it’s true that your site needs to be published to a recognised set of grammars to get a AA accessibility rating, tableless design is only a recommendation, not a requirement for the more stringent AAA rating.

One often mentioned benefit is that of supplier independence. In a world were everybody develops to a standard, it would be much easier to switch between developers. They’ll instantly understand how the site was put together and not have to trawl through somebody else’s tag soup. This is reliant on having a significant number of suppliers versed in web standards. Unfortunately this currently isn’t the case. While the number of skilled CSS developers is increasing, it’s still a relatively specialist field. Because of this, it could be seen as a relatively risky proposition for a large company to lock themselves into a style of coding when there is such a lack of skilled coders. In my experience an organisation will often have a single individual experienced enough to develop a site using CSS. For many organisation switching to web standards could actually increase their dependancy rather than decrease it.

Conclusion

Web standards and CSS based design are definitely the way forward. However in our rush to advocate these “new” techniques, we may end up believing our own hyperbole. Build something up enough and the reality will always fall short of our expectations. By taking a dogmatic approach we risk alienating the very people we are trying to convince.

Table based design will be around for a long time. To encourage developer buy-in we need to lead by example and help reduce the barriers to entry. Not create new barriers. We need to be honest and up-front about the benefits as well as the cost. Developing CSS sites can be hard and it can time consuming. In certain circumstances using tables for layout can make much more sense than CSS.

Comments (95)

Semantic Coding | May 7, 2004

The rise of web standards has also seen the rise of semantic coding. We’ve had it drummed into us a thousand times that <h1>’s are for headings and not for big text, that <blockquote>’s are for quoting text and not for indenting. We’re all so used to this now that we do it by default (don’t we?).

Semantic markup has been sold to us very well. The dream is that one day, other computer systems will see meaning in your code. Google will look at your headlines and think “hmm, that’s a headline, it must be important”. Speech browsers will see that something is wrapped in an <em> and will dutifully emphasise it. Using (X)HTML elements in the correct, semantic way is very laudable and long may it last.

If you’re a CSS author, you’ve probably used container elements to help control the visual display of your pages. You’ll wrap a <div> or a <span> around another element (or group of element) to act as a hook for your style. By doing this you’re adding meaningless markup to your code for display reasons. This makes you feel bad, so you’ll try to give these hooks some meaning. You’ll put all your branding code inside a <div> called branding and your main content will go inside a <div> imaginatively called mainContent.

You relax into your chair feeling glad that you’ve bought order back into the world. However, if you are anything like me (for your sake I hope you’re not) there will always be one or two rogue elements. For instance, you’ve decided to go for a two column layout. What on earth do you call their parent <div>’s? You could call them col1 and col2 or leftCol and rightCol but that just seems wrong. What if one day, via the magic of CSS, you decide to switch their position. Chaos would ensue and you’d be forced to hang up your web standards spurs in shame. Of course you know that you’ll never actually change the order, but it still niggles.

The question that springs to my mind is “does it matter?” Despite what we’d like to think, not everything has semantic meaning. Some things are purely presentational and sometimes it’s going to be impossible to completely separate meaning from display. While it’s reasonable to expect that current and future computer systems will be able to understand the meaning behind a <cite> element, is it reasonable to expect them to understand each individual authors personal semantic vocabulary? Because let’s face it, there really is no standard way of semantically identifying page elements outside the regular (X)HTML tags. As such, pretty much all this “semantic” information is meaningless. It makes up happy (and to an extent makes development easier) but it’s not really intended for anybody other than ourselves.

Comments (30)

And the WSA winner for March is... | April 9, 2004

If you don't already know, the winner of the "Web Standards Awards":http://www.webstandardsawards.com/ Gold Star Award for March goes to "Jason Santa Maria":http://www.jasonsantamaria.com/. Unlike "last months unanimous winner":http://www.webstandardsawards.com/previous/the_85th_pga_championship.html, this month proved to be a much closer contest. Tied with "Adaptive Path":http://www.adaptivepath.com/ for two rounds of voting, it was down to that months judging panel "Chairman" to cast the deciding vote. So as well as commending "Jason Santa Maria":http://www.jasonsantamaria.com/ for an excellent job, I'd also like to commend "Adaptive Path":http://www.adaptivepath.com/ for putting on such a closely fought battle.

Comments (0)

Sub:lime Discussion | March 21, 2004

Thanks for all the comments about my recent Zen Garden rip. Who'd have known Metallica were such avid readers of my blog ;-)

I've been in email contact with both the designer who used my design and the owners of the site. Both have been extremely reasonable and the site got taken down and redesigned almost immediately.

It was clear from my corespondents that the designer in question was under the impression that the CC license gave him the right to use my design in any way he felt fit. My initial feeling was that he was wrong, but after reading some of your comments, I'm not so sure.

When I submitted my design, I read through the FAQ's, the CC licence and the comments Dave puts in the CSS files. All designs are given the same license and comments, so this is not something I could change or add to.

It was my understanding that the CSS was under a "Share and share alike" licence, but the design was not. This made perfect sense to me at the time. Being a designer and a developer, I see the design and the code as two completely different things. The design is the visual idea, the CSS is simply the mechanism I chose to represent that idea in.

As a developer, I'm not precious about my code. I'm happy for people to download it and play with it to see how it works. God knows I've done this before. I'm happy for people to grab chunks of code to use on their own sites, or use the code as a building block for something new. After all, this is how many people learn web design, and one of the reason the Garden was set up. Hell, it's one of the reason I submitted my design in the first place.

However as a designer, I see the design as a completely different, and very personal thing. While I'm happy for people to use my code, I'm less happy for people to use my designs without permission. Call me whatever you want, that's just the way I feel.

Usually it's pretty easy to spot a copy. I get quite a few people emailing me, telling me about a new sub:lime clone they have found. If they were better than the original, I'd be pretty chuffed. However they rarely are. A few people said that I should be happy that the designs are always worse than the original. However it just makes me sad. As I explained to Dave S, it's like when you design a great looking site for a client and then come back in 6 months to see that it's been messed up. It's not a nice feeling seeing good things go bad.

When something stops being your design and starts being a completely new work is a different matter. I'm all for people taking inspiration. In fact I'd encourage it. Building on somebody else's work is a good, creative and positive thing to do. Simply copying the design is lazy.

I think using music as an analogy is an interesting idea. I'd be more than happy for you to take a complete copy of sub:lime and either keep a copy on your computer or even publish it on your own version of the CSS Zen Garden. Using the music analogy, this would equate to file sharing . I'm also happy for people to take the design and use it as a base for creating something completely new and different (remixing). However I'm not happy for people to add their own content to my design and then do whatever they want with it. This would be like downloading a song, changing a few of the words and then using it for your company jingle or trying to sell it on to somebody else as your own work.

After reading some of the comments on my original post, I revisited the CC license and realised that the distinction between the design and the code wasn't as clear cut as I'd first thought. While I still believe that the design is different from the code, I now agree that the design is implied by the code, and that, if you release the code under a "Share and share alike" license, you're effectively releasing the design as well.

Despite what the rest of the comments in the code may say, having your design released under such a licence removes all control you have over the design. Effectively, the design isn't yours any more. You'd have no right to ask people not to use your design. They could sell it on, they could post it to a site such as www.oswd.org, they can basically do anything, as long as the license remains the same. It also appears, that once something is released under a CC licence, it can't be changed.

Some people have suggested that my decision to remove my design from the Garden was down to me not being able to handle the fact that people will always rip off designs. This is not the case. I'm perfectly aware that there will always be people out there who will copy other's work.

The reason I chose to remove my design is because the license it's been released under actively encourages this kind of copying.

Comments (28)

Beautiful Version 2 Entries | March 8, 2004

I have to admit, I wasn’t expecting such a high level of quality entries when Paul (whitespace) Scrivens announced his monthly Version 2 competition. However, on looking at the list of submission for the February contest, I have to say I was impressed.

The standards is extremely high and below is a list of my favourites.

Comments (14)

And The Winner is... | March 7, 2004

The judging is over, the votes are cast, and our esteemed judges have come to an almost unanimous decision. So it’s with much pleasure that I’d like to announce the 85th PGA Championship site as Web Standards Awards Site of the Month for February.

Despite some peoples misgivings, the quality of February’s award winners has been universally high. We are always looking out for sites that are visually appealing and marry usability and accessibility, with creative use of web standards. If you have been involved in creating such a site, or feel a particular site should be considered for an award, please don’t hesitate to send in your submission.

Comments (6)

Internet Explorers Expression Property | February 15, 2004

Ever heard of Internet Explorers expression property? Me neither. That was until I read this article.

Comments (17)

Safari Friendly CSS and Accessibility Favelets | February 15, 2004

I came across this handy user stylesheet and associated favelet the other day. The stylesheet basically outlines and names all the page elements with an ID or class.

There are a few favelets out there that do a similar thing (see my bookmarklets page), but they mostly use the border property. The thing that’s nice about this stylesheet is that it uses the outline property. Unlike borders, outlines take up no space, so using them for testing can be really useful as they don’t disrupt the layout of your page. Outline doesn’t work in the “usual suspect” browsers, but does work in Safari. As such, if your a OS X based web developer, this stylesheet and the associated stylesheet toggle favelet could come in useful.

I recently had a play with custom stylesheets myself and came up with a nice little, Betsie inspired one for people with visual impairments. Unfortunately, it only works if the site you visit have doctypes that don’t throw the browser into quirks mode. I’m sure there is probably a way around this, but haven’t had time t look into it more. If anybody has any suggestions, please drop me a comment.

In the meantime, I though my Betsie user stylesheet would make a neat little favelet, so tweaked the above favelet to create a Toggle Betsie Favelet

Comments (2)

Web Standards Awards | February 10, 2004

wsa.jpg

As you’re probably aware, I post a lot of links to nice looking CSS sites. I’d been thinking about creating a CSS links site for some time, but never got round to it. Then in Sep 2003, a chap called Johan emailed me ask my opinion about a personal project he was working on.

The project was called the Web Standards Awards and the concept was simple. Each month, a group of judges would give awards to their favourite CSS sites. Most of the hard work had already been done. The design was set, the stylesheets were built and the most significant thing was the need for a “Backend”. I was looking forward to seeing this site launched, so spent the next few months emailing Johan to see how things were going. However Johan was snowed under at work and having difficulty finding the time to finish the project.

At the same time, Cameron from The Man In Blue started talking about the need for a web standards award site, so the three of us decided to join forces. Johan finished tweaking the design, Cameron supplied the copy and I set up MT. As we’ve all been busy, it’s taken a few months for the site to be ready. However as of this moment I’m pleased to say…

The Web Standards Awards are now open.

Comments (15)

A Fresh Bunch of CSS Goodness | February 9, 2004

Comments (10)

Deja-Vu | February 5, 2004

Scrivs posted a lovely Chech website on the CSSVault today. However I've a nagging feeling I've seen it somewhere before.

Comments (11)

Another Big Site Gets a CSS Makeover | February 2, 2004

The AOL site has been given a CSS makeover and I have to say, it looks pretty good.

New AOL site banner and nav

Like most big site makeovers, the first thing people notice are the sites problems. In the case of AOL, the site doesn’t validate, a lot of the text is image based, the text is a little small and overlaps its containers when resized.

The site also uses Javascript to show/hide layers of content. However instead of using a method like this, when Javascript is turned off, some of the content is inaccessible.

All that being said, the site looks great. It’s got a very macromedia.com/Windows XP feel about it. It’s good to know that the old idea about CSS sites looking square and ugly is well and truly out of the window.

Comments (12)

A Weakly Source Of Inspiration | January 29, 2004

If Paul Scrivens is officially the busiest man on the web, Russ Weakly has to be running a close second.

Russ runs Max Design, a web design firm in Australia specialising in web standards. Many people will have come across Russ though his excellent Listomatic and Listutorial presentations. Since then, Russ has been building an archive of quality articles at a rate of knots. They are coming so thick and fast, Russ has just posted a new article while I'm still getting round to posting about his last one.

Russ also chairs an organisation called the Web Standards Group. This groups runs regular meeting around Australia, allowing web standards enthusiasts to meet up and discuss issues that interest them. The turnout for these meetings looks pretty good, so It would seem that Oz has one of the most web standards savvy workforces around. By comparison, a quick look at the London web standards group at meeetup.com reveals 3 active members!

The Web Standards Group has a good, active mailing-list and one that I've been tempted to join on a number of occasions, even though I'm not based in Australia (which is a shame in and of it's self!). The list discusses some really interesting topics including a recent one from Russ entitled, Real world use of standards.

If that's not enough, Russ is a regular poster on the webgraphics site. And I thought I was busy!

Comments (8)

A Selection Of Nice CSS Sites | January 27, 2004

Comments (19)

A Couple of Questions About Web Standards Advocacy and W3C Validation Buttons | January 26, 2004

Over the weekend a few people picked up on the fact that my homepage no longer validated. I felt it was OK to keep the validation buttons as they are a means of helping me keep the site valid and also act as a show of intent and transparency. However not everybody agreed.

There was also a feeling that as my site didn't validate It was hypocritical of me to discuss web standards.

So:

Q1. Does having validation buttons require a site author to validate their pages every time a change is made or is it sufficient that the site validated when first published and checked periodically? Knowing that a page may not validate 100% of the time, is it better to have no validation buttons?

Q2. Is it hypocritical to discuss web standards if your page doesn't validate.

Comments (39)

First CSS Links of 2004 | January 5, 2004

My first selection of good looking CS sites for the New Year. If this is an indication of things to come, the quality of work out there is going from strength to strength.

Comments (5)

A Selection of CSS Goodness | December 23, 2003

Comments (7)

Even More CSS Sites | December 11, 2003

Comments (15)

More Nice CSS Sites | December 2, 2003

Here are a few more nice CSS sites for your browsing pleasure.

Comments (8)

Selectutorial | December 1, 2003

The guys from Max Design have come up with another great tutorial, entitled Selectutorial: CSS selectors. Well worth checking out.

Comments (0)

No Margin for Error | November 23, 2003

Margin Collapsing

Margin collapsing is a CSS phenomenon I've been familiar with for a while. Conceptially It's very simple, however recently I've been running into a number of problems with my layouts where margin collapsing appears to be the culprit.The problems usually revolve around either extra vertical white space appearing that I just can't seem to remove or the inability to create vertical white space by using margins.

At it's core, margin collapsing is very easy to understand. Basically when two vertical margins meet up, instead of adding together, the largest margin takes precedent and the other one "collapses" to nothing.

Here is a simple example:

This paragraph has a 20px margin

So does this one

Both paragraph tags have been given a 20 pixel margin. However because the bottom margin of the first paragraph touches the top margin of the second paragraph, the margins collapse, making the space between both paragraphs 20 pixels instead of 40.

Most people think of margin collapsing happening when one block level element follows another. However margins collapse whenever one margin comes into contact with an adjacent margin. This means that margins can also collapse when one element is contained within another.

A paragraph with a 20px margin inside a div, also with a 20px margin

In the above example a paragraph (light blue) with a 20 pixel margin is wrapped inside a div (medium gray), also with a 20 pixel margin. The top and bottom margins of the paragraph tag collapse into the margins of the div tag leaving just a 20px vertical margin around both elements.

Now you've probably noticed that these two tags are contained within another div that I've applied a border to. Most people will assume i've done this just to make the examples stand out. However I've actually done this for another reason.

Here is the same example with the border on the outer div removed.

By removing the border around the outer div, the margins of the contained elements are now adjacent to the margin of the preceding element (in this case a paragraph tag) and have all collapsed together. Now while this is what margin collapsing is supposed to do, if you don't know what's going on here, this kind of thing can be a bit of a head scratcher.

There are number of ways to get round margin collapsing issues. One way is to add a border or 1px of padding around the elements so that the borders are no longer touching and so no longer collapse.

The same example but this time each element has been given a border

Another way to stop margins collapsing is to change the position property of the element.The CSS2 Specs explain that margins of absolutely and relatively positioned boxes don't collapse. Also if you float a box it's margins no longer collapse. It's not always appropriate to change the position properties of an element but in some situations if you're having problems with unwanted margin collapsing, this may be an option.

Before I move on, it's probably worth bringing up self collapsing boxes. A self collapsing box is one where it's top and bottom margins meet.

Here is a very simple example of a self collapsing block

This paragraph has a 20px margin. After this paragraph is another, empty paragraph, also with a 20px margin

Because the second paragraph has no content, it's margins collapse together and they in turn collapse with the preceding paragraph. This is why you can put loads of empty paragraph tags in a page yet they take up no space. Usually this won't cause any problems, however people occasionally use empty elements to clear a float for instance, so this behavior needs to be born in mind.

Cleared Elements

On the subject of margins and floats, here is an interesting situation I came across a few days ago while trying to lay out a page.

This div is floated left
This div is cleared and has a 20px top margin

In the above example it would be reasonable to expect that the div with the 20px margin would be 20 pixels below the floated div. However in actual fact it appears to be only a couple of pixels below the floated div.

If you look at the CSS2 Specs for clearing floats you'll get a better understanding of what's going on. When you clear something, what actually happens is the element you've applied the clear to increases it's margin enough so that it clears the proceeding floated boxes. If that element already has a margin the largest margin wins. In this instance the 20px margin is just slightly larger than the height of the floated box and it's top starts at the top of the floated div. Because the floated div is slightly less than 20px tall you get a small gap between the two elements background colours.

In a layout I was working on recently I ended up with both these phenomenon happening at once. Things were collapsing all over the place (literally and figuratively). I even ended up having problems with an empty div I was using to clear a float apparently collapsing in on it's self and then collapsing with other elements, causing all sorts of layout problems. So if you find yourself in a situation where you are using margins to space out elements but are getting unpredictable results, it may be down to margin collapsing, it may be down to cleared elements and if you're really unlucky it may be down to both.

Comments (31)

Sub:lime revisited | November 23, 2003

Since submitting my sub:lime design to the CSS Zen Garden I've been getting quite a few emails about it.

Most have been from people asking if they could use the design on their site. I try to explain to them that the CSS Zen Garden is aimed at helping people learn about CSS and not just a repository for cool CSS templates. I'm happy for people to use the CSS and layout as the basis for their site, but am less happy people just blatantly copying the design, images and all.

To these people I point them in the direction of these links:

Explain that I'd rather they not use the design wholesale but use it as a learning experience, and hope that they understand.

However this morning I got a wholly different and much more encouraging email from a chap called Dan.

I am about to partake in a redesign of my personal website to make use of CSS layouts. In preparing to do so, I have been practicing with the zengarden layout. I selected your design and did my best to duplicate it using only styles (no images) as an excercise. I would like to share with you the result of my tests:

Sub:lime

Obviously by doing away with images you do loose some features, such as the side gradients. However, I think you might find that I discovered some optimizations in your design. I was able to avoid using the extraDiv1 and I found that many of the images simply aren't needed.

Now this kind of thing strikes me as the very reason behind the CSS Zen Garden and why the CSS is released under a creative commons licence. It's not to allow people to "steal" the designs and use them on their site, it's to allow people like Dan to break the CSS down, see how it works and come up with new and innovative solutions, while at the same time leaning about tableless design.

The solutions Dan has come up with are great. I'm the first to admit that the CSS makes far too much reliance on image replacement techniques such as FIR, and includes a couple of nasty little hacks, both of which Dan has managed to minimize/fix.

Now some people would see this kind of recodes as rude and insulting, however personally I think they're great. Apart from giving Dan the opportunity to try out his CSS skills on a design he obviously must like, I've learnt a thing or two as well. I spent about an hour going through his stylesheet this morning, looking at the changes he'd made and noting down ways I could improve my own CSS in the future.

So nice one Dan. I hope to see a few less people simply helping themselves to my Zen Garden Design and a few more people using it as the resource and inspiration it was intended to be.

Comments (9)

Some Nice CSS Sites | November 15, 2003

Here are a few nice CSS sites that have been lurking in my bookmarks for a few weeks.

Comments (4)

ReUSEIT! Competition Winners | November 15, 2003

Well the votes have been tallied and the winners of the ReUSEIT! competition have been announced.

I think it will come as little surprise that Mike Pick's excellent Kraftsman entry scooped the top prize. Mike's design was definitely one of my personal favourites. On the face of it, the design and layout is very simple. However Mike has paid great attention to detail here and it's this subtle use of detail that really makes the design. From the superb choice of typeface to the gorgeous iconography, the design exudes subdued style, allowing the content to take center stage.

The two runners up (Only a few graphics... and Minimal Use) were also good, solid, practical designs and ones I'm sure would suit Jakob's style.

Of the others, here is a short list of my personal favourites.

Overall the competition attracted a good spread of submissions. If I have one criticism, it's that I felt a large proportion of entrants had jumped straight into the coding before any prolonged design phase. In the early days of the web when the majority of people building sites were on the techie side rather than the design side, this is how most sites got built. However I feel there really is a need for CSS enthusiasts to spend more time in their favourite graphics packages before hitting their text editors. Theoretically at least, it's shouldn't matter if you're building the site using old skool table based layout's or lean mean CSS/(X)HTML. The design should inform the coding, not the other way around.

Comments (0)

Some Nice CSS Sites | November 7, 2003

I've seen a few really nice CSS sites of late. One of my favorites being SharkRodeo. The site is quite small and simple, but a lot of thought has gone into the layout, design and colour scheme. It really is a joy to look at and goes to show that small can deffinately be beautiful.

Then there is Wildly Sophisticated Media. This site has an identity that really packs a punch, feeling more like a trendy lifestyle magazine than a careers site.

And finally there is Lockergnome. Their new site has lot's going on on the home page and is a little too busy and portally for my tastes. However it has some lovely little flourishes and proves that CSS based sites don't all have to be minimal and full of white space.

If you know of any more cool CSS sites, please let me know.

Comments (7)

Interesting new CSS Zen Garden Design | November 7, 2003

The latest Zen Garden submission by Shaun Inman's is an absolute gem. Entitled This is Cereal, the design is full of wholesome breakfast goodness and is one of the most distinct designs I've seen on the garden so far.

Keep up the good work.

Comments (7)

My Favorite CSS Zen Garden Designs | November 3, 2003

For no particular reason, here is a list of my top 10 favorite CSS Zen Garden designs, in the order they were submitted in.

Comments (3)

Beautiful New Zen Garden Submission | October 7, 2003

John Hick's new Zen Garden Submission is possibly the best one yet.

John has managed to create a design that blends a clean, elegant layout with a strong visual identity. The colour scheme and considered use of whitespace give the design a beautiful calm sense of balance.

John's submission has definitely upped the ante, pushing the quality of design to the next level.

I'm just glad I managed to get my design in before this one.

Comments (4)

Margin:auto quirk in Netscape 6+ | October 3, 2003

Thanks to Gus Campbell for spotting this issue. When centering an div using margin:auto, in Netscape 6+, if you reduce the screen width to less than the width of the div, you get a negative margin on the left hand side of the screen. This renders your site unusable for people on small monitors as it's impossible to read the text falling off the left had side of the page.

Gus did some poking around and found that setting a minimum width on the body tag would combat this problem. He also believes that, rather than being a bug, this is actually the recommended behavior.

I must admit this is a new one on me. I did a bit of googling but couldn't find this mentioned anywhere. Is this a new issue or did I just forget to read the memo?

Comments (5)

About My CSS Zen Garden Submission | September 29, 2003

I'm pleased to say my submission to the CSS Zen Garden has just been accepted, so following in a grand tradition, I thought I'd say a few words about how it was created.

I've been meaning to do a submission for a while, but work, skillswap, my photo site and new blog have been keeping me busy. However my girlfriend was away a few weekends back, so in between sessions of Neverwinter Nights, I had some free time on my hands.

I started off with a layout pretty much in mind. I wanted a centered panel that stretched from the top to the bottom of the page and was surrounded by a drop shadow on both sides. The design would have a header block and then blocks for the content. Usually I'd sketch these initial ideas out on paper but in this case I didn't feel the need.

Not being a naturally talented visual designer, I get a lot of inspiration from other well designed sites. I have a big bookmarks folder of great looking sites, and for most projects this is one of my first destinations. Two sites I kept referring to were hicksdesign and jeffcroft.com. When I first saw these sites I really liked their colour schemes and decided I wanted to use an orange and green colour pallette on my submission. The CSS Zen Garden already had a very nice submission using a strong orange and green pallette so I wanted to make sure that the colour pallet I used was a lot more muted.

Layout wise, there were two regular sites and two other Zen Garden Submissions I kept coming back to. I liked the header layout of mckendall.net, especially the thin white lines between blocks (something that also appeared on jeffcroft.com ) and the block at the top of the page that bled to the edge. Indesain Studios was another beautiful site that used a general layout similar to what I wanted to achieve. The other two zen garden designs that most influenced me were Not So Minimal and Erratic Blue. I liked the overall content layout of both these designs and borrowed heavily from Dan Rubin's headline treatment. Finally I liked the logo Didier had created on his Release One submission and wanted create something with a similarly modern feel.

So with all these sites to inspire and influence me, I opened up photoshop and started working on the design. Everything took shape fairly quickly and I had my first draft ready in just a couple of hours. The main focal point of the design was a central image. After looking though my own pictures and not finding anything suitable, I did some searches on stock xchng and came across this picture. I actually didn't think the picture would be suitable for what I had in mind, but the colours were right and I didn't want to spend hours looking for an image. I decided to use this image for now and possibly think about alternatives later.

I bought the image into photoshop and immediately pixelated it to help create the colour palette. I really liked the pixelated image and after playing with a few variations (smaller pixels, fading from pixelated to solid etc) decided to settle on the original big pixelated version.

From here I came up with the idea of calling the design either sublime or subliminal. I liked subliminal because I thought the pixelated image of the limes was quite subliminal. However I ended up choosing sublime, because of the meaning of the word and also because I thought the image was no longer a picture of limes, it was somehow below or preceding being an image of limes, or sub-lime (wankey bit now over).

Once the design was finished, I chopped it up in fireworks, which I find much more intuitive than image ready and then started thinking about building the CSS. At first I thought I'd probably want to see how other people had built their CSS files. However once I started coding, I realized that I probably didn't need to. The design I'd come up with was pretty simple and I ended bashing out about 95% of the code in around an hour.

Like most CSS I do, I take a progressive enhancement approach, slowly building up figurative layers of style, step by step. I started by laying out the container, then moving on to the header, main copy and nav areas. On my next iteration I started styling the text, adding font size, spacing and padding. Finally I added the headline images and sorted out the styling of the nav area.

I tested this on Safari (My browser of choice), Explorer, Netscape and Opera on my Mac and was relieved that everything worked fine. I'd normally fire up Virtual PC to test on windows, but had stupidly deleted all my disk images the day before when trying to clear space on my hard drive. So I ended up having to wait a few days before I could test the template on a PC. Luckily, while there were a few IE problems, they were mostly related to the box model and were easily (if a little inelegantly) fixed. There was also one weird issue, which I won't bore you with now, but is documented in the CSS, that kept me stumped for an hour or so.

In total the design and template build probably took me less that 10 hours. Basically 2 evenings work. This was something I was particularly please about as I rarely spend less than a couple of days on a design and a good week or more building and then testing/debugging a CSS template. However in this case I think having the HTML already built and not being able to touch it was a big help.

Considering the speed at which I did my submission I'm pretty happy with it. I like the colour scheme, and the simple blocky layout works well I feel. I had some really positive feedback last week when I posted it up for testing/feedback, but am always interested to hear what others have to say.

Andy

Comments (10)

My Zen Garden Design | September 26, 2003

Hi Folks,

I spent last Friday and Saturday evening coming up with a Zen Garden design.

Basically I wanted to create something clean and clear. Not too flashy or full of complicated CSS trickery. Just something simple that would inspire people to say, "hay, I could do something like that!"

I was also keen on getting the job done quickly (busy man and all) and not trying to impress people with my (limited) CSS knowledge. As such I wrote the bulk of the code in about an hour. I realise that it's a bit sloppy and uncommented. I've used the box model hack far more times than I usually would. However on the whole I think it's turned out quite well.

I've tested it on a few browsers and it seems mostly fine. However I'd really appreciate it if people could give it a once over before I submit it to the Garden, in order to catch any lurking bugs.

Also I'd really like to know what you think, and any suggestions you may have to make it better.

Cheers

Comments (19)

Google Redesigned | September 25, 2003

Continuing a common theme, Paul Scrivens has just created a standards compliant version of Google.com. The nice thing about this redesign is the lack of redundant <div>'s, something Richard Rutter would be pleased with.

While on the subject, Paul's new site whitespace, is a great little blog and one I immediately added to my RSS feed when I came across it last week. Well worth a read.

Comments (9)

User Defines Style sheets and Quirks mode | September 23, 2003

I've been trying to create an accessible user style sheet based on the default style of the BBC's Betsie program. I thought this would be an easy task but it's actually been proving quite tricky.

What I want to be able to do is linearize a table based layout. To do this I've been using:

table, tr, td {
  display: block !important;
}

However when I tested this on a number of popular sites like Yahoo or Amazon, the layout didn't get linearized at all. In fact it ended up getting severally mangled. It turns out that these popular sites don't have a doctype. This sends my browser into quirks mode and turns the layout to jelly when viewed using my custom style sheet.

The idea behind user style sheets is to give final control to the user. Unfortunately this breaks down if the browser/site has final say about the rendering mode. With so few sites actually having doctypes, this makes creating useful user style sheets a real hurdle.

The only way I can see round this is for browser manufactures to allow people to alter the rendering mode themselves (does any browser currently do this?). Otherwise user preferences are always going to be held over a barrel by web browsers and doctype-less sites.

Comments (3)

CSS Based Design - Matrix Style | September 23, 2003

Based loosely on a SkillSwap talk given back in March, Jeremy Keith's new CSS Based Design article is a joy to read.

The article is peppered with Matrix references to produce something that is both extremely useful and highly entertaining.

Who said learning had to be dull!

Comments (0)

Cool use for CSS attribute selectors | September 22, 2003

A while ago I wanted to remove the borders around all the text input boxes in a form, while keeping the borders around the submit buttons intact. The only way I could figure out how to do this was by setting classes for all the input boxes. It worked, but it felt rater unsatisfactory. Surely there should be some way to only apply styles to one type of input tag, but not another.

Well in fact there is, by using attribute selectors.

Attribute selectors are part of CSS2. They basically do what they say on the pack. You can select an element based on that elements attributes. So for instance, If I wanted to remove the borders around all the text input boxes in a form I could simply do this.

input[type="text"]{
  border-style: none;
}

Unfortunately, while attribute selectors are pretty well supported amongst most modern browsers, they aren't supported by IE5/Win. That meant in my case I was still stuck with using classes. Still it did open my eyes to how potentially useful attribute selectors could be.

Today I came across a cool way to use attribute selectors in order to hide banner adverts. The basic Idea is pretty simple. By using attribute selectors, hide any elements who's attributes look like they could relate to banner adverts. In the most simple for you'd do something like this.

img[height="60"][width="468"]{
  display: none !important;
}

Which would hide any image that was the shape of a regular banner ad.

However some people have taken this idea much further and have created user style sheets which aim to cover as many attribute permutations and combinations as possible. So if you're fed up of banner adverts, instead of using one of the many ad blocking programs around, why not simply set up your own banner ad blocking user style sheet.

Comments (10)

Web Standards and Tableless Design | September 17, 2003

I belong to a number of web design related mailing lists and see quite a few people asking if they should start doing tableless design. I think it's great that more and more people are starting to design sites this way but feel that these is a bit of a misunderstanding about tableless design and web standards.

CSS based tableless design and web standards are actually 2 different things but are often chunked in together. It's perfectly possible and acceptable to create standards compliant sites that use tables for layout. The idea is to eventually faze out the use of tables for layout. However as long as browsers support tables and the standards say it's OK there is no real problem with using simple table based layouts.

However tabeless design is undoubtedly the future of the web so it makes sense for people to start working towards that goal and upskilling themselves. There have recently been a number of high profile tableless sites launched and this is only going to increase in frequency. So if you're new to CSS layout it really makes sense for to start exploring it as a possibility.

Using CSS for layout has some wonderful benefits like improved search engine friendliness, better site accessibility and potential bandwidth savings. It can ease site maintenance and potentially make site redesigns a simple process.

Good CSS based layout can be a complicated thing to achieve and requires a solid understanding of CSS and browser quirks. Some people fear that because of this complexity, you may have one CSS guru who does all the layout for a site, but unless everybody working on the site are also very knowledgeable in using CSS, tableless design would be unworkable.

Personally I believe that by separating the style from the content, it actually makes life easier for the developer. They no longer have to worry about breaking a sites design because they never have to go near it. No more having to add font tags all over the place and escape lots of tag attributes, or work out complicated routines just to echo out some info in a multi column table layout. So using CSS to control layout can greatly simplify the job of the programmer/developer.

Fundamentally the argument shouldn't be whether to use tableless design or not. The argument should be to adopt web standards, and design to a standard, not a browser version. Then, when it comes to designing the site, make a considered decision about the general design layout. If you think you can do it using CSS (i.e. it's a simple layout and you've got the in-house skills) then go for it. However it's just as valid to use tables to control the basic layout (doing your best to cut out complicated or overly nested tables) and use CSS to control everything else.

This is the way vendors such as Macromedia are moving. DWMX2004 now uses styles by default to control text appearance, page colours, margins etc. However they realise that table based layout will be hear to stay (for a while at least) so have updated their table editing mechanisms as well.

So if you're struggling about whether you should start designing sites using CSS layout instead of using tables, don't (struggle that is!). We're living in transitional times. By all means have a play with CSS based design, but don't cut yourself up if you have to use tables occasionally.

Comments (5)

Not just Listmatic | September 15, 2003

The link to the excellent Listmatic CSS list styling site has been doing the blog meme rounds for a week or so. As such I wasn't going to post it up as I guess most people will have already come across it.

However I did a bit of poking around the people who wrote its site and came up with this interesting little presentation. Not anything ground breaking, but if you know somebody who knows little about web standards, it's probably worth pointing them too.

What's more interesting is that the authors, Max Design, seem to be one of the few web design companies I've seen who exclusively do CSS based design. Most of their work seems to be for one client, The Australian Museum, but some of the sub sites they've done for them are really very nice.

Comments (0)

Graduate recruitment site live | September 12, 2003

The last couple of weeks we've been busy building a small site for a well known high street brand, which went live yesterday. This job was purely a production job, the design having been executed by a partner agency of print designers. I did all the CSS work, Jamie did the project management and production while Jeremy did the PHP programming and Database work.

We decided that the site needed to have a high level of accessibility so we chose to build it using CSS layout. I started by building an XHTML template and making sure the code was logical and valid. Then I created a basic stylesheet to serve to NN4 and from this imported other relevant style sheets.

The first main stylesheet I created was layout.css which not surprisingly controlled the layout of the page. I built this stylesheet up step by step, starting with the main elements then slowly getting more specific. Like most of my CSS work I try to keep the flow of my CSS files similar to the flow of the document, as I find it easy to locate styles this way.

Once the layout started coming together, I created a stylesheet for the text styling and then a separate stylesheet to handle the CSS rollovers in the site nav.

Once the basics were done, It was time to start browser testing. If you look at the stylesheets you'll see that each one has a version number (currently 0.9). Basically during the testing phase I'd fix an issue, save a version of all the files and then move on to tackle the next issue. It's a minor thing, but keeping template version numbers in the CSS files helped keep track of which files were the most recent, and which XHTML templates they related to.

Once the final XHTML and CSS templates were done, everything was looking rosy. I came across a few issues, mostly involving mysterious gaps appearing in IE/Win because it couldn't handle training whitespace in the code. However I was surprised that all the bug's and tweaks were very minor.

The CSS code was looking quite nice at the template sign-off point. However the production schedule on this job was really quite tight, so when it actually came to building the pages, lots of page specific styles had to be created and unfortunately the nice structure of my CSS files broke down a little. Also these later additions were fairly poorly commented.

Some pages needed their own specific styles and I was initially planning to create a few separate stylesheets. However Jeremy suggested writing an ID to the body tag, allowing individual page styles to be controlled by the main stylesheets, making his programming job a little smoother.

Overall I think the site has worked well. It validates, is relatively clean and reasonably semantic (considering the time pressures we had). Apart from one or two omissions (e.g. no skip nav links or form groups) the site is reasonably accessible and would pass a Bobby AAA check if you've got a fairly open mind (and don't read the user checks too literally).

What I'm most chuffed about is having the ability to do a site for a well known brand in CSS. There are so few big brands out there building sites using web standards, I'm fairly pleased that we've released another one into the wild.

[site and client details removed at the request of the client]

Comments (2)

Tableless design is big in Brazil | September 8, 2003

A while back these guys emailed me to let me know they'd featured the message website on their Brazilian site about tabeless design. The site looked really useful but unfortunately was all in Portuguese so I didn't understand a word of it. Then last night I had the bright idea of running the site through Bablefish and hay presto, the site now makes some king of sense. The translation is a bit sketchy but the site makes a hell of a lot more sense than it did before.

One of the things that most impressed me by this site was the large number of CSS makeovers they featured. These included tableless versions of the Adobe, Google and Apple websites.

Well woth a look if you've got 5min.

NOTE: was going to knock up a quick Bablefish bookmarklet but then came across these two:

Comments (1)

BBC web site makeover | September 6, 2003

Inspired by Doug Bowman's recent version of the new Yahoo search page, Pidster went looking for a likely target to test his CSS makeover skills. He didn't have to look far, selecting the BBC's news page as a worthy target.

In a homage to changing rooms, Pidster took up the mantle of makeover superstars Handy Andy and LLB, and set about turning BBC tag soup into valid mark-up. At the moment Pidsters version of the BBC news site is only in phase one and he himself admits that the CSS is a bit *nasty* and the page needs more testing.

However being a paid up member of the W3C, I hope this will be one makeover the owners will not go ballistic about.

NOTE: A recent article said that the majority of W3C members sites didn't validate, so if you want to get on the web site makeover bandwagon, This would be a good place to start.

Comments (1)

Macromedia.com | September 1, 2003

Just had a look at Macromedia.com this morning and was surprised to find that it's using CSS layout.

Last time I looked the nav on the home page was in CSS but everything else was table based and the nav on other pages was still done in Flash, something pointed out by Todd Dominey.

As yet the pages don't seem to validate as XHTML but this mostly seems down to not closing a few br tags.

Comments (0)

Great commercial CSS site | September 1, 2003

Ryan Carver has done a really good job with his latest project, One True Fit for Lee Jeans. The site is a great example of a well designed, commercial site using CSS/XHTML. If you want to find out more about the site, Ryan has put up a page explaining the techniques he used to create the site.

Nice work Fella!

Comments (0)

CSS, Web Standards and Accessibility | August 29, 2003

There have been some good articles and posts on various blogs of late about CSS, Web Standards and Accessibility. Here's a selection of some of the best ones.

Comments (0)

Nice Blogs! | August 29, 2003

For all you folks that haven't come across hicksdesign it's well worth a visit. The site is a beautiful example of CSS based design and should provide inspiration to us all.

Poking around in my comments I also came across this little gem from Jeff Croft. It's still under construction (aren't most blogs though?) but is already high on my reccomendations list.

Both these blogs have a few things in common. First off they both make use of overflow: auto to create a scrolling "frame like" area for the content. Normally frames and their ilk bug me but in both these instances I feel they work really well.

Both blogs also make really nice use of colour. They both use a combination of orange and green. Hicks Design going for the fresh, natural look which Jeff Croft uses solid blocks of saturated colour to good effect. I find most blogs (including this one) tend to be a little on the plain side so it's good to see bloggers making more use of colour.

Lastly they typography on both sites is really nice. The titles are clear, the text is well spaced and generally the posts are very easy to read. It's a small thing, but so few bloggers seem to think about how to display their posts. Good clear typography can make a huge amount of difference.

I'm always on the lookout for nicely designed blogs and CSS based sites, so if you know any good ones that aren't already on my links page, please let me know in the comments below.

Comments (9)

Eric Meyer on Floats | August 27, 2003

Eric Meyer has written an interesting article outlining a problem people often have with floats. Eric explains that in actual fact it's not a bug but the way floats are intended to work, and offers some useful solutions get round this issue.

Comments (1)

Another Altruistic Redesign | August 27, 2003

Paul Scrivens has created a standards compliant version of Google and ponders the pros and cons of this famous search engine converting to web standards.

Alltheweb converted their sites to a CSS based layout some time ago. For such a popular site, shaving even a few K off the file size would probably provide a big bandwidth saving. However alltheweb have gone one further providing themed skins and allowing you to create your own customisable stylesheet. Erik Bator worked on this design and talks briefly about the reasons alltheweb chose to use CSS and web standards.

Comments (0)

Flash Satay Experiment | August 19, 2003

Should you or shouldn't you use the Flash Satay method of embedding flash content?

What browsers does it work on and how many people will actually be serverd the flash movie correctly?

Fill in this poll and help answer that question.

Comments (0)

Creating form layouts using CSS | August 19, 2003

A while ago I read an article at A List Apart about creating form layouts using CSS that you would normally use tables for. It was a great little article, but I could never quite get it to work.

I was trying to lay out a form today using this method, but it kept breaking in IE 5.x on Mac. Basically it displayed fine on all other browsers, but on IE5 Mac each subsequent row was being indented slightly.

Here is an example of what was going on.

I tried playing around with clear div's (see previous post). I added a clear div inside each row to make sure the row actually took up space. Then I added a clear div after each row and for some reason this fixed the problem.

I'm not sure exactly what was going on here, and I really don't like the fact that the form is now stuffed full of nasty clear div's. However it works in IE5 on Mac which is one thing. If anybody knows a better way of getting it to work, please let me know.

Comments (11)

Clearing Floats | August 19, 2003

As most of you probably know, when you float an element it no longer takes up any space in the document flow, causing borders and background colours to behave strangely.

To get round this you need to add some content to the container element and set that content to have a clear: both; style. Most people do this by using either

<br class="clear" />

or

<div class="clear"> </div>

However I found a number of problems with both these methods. Firstly they both add extra vertical space. Often this is OK, but in precisely controlled layouts this is a problem. Using the <br /> also produced problems and I was told on the css-discuss list that you really need to use a block level element like a div to get it to work in all browsers.

While on my usual internet trawls I came across a site where the owner had tested a wide variety of methods designed not to produce extra whitespace. I'd love to give this guy a credit but I can't for the life of me track down the site. If I do i'll post up the details.

Basically instead of using a no breaking space inside a div, it was suggested that an empty comment tag was used instead.

<div class="clear"><!-- --></div>

And that the styles contained a height declaration as well.

.class {
  clear: both;
  heignt: 0;
}

This may not be news to some, but It's something I've never come across before and seems extremely useful. I know some people will see it as a bit of a hack and it could spark off the whole design vs semantic mark-up debate again. However there are times when you really need to use hacks and this one seem to be doing a good job so far.

Comments (3)

More Altruistic Redesigns | August 14, 2003

Tom Gilder has done a good job of creating a standards compliant version of the Mozilla site.

In a similar vein, Douglas Bowman has turned his skills towards redesigning the new Yahoo search page.

The trend continues. Who will be next?

Comments (1)

How I Organize my Stylesheets | August 14, 2003

A couple of weeks ago there was a big discussion on css-discuss about how people structure their CSS files. Here is what I do.

First off I try to break my styles down into logical chunks. I'll have a basic stylesheet that I'll serve up to Netscape 4 and within this I'll import the more advanced style sheets. On a simple site this may just be a single stylesheet, but on more complicated sites I'll break this stylesheet down further, usually having one for layout and one for styling. On the Message site The nav was a complicated little problem on it's own, so I gave it it's own stylesheet. I also used the FIR image replacement technique on the homepage headings and so created a separate heading stylesheet as well.

This breaking down of styles has two very useful results. First off it makes it very easy for me to find styles. If it's a layout style I need, I simply go into the layout stylesheet, whereas if I want to change fonts or colours, I go into my styling stylesheet. It also makes bug fixing easier. If I find a difficult problem I can stop importing one or more of the stylesheets to locate which stylesheet the bug is in.

Within the stylesheets I tend to add styles relating to their position in the flow of the document. Anything that is page wide I'll add at the top, then I'll add styles for my headers/branding, my nav, content and then footers (assuming thats the order these elements appear in the page).

Some people have suggested odd methods like having all the id's first, then the classes and finally the html elements, or setting everything out in alphabetical order. This is great if you can remember the type of element or it's name, but not much use if you can't. By laying everything out as it appears in the document, it's much easier to find the style you want. Also because you styles are following the flow of the document you're less likely to get any odd cascade problems.

Finally it makes life a lot easier to debug the code. I sometimes need too comment out chunks of CSS and HTML to locate a bug. It's much easier to do this if you know that the chunks of CSS you comment out are in the same order as the HTML, rather that having to comment out lots of sections in your CSS just to isolate one section in your HTML.

Comments (8)

Avoiding Tantek's "Box Model Hack" | August 13, 2003

If you're a CSS developer you'll know that IE5.x gets the box model wrong. Padding and margin should actually be added to the width of a box. However IE5.x includes padding and margin within the width of the box. An annoying bug that can really mess with ones layout.

Luckily Tantek Celik came up with a clever, ugly hack to get round this issue. I've used this hack on a number of sites but, when building the new message site, I found a much more elegant solution.

Somebody on a web design forum (can't remember who or where) suggested that in most cases you didn't really need to use this hack. What you do is simply set the padding/margin of the element your interested in, and then set the width on the parent element. This may mean creating a parent element (a wrapper div) solely for this purpose. Not great, but much less messy than using the box model hack.

Comments (12)