CSS is not hard to learn – if you recognise it for what it isTuesday, October 4th, 2005 at 9:45 am
On almost any mailing list or forum you still encounter developers venting their frustration as to how buggy CSS is and how hard it is to switch from table layouts to CSS layouts. A lot of this frustration is not based on bad browsers or missing elements and concepts in CSS, it is based on an old school view of web design. Web design was never easy, but it can be if we start embracing the complexity of our development environment and be flexible enough to develop for it.
Tables were not easier
I doubt that anybody making the claim that table layouts are a lot easier was around when the browser wars were in full swing and the visitors largely used Internet Explorer 3, Netscape Navigator or Netscape Communicator. It was not easy at all to make a table layout that didnï¿½t break apart when the content changed. It was also not easy to change the look and feel when a redesign was due, unless you planned your tables properly and used the server to your advantage via includes and variables. I remember writing a toolbar for Homesite 3 in 1998/1999 that allowed us developers to generate ï¿½bullet proofï¿½ tables instead of having to remember all the tricks that had to be done to make tables behave. Those who had to suffer the same horrible technology may remember the stunts:
- Table width attribute set to 1
- Row of transparent GIFs to define the whole width of the table with repeated width definitions in both the image and the TH/TD elements
- Tables cut up into several tables to allow rendering of one table after the other rather than having to wait till Netscape rendered the whole table.
- Font settings in each TD, as the rudimentary CSS support meant losing the font definition of the parent element in table cells.
It took us about 4 years to get out of this mess, and now we repeat the same mistakes we did back then. We donï¿½t seem to have realised how lucky we are: Browsers are not all bad; some of them are pretty amazing in what they do. I wouldnï¿½t want to write a browser engine catering for all the options HTML and CSS gives us while trying to please the marketing department and ensure security.
Instead of embracing the diversity of the web and its hundreds of possible user agents and user agent settings, we try to enforce a rigid structure.
How often have you heard:
We need to use a table here, as all the columns need to be the same height and we donï¿½t know their content.
An equivalent of that would be:
We need ducks in this pond, as otherwise it will overflow with bread thrown in by old ladies.
The content makes the design, not the other way around. A design that constrains the content or ï¿½ even worse ï¿½ expects different content to take up the same dimensions – is bound to fail, regardless of technology.
Browser vendors realised that not the developers, but the users are the important group to cater for: Nowadays users have a lot more options to override what we think is best for them and make the web site display in a way they want or need. The inbuilt RSS viewers of Safari and Opera are pretty nifty, and browser add-ons like Mozillaï¿½s DOM inspector, Aardvark or Adblock allow us to get rid of unwanted elements of a page to make it more usable for us. Opera has a very extensive user view option that even allows serialization of tables and removal of colours or fixed dimensions.
We use these things as developers for testing, and yet we delude ourselves into thinking that we know what is best for our visitors. These gadgets were implemented for the users, not for us.
I am going to make a bold statement now, but almost 8 years experience of web development taught me this:
A web page that looks and works exactly the same across different browsers is most likely neither accessible nor easy to maintain. A web page that is well structured, allows for flexibility and improves visually with the sophistication of the user agent is both.
The media attribute or selector of the style directives in HTML and CSS define screen, and print (amongst others), but not ï¿½Internet Explorer 6.0 on Windows XP2 with a screen size of 1024×768 and full window with the font setting to mediumï¿½. A CSS style sheet defines how a user agent should render the page, it is not a native program to the browserï¿½s rendering engine triggering a set-in-stone outcome. Much like an XSLT style sheet converts hundreds of XML documents to another XML format; CSS does this for user agents and their modes (print, screen). You wouldnï¿½t try to use the same XSLT for a PDF generation and XHTML conversion, and still one CSS is supposed to cater for all and deliver perfect results.
CSS is dead easy once you learnt to let go of the fixation to try to constrain everything. A good web page design should allow for:
- changes in the amount of content
- changes in the size of the font
- various viewport sizes without forcing the visitor to scroll too much
I will not get into the ï¿½fixed vs. liquid vs. flexibleï¿½ layout discussion ï¿½ personally I have no problem with flexible width; if a text is too wide to be readable I resize my browser window. On the other hand, if you fixed the width and I have to scroll on a 1024 resolution I simply leave your site.
So how can we make ï¿½easy CSS layoutsï¿½?
There are some tricks to avoid frustration when developing web sites with CSS:
- Cross-Browser means ï¿½functioning in different browsersï¿½ not ï¿½looking the sameï¿½. Donï¿½t go back and forth between browsers and compare ï¿½ no user would do that. Surf the whole site in one browser, then in the other and see if there is a consistent experience throughout the whole site with the same browser. If there are terrible bugs preventing the visitor from using the navigation or being unable to read the site content because of overlapping sections then you need to fix them. If there is a 2 pixel shift when the font size is nudged up two measures and that infuriates you then you really need some real problems in your life.
- Donï¿½t limit the height of an element that contains text. You cannot have multiple columns with the same height and different content (you can simulate it with background images and colour but there still might be instances where it simply will not work). Furthermore you cannot have a text that is as high as an image next to it.
- Allow things to grow: You can use a background image that reveals less or more according to the content of the element it is applied to, or you can make the image fade onto a background colour and fill the rest of the element with that one. This will allow for text resizing without awkward gaps.
- Donï¿½t use any padding and margin on main layout elements – you are simply asking for cross browser problems (yes, MSIE). If you fix the layout width, then fix it for all the elements and use margin and padding on the elements added to the layout DIVs. Try to avoid percentages as there are some nasty rounding bugs. Especially gutters defined as percentages are tricky: A 5% gutter of 1024 pixels may look enough, but the same will fail on 600-700 pixels.
- Donï¿½t expect the content to follow any amount rules. ï¿½This design can have 6 horizontal links in the menuï¿½ might work for English on medium font setting but will break into several lines in Finnish, German or when the text is resized. A good navigation can break into several lines, but tabs do look confusing if they do.
- Use background images for borders, instead of borders. It saves you the trouble of having to calculate the extra widths into the overall layout equation.
- Use larger background images than needed and position them to allow for elements to expand and contract.
- Use background images on the parent element for bullet points. This allows links and other list elements to wrap onto another line without bad wrapping:
- Assume growth, no matter what the client tells you. There is no such thing as a ï¿½5 page web siteï¿½. Any web site does involve the same planning and structural thinking, no matter if it has 10 or 10000 pages in the end.
- Develop with content in place. Preferably real content that will be on the site later. A lot of CSS grievances happen because of empty elements. Content will make them snap into place and behave in most of the cases. On the other hand, content also shows you where you need to cater for more space.
The main trick is to know what will be put out on the web. If there is no Information Architecture, sample content or even an idea how many people will use / edit / publish on the site it is almost impossible to develop a good web site and it is tempting to restrain your designs to what is most convenient. A web site is not a brochure, its success is very much dependent on it changing over time and solving even more problems or needs our visitors have.
Update Can you create flexible and clean CSS? Prove it by participating in the CSS Toolshed