/CSS/ A positive attitude to development
11/09/2006 | Filed under Develop > CSS
The beginning: the best way to ensure your CSS is going to work properly is from the ground up. John Oxton sets the standard for his series on development with CSS. Are you ready to keep up?
The most important weapon in any CSS developer’s arsenal must be well-written HTML. Without it there is no hook from which to hang your hat or canvas on which to paint your masterpiece. But so often HTML is overlooked and written off as unimportant. It’s no surprise, then, that cascading stylesheets have become, to some extent, a mystery to developers used to being able to use tables to create robust layouts. Fortunately, good HTML helps to demystify the CSS that then shapes it.
For a long time HTML has been doing a job was beyond its original remit. The web today is way more advanced than perhaps its creator could have imagined or hoped for, and as a result, HTML sometimes doesn’t seem to have enough tags to describe the content at hand. Generally speaking, though, the tags we do have are sufficient to get the job done, it just takes a little thought and care.
Here’s a common example I often come across when looking through a site’s source code:
<p><b>This is the main page heading</b></p>
Lets look at the example above and target it with some CSS. For the sake of this exercise let’s say we want the main heading on the page to be in big blue letters. The CSS might look as follows:
font-size:3em;
color:blue;
Applied to the <p><b> this is the main page heading</b></p> example the CSS might then look like this:
p b{
font-size:3em;
color:blue;
}
All very well and good up until this point further down the page:
<p>So I said to him, <b>you’re a bloody idiot!</b></p>
As in the code snippets above, the content within this <b> tag will also be blue and three ems high. Given that I’d had hoped to style the main heading of the page to be distinct from the rest of the content, that’s not good news. It makes much more sense to use the available HTML tools to reduce the amount of mark-up needed in the process and even make it more accessible. So the above code will become:
<h1>This is the main page heading</h1>
This approach helps to describe the kind of content we’re dealing with and enables us to target it far more accurately with CSS. Doing this will also aid accessibility because, at the most basic accessibility level, headings can be useful for navigating quickly through a page.
So the CSS for our main page heading may now look like this:
h1{
font-size:3em;
color:blue;
}
The <b> tag page is, of course, left untouched and can be styled independently.
Valid HTML
When I started hand coding HTML, I became obsessed with valid mark-up as defined by the W3C validator (validator.w3.org) and I still use it almost daily. I have learned, however, that valid HTML is not the absolute end of the matter, nor is it always possible to create it. There can sometimes be perfectly logical reasons why your HTML won’t validate, and I think it’s more important to understand why your HTML won’t validate and decide if that’s an acceptable reason than trying to bang a square peg into a round hole. Of course, the zealots will have my head for this line of thinking. My rule is: validate if there are problems with a page.
Semantic HTML
The truth is that HTML is not, semantically speaking, a very rich language. An <h1>, for example, will tell us that the element is a level one heading but it won’t give any real meaning to that heading. Let’s say you wanted to use a collection of level one headings to break a page into distinct sections, it would be very difficult, using only the HTML elements as a guide, to then identify just what section each heading serves. This is the point at which classes and IDs enter into the game:
<h1 id=”heading_Welcome”>Welcome to my one page website</h1>
…section contents
<h1 id=”heading_About”>About me, myself and I</h1>
…section contents
<h1 id=”heading_Contact”>The many ways in which you can get in touch</h1>
…section contents
I used IDs in this example because I’m 100 per cent sure that each of those headings is unique and will never occur again on the page. I could have easily chosen to use classes but these IDs also provide us with a handy navigational tool. Using the anchor tag (<a>) we can easily jump to and from each section using the ID of each to identify the section. So, for example, in the Welcome section we may have the following code enabling users to jump straight to the About section:
<p>Welcome, this is my site about me, let me tell you all <a href=”#heading_
About”>about myself</a>.</p>
The other thing worth discussing is the way I have structured the IDs: heading_ Section. Some might argue that it’s obvious it’s a heading when it’s clearly embedded as an attribute in the <h1> but when the ID finds itself in within the external CSS file, separated from its HTML tag, suddenly that additional bit of semantic information becomes useful to a human author. This is how an HTML document can be made semantically richer.
Generally, I tend to work with classes and IDs in a way that suits me, or the project I am working on, rather than conforming to some formula put forward by someone else. I always try and do a little planning first. Of course, I find myself developing routines and bad habits, so reviewing the process from time to time and seeing what others are doing is no bad thing. If I’m lucky enough to be working with other developers on a project, I usually try and get a consensus on how we’ll structure IDs and classes.
The one big no no is adding presentation information to classes and IDs. For example an ID of heading_DarkGreen might seem like a good idea until we change that heading’s colour to light pink, at which point we discover our ID is semantically useless.
Tables
Once you’ve mastered table-free layouts it’s hard to consider any other way of going about it. You’d have to hold a loaded water pistol to my left testicle to get me to use tables for layout. But they are not the worst crime you could commit. In fact, when I was first considering CSS as the way forward, I continued to use a table or two for layout.
I remember feeling that tables were in some way more robust than divs or other HTML elements positioned with CSS. To some extent this is true: tables behave consistently in most browsers, divs and CSS do not, although that’s changing quickly now.
It’s a complete myth that only a table-free layouts make your site accessible. Lots of nested tables should be avoided at all costs, but using just a single table to help you lay out your header, columns and footer, and to get the basic shape of your site is not a big deal and your site can still be accessible. You might like to read Andy Budd’s article on the subject of tables (tinyurl.com/p9alx), it’s two years old but it still raises some interesting points.
CSS hacks
It seems like only yesterday that hacking the hell out of CSS was all the rage. A star hack here, a box model hack there. You could spend hours trying to wrangle Internet Explorer 5, 5.5 and 6 into shape. Then Microsoft announced IE 7 and told us it was intending to find a solution for all our CSS problems. There were also rumblings from the IE developers about tidying up all those hacks we’d created in order to get the browser working in the first place. Everyone quickly came to the conclusion that perhaps hacking CSS was not a good idea after all.
There’s a lot of drama surrounding the release of IE 7, and I’m sure on the day of its full release there’ll be a lot of websites that break because of hacks, but hopefully, at least as many of them will just carry on working, too.
If anything the arrival of Internet IE 7 reminds us that things will always move forward and we have to keep that in mind. We still need to deal with older versions of Internet Explorer, of course and current thinking seems to favour Microsoft’s own conditional comments (tinyurl.com/x113) to deliver specific CSS to each version of IE. Perhaps the only other thing to consider is trying to design the user interface to avoid the need to hack it in the first place. It’s easier said that done, of course, but it helps if you try to remember to keep everything simple.
Browsers
I think you have to be a browser collector if you decide to be serious about CSS. I have Opera, Firefox, Mozilla, Camino (my browser of choice), Safari, Internet Explorer 5, 5.5, 6 and 5.2 on OS X. Additionally, I keep Lynx in my arsenal (lynx.browser.org) to test my site without JavaScript and CSS applied.
King of the browsers for development must be Firefox, if only because of Chris Pedrick’s Web Developer Extension (chrispederick.com/work/webdeveloper), which provides a suite of very useful tools, such as a toolbar that enables you to debug the page visually, while digging into the underlying code. More recently FireBug (addons.mozilla.org/firefox/1843) has been released to rave reviews and looks set to keep Firefox ahead of the pack.
That’s not to say other browsers don’t offer plenty of useful tools, they do. Opera, for example, has a list of User modes, which can be found under View > Style and these are particularly useful for testing out how your HTML will react to an end user applying their own style sheets (it doesn’t happen often but it does happen). Jon Hicks, king of the browser geeks, also recently wrote a piece on using Safari for web development, which can be read at www.hicksdesign.co.uk/journal/web-development-with-safari.
Mobile browsing is still a work in progress, but Opera Mini looks like a strong contender. I have been surprised by how well my CSS sites actually render on a mobile browser, though I can see areas where it might be improved. It’s something I will be covering in future tutorials.
When it comes to developing a browser support selection process, I’d thoroughly recommend making use of Nate Koechley’s Graded Browser Support at developer.yahoo.com/yui/articles/gbs/gbs.html. Unless I have specific user statistics for a website, this is the model I now favour.
Accessibility
The word ‘accessibility’ seems to give most web designers the fear, these days, not least because it may one day become a legal matter. In reality, though accessibility is really just a fluffy kitten, and aside from the occasional playful scratch from it’s claws, accessibility can become your special friend.
I think the biggest mistake I’ve made in the past when approaching accessibility is to imagine that it simply means catering for the needs of people with disabilities. This is not true, though that in itself is reason enough to comply with it. These days I summarise accessibility as making your web pages accessible to as many devices and people as possible. This might include printers via a simple print stylesheet, mobile devices via a handheld stylesheet or simply by considering how a person with colour blindness might navigate my site.
I have also, long ago, come to the conclusion that unless I have quite specific user statistics for a site, there’s no way of covering all the bases, so it’s important to try and instill a culture of accessibility right at the start of any project. Explaining the business benefits of accessibility is much better than threatening clients with the Disability Discrimination Act. It’s such a grey area that until a large company has been sued in the UK, we can never be sure what true accessibility really is. Over-committing yourself to the latest accessibility techno-babble might just back fire on you.
The web standards community
Compared to some people I joined the web standards revolution quite late in the game and a lot of the hard work seemed to have been done already. Although the job is far from over and it seems that we can all contribute and help things move forward, even if it’s just by encouraging conversations to start or asking questions. It’s really quite amazing how much information is out there, though, and as long as you can describe your problem to Google, it’s almost certain that someone will have solved it already.
There will always be the trailblazers, the leaders of the field who enjoy solving problems and coming up with new techniques, and for that reason it’s worth seeking out and becoming a part of the web standards community.
Where do we go from here?
I know a number of web designers who are still only flirting with the idea of moving from tables-based layouts to a CSS way of development but remaining unsure about how to find the time to retool. Perhaps they’re thinking about it in the wrong way: I eventually switched by selling the idea to my clients first and working out how to do it afterwards. That level of expectation was motivating, but also one of the most prolonged periods of stress I have ever experienced and I wouldn’t recommend it to the faint-hearted. Three months later, however, I had one fully blown HTML and CSS-driven site under my belt and I’ve never looked back.
None of the work I have accomplished would have been possible without the help of the Web Standards community. Time and time, again I end up at: www.456bereastreet.com, a veritable gateway into the community.
And now it’s over to you. Over the next few issues, I will be covering a variety of topics and methodologies. I have provided an overview of my perspectives, the way I use CSS to achieve my goals and the tools I use, but I need to know what you want to learn about. Let me know your thoughts and opinions on CSS, as well as anything you are having particular trouble with and we’ll tackle it together.
Despite John’s confidence, advanced CSS can still be a daunting prospect. If you would like any specific topics to be covered in this tutorial, please send your requests to John at dotnet@johnoxton.co.uk, or visit our forums.
Bookmark with:
Comments
Brendan Bacon / 21/09/2006 / 10:51
Issue 155 of .net's article '/css/designing simple, accessible forms' offers readers a link to 'Files online' which does not exist (www.netmag.co.uk/files/forms.zip). Can you tell me where this link can be accessed?
Jake Xu / 21/09/2006 / 13:40 / http://www.netmag.co.uk
Hi Brendan,
I had a look at that link and the file is there for you to download. Can you please try again? Type in the URL in your browser and select to download and save the file on your computer.
Regards
Jake
James / 14/03/2007 / 09:18
Hi Bredan or any other fans of Bredans articals,
I love learning about css, was wondering if I can apply CSS to my 'real works' emails that I send to our memberships base, or is it a waste of time. Tables are so bloody clumsy!
Wondering if I can l can remove the loaded water pistol point at my testicle.
cheers
james
Adam / 05/06/2007 / 17:19 / http:www.cubixstudios.net
i love CSS but i hate the hacks that are needed, some of the logical code you'd normally use just falls to pieces in IE
plamen / 25/10/2007 / 16:05
CSS is just lovely. i use it all the time. Tahnks
Mike / 10/07/2008 / 16:22 / http://www.trcreative.co.uk
A nice read that takes me back a few years in the web design industry, think most people have made the jump from tables to CSS.
