When I first encountered Cascading Style Sheets in the autumn of 1998, I was trying to do cool stuff—make this stuff over here move, make that stuff over there change color—and it took another six months before I started using CSS to control presentation rather than behavior.
It took me two years to break out of the comfortable prison of layout tables, and another two years before I could use CSS to produce layouts that were originally intended for tables.
Even though I was forced during that time to deal with such anachronistic works of art as Netscape 4.0 and Internet Explorer 5.0 for Windows, the moral of the story should be clear: it took me a long while to achieve genuine mastery of CSS.
There are plenty of excellent books and articles out there, including many written by the contributors to this publication. While most of those works gracefully walk the inexperienced developer through challenging layouts and teach by literal example, few of them acknowledge that using CSS to create standards-friendly sites requires a mindset that is alien to many experienced developers. This requirement hamstrings a lot of talented people, and for two years I’ve been looking for the words that will heal their pain.
The cries of frustration I hear from other developers about CSS are only an echo of the ones I made for years. As a result I like to think that I can relate, and I’m writing to convey the most important lessons I’ve learned so far.
Lesson No. 1: Everything you know is wrong… sort of#section2
Just so we’re on the same wavelength, I want to underscore the fact that if you’re starting to work with CSS, everything you’ve learned to this point probably feels useless, or worse than useless. That’s a problem that needs to be dragged out into the open and shot with the utmost speed and mercy.
Unaffected is the body of wisdom you’ve acquired on subjects like design, optimization, user experience, programming, and project management. However, the assumptions under which you’re accustomed to applying that knowledge change—sometimes drastically—when you switch to standards-friendly production techniques.
As a result, the best thing you can do is give yourself a clean slate. Throw out your assumptions and expectations. For that matter, throw out everyone’s assumptions and expectations. Roll up your sleeves and learn something new. When it comes to layout and production, resolve to remove “but” and “should” from your professional vocabulary for a while. Replace them with “how” and “why”—and commit to meeting your project objectives.
At the implementation level, this lesson is about the differences between table markup and semantic markup:
| Table markup | Semantic markup | Implications |
|---|---|---|
| Linear | Hierarchical | Design for the information, not in spite of it. |
| Procedural | Functional | Put things where they belong. |
| Location-based | Contextual | Let the markup describe what something is, before you let it describe where something is. |
| Defines constraints | Defines domains | You don’t need to push the envelope, because it will change its shape to suit your needs. |
Finally, don’t forget that there are things layout tables can do, and then there are things CSS can do. Some of these capabiities are mutually exclusive, and this doesn’t diminish the power of CSS.
Lesson No. 2: It’s not going to look exactly the same everywhere unless you’re willing to face some grief… and possibly not even then#section3
There are an awful lot of differences between rendering engines, and the W3C specs sanction those differences. You can adjust, tweak, hack, and waive, but if you want to preserve your social life, you will learn to let go of the small differences—and convince the stakeholders in your projects to do the same.
Lesson No. 3: You will be forced to choose between the ideal and the practicable#section4
Life and work often become series of compromises, especially when things are in a state of transition. The best thing you can do to ensure compromises in your favor is to plan effectively.
From time to time, though, you can expect to encounter situations where you will be forced to choose between the lesser of two evils, or perhaps even situations where you will be given no choice at all. Sites that are incapable of passing accessibility or validity tests will result, and you will be forced to accept those outcomes even when your contrarian assertions are absolutely correct.
Appreciate the objectives of your projects. Acknowledge workplace politics. Decide what is most important to you as a professional. Concede that the decisions of others made over your objections, much less those made without your input, do not reflect on your skill or integrity a jot (though they may reflect on the wisdom with which you choose your project sponsors). Choose your ground, pick your battles… and fight the ones you can actually win.
Lesson No. 4 (with thanks to Antoine de Saint-Exupéry): Perfection is not when there’s nothing to add, but when there’s nothing to take away#section5
When producing markup for a standards-friendly site, it’s all too easy to stick to the table-based way of doing things and create an over-abundance of container elements. While at first it may seem like common sense to force the markup into the design, doing so misses the point of standards-friendly production.
Don’t force anything, and don’t add markup unless context encourages it. Focus on the information first. If you’ve got several instances of content that share the same purpose or classification, don’t be afraid to stick them inside divs or spans that share a class named in a way that describes that purpose or classification. If you want to put body copy inside a container element that’s common to all of your pages, most people won’t fault you.
If instead you’re going crazy with divs because you need certain widgets to be present at particular layout coordinates (or have other seemingly unique presentation requirements), chances are you’re not thinking through your design completely. As a consequence, your markup will be even harder to maintain than the table-based markup that you’re trying to replace.
Remove tags wherever possible… while keeping the next lesson in mind.
Lesson No. 5: Some sites are steaming heaps of edge cases#section6
In many cases, the person responsible for a site’s graphic design is not responsible for any other aspects of site implementation. When paired with a failure to create strict site- and section-wide wireframes, this lack of accountability results in unique comps for too many pages, and thus a lot more work for the stylist and producers.
It has been this writer’s experience that such an outcome is far more common during small projects than large ones, which leads to those small projects going egregiously over budget. I invite the reader to consider the implications of that fact.
Whenever possible, encourage the graphic designers with whom you work to respect the imperative of consistency. If your encouragement has no effect, make sure to stick a unique id on the body of every page of the site, and enjoy the bright side: there’s no doubt that you’ve got a living.
Lesson No. 6: Longer lead times are inevitable#section7
Browser vendors had five frenetic years to work out a uniform and reasonably stable approach to table rendering, and that task was made easier by the fact that until Gecko and KHTML were released, most rendering engines had a great deal in common—Mosaic begat Netscape but was also licensed to Microsoft.
The state of CSS rendering technology is comparable to the state of table rendering technology in early 1998… so give it time, and test your layouts diligently in the meantime.
The good news is that the time needed to test and debug your layouts is repaid after launch by the reduced time spent on maintenance, extensions, and revisions.
Lesson No. 7: Coherent and sensible source order is the best of Good Things#section8
If you deliver work that reads properly when styles are removed, your thoughtfulness will repay you many times over. Such a practice carries many benefits, including:
- A site-wide print stylesheet replaces separate print-only pages.
- Stylesheets are easier to document, normalize, and maintain.
- Interspersal of markup and scripting on site templates decreases.
- Keyboard navigation of the site becomes considerably less painful.
- When the site is redesigned, there’s no need to rearrange the content all over again.
Lesson No. 8: Descendant selectors are the beginning and end of genuinely powerful CSS rules#section9
When you begin the transition from table-based layout to standards-friendly production, it’s tempting not only to go crazy with container elements, but also to stick classes and ids all over the place.
Of course, you usually don’t need to. For an example, consider an element intended to contain navigation links. A common beginner’s mistake is to build the whole thing with divs, which offends purists because doing so makes things more difficult for users of screen readers.
Since divs aren’t the ideal solution, we can use unordered lists instead. Screen readers accept commands to skip those. Thus, a “good” navigation element is an unordered list of links. A conscientious developer might put an id on the list for the sake of positioning, and classes on the links, so that they can be distinguished from all of the other links in the document.
However, in this scenario, only the id is necessary. The trimming in question is made possible by a descendant selector:
#nav a {
color: red;
}
In English, this selector says “all links within #nav should be made red.”
Here’s a more complicated example:
#bodycopy blockquote.critical {
float: right;
width: 30%;
padding: .5em;
margin: .5em;
}
The attributes in that rule would be applied to blockquotes assigned to the class critical, but which also appear within #bodycopy. This allows both plain blockquotes in #bodycopy and similar blockquotes in #sidebar to be styled differently, while minimizing the number of classes and ids that need to be used.
In effect, descendant selectors allow you to reduce the number of classes and ids in the markup and to keep a keener eye on context than is possible without these selectors.
When used in combination with background images and layout properties, descendant selectors make possible effects that tables can’t even begin to duplicate.
Lesson No. 9: In the real world, stylesheet hacks will get your project across the finish line#section10
Yes, stylesheet hacks are mildly disrespectful to the intentions behind the underlying technology. Yes, stylesheet hacks introduce the possibility of nightmares in the wake of a major change…such as the one that will take place when Internet Explorer 7 is released. Yes, the whole subject is an uproar waiting to happen.
This writer takes an unambiguous attitude on the subject. Given a choice between making excuses to a client about why something looks lousy in their browser or just fixing it, the latter decision settles up a pending invoice with far less pain and delay. When used wisely and with the appropriate caveats, stylesheet hacks make life a lot easier!
Lesson No. 10: Working around rendering bugs is like playing Whack-a-Mole#section11
By this, I mean that when a rendering bug in one browser is worked around successfully, it often results in the exposure of another rendering bug in another browser (or a different version of the same browser). When this happens, you can expect to step back and re-examine your entire ruleset… if not your entire stylesheet collection.
The good news is that there’s usually a way out of these apparent no-win situations, most of which can be found by a properly-tuned web search. Positioniseverything.net is an especially valuable resource in these cases.
Lesson No. 11: When you’re drowning in CSS layout problems, make sure of the width and height of the water, float without putting up a struggle, and get clear of the problems#section12
When you’re working with columnar layouts, unpleasant surprises are common. The best way to achieve an aesthetically pleasing columnar layout and sensible source order is to use the CSS float attribute. However, in order for this to work well, all of your columns need to have defined widths and, in some circumstances, defined heights as well. Without those widths and heights, the layout is rendered willy-nilly.
Additionally, you may find yourself ignoring Lesson No. 4 above in order to create the layout successfully. However, that’s one of the compromises I mentioned—a compromise hopefully made only after you’ve tried your best to do it some other way.
Lesson No. 12: Background images will make the difference between the plain and the tastefully embellished#section13
Thanks to the vagaries of the CSS box model, mixing proportional and fixed dimensions within a layout—in other words, attempting an elastic layout with lots of borders—is a sure way to disaster (or at least considerable grief). However, you can create the illusion of that mixture by creating well-composed background images and referencing them properly in your stylesheets. Self-directed experimentation is recommended, particularly with regard to the behavior of borders.
Another common task for which I believe background images are appropriate is the replacement of headings with bitmapped type. Though arguably contoversial, the practice of combining the background-position and text-indent CSS properties makes it possible to give search engines and screen readers what they need, while also providing the high-quality visual experience for which most graphic designers strive.
For the record, naysayers should know that I’ve yet to encounter any personal computer users who routinely browse the web with stylesheets enabled and images disabled. While that scenario leads to an intriguing intellectual exercise, I’m presently confident that it bears little relationship to the way people habitually browse the web in the real world.
In Conclusion#section14
The buzz about Web 2.0, CSS, and myriad other subjects of the bleeding edge can become a dull roar to those left ill-equipped for industry changes because of work habits adopted in good faith years before. It is my hope that the experience I’ve shared will help some folks to find a way back to the top of the heap—which is where the web needs you.
A good mix of general and specific points.
Whenever I hear someone the web standards movement is elitist and pedantic I am reminded of the argument that Zeldman made years ago. Standards are all about the bottom line. At the time I didn’t really understand that, because my own use of CSS grew slowly and it was hard to notice the improvement. But this year when I took a job at an agency where they still barely know what CSS is I discovered the painful truth. Bloated table designs can raise development costs by very large factors. Worse yet, they can create situations for application developers where templates balloon out of control and require baroque display logic that destroys readability.
The idea that your code needs to validate perfectly and not use any CSS hacks _is_ pedantic. Web standards in general, and CSS in particular is first and foremost _pragmatic_.
While I agree that validation must sometimes be sacrificed in favour of what is practicable, I’ve always found validation invaluable for learning new tricks.
With each site you work on the validation process will throw up another gem that you didn’t know about – whether from a standards-compliance or an accessibility point of view.
Yes, where the costs of validation outweigh the potential benefits, you’ll have to make a compromise. However, where the pain of transitioning to standards-compliant code is concerned, validation can be an enlightening experience.
Congratulations on this superb piece!
It’s really refreshing to read an article covering some of the issues we face concerning real world implementation of web standards. Far too many standardista’s dismiss any website that fails validation or uses a less-than-semantically-perfect piece of mark up due to an ill advised decision by a project stakeholder.
“Choose your ground, pick your battles”¦ and fight the ones you can actually win.” – This pretty much sums my past 3 years, struggling to introduce a web standards approach to a digital agency.
Bravo
I am always amused when someone talks about trading validation for some mysterious pragmatic reasons. Unless you are stuck with
crappy CMS or some system which allows html mess in users submited comments – I can see no reasons for tradeoffs.
Thanks for this good article. Sometimes it feels so much easier to stick to the “old” style of producing web pages and I understand that it takes years to adjust. For me as a programmer it might be not as hard as for a designer or artist. Im used to see aesthetic not only in the presentation, but also in the code. Therefore I totally agree to Saint-Excupery…
Right from the beginning you had my attention – because I was the same way. I KNEW the benefits of CSS – but it was psuedo CSS I was using, and it was still mixed with tables every now and then. I look back and laugh at some of my projects then – but it was all I knew. I then took the time to read read and read some more to really grasp CSS, the browsers, and how things are rendered.
I think this is a great article with some excellent points.
Another excellent article outlining the constant battle we all face when developing with CSS. My advice is to get stuck in and keep persevering. It can be de-motivating at times when having to use browser hacks (oh the irony) and it’s certainly not an easy ride and full of headaches, but the feeling at the end is worth it. There’s no real excuse with the acres of CSS related articles and resources out there!
It’s so refreshing to read an article on Web Standards that doesn’t vilify the thousands of quality, hard-working designers out there that weren’t exposed to CSS early on. I started my career in web design in 1998 and all the training I got was in table-based layout. It would be nice to just turn on a switch and say “I’m going to follow web standards now”, but I can’t. That’s like saying, “I’m going to start speaking Spanish today. It’s a much more efficient language.”
Now that I’m designing full-time, it’s really hard to find the time to train myself in the new standards (I actually enjoy getting away from the computer in my free time). So for me (and MANY others like me), it’s going to be a long road to completely saying “goodbye” to tables. Thanks for cutting us some slack. There are a lot of great designers out there that have just been a little misguided.
Thank you for outlining the numerous drawbacks and disadvantages of CSS. As a website optimizer I have to stick to clean markup and standards but I feel reminded of the days of Netscape 4 all the time. Back then we had to code JavScript for two different browsers, the HTML was quite the same on both major ones. Nowadays we have several brwowsers every one of them dealing differently with CSS and so called web standards. I would love those standards if they would work. Having to fight float and padding bugs and such on a daily basis I wish I could do table layouts once again. At least those work everywhere.
I quit flash programming a while ago because of it’s by now ludicrous complexity that renders it worthless for simple sites.
If I had an alternative I would also quit CSS. It’s a constant annoyance and you can’t even use more than the system fonts until now (we’re in 2006 and were supposed to have flying cars by now!).
The CSS believers are fighting a just war but in the daily routine CSS sucks. You have to make too many compromises and fight too many inconsistencies. Often I miss the crossbrowser compatibility of flash. I hope that one day we will be able to code websies in SVG, vector based and looking everywhere the same.
Great article. I’ll make sure to apply these on my upcoming project! I tend to have problems w/ CSS layouts @ times, but step 11 is a great reminder for those having troubles w/ layout and floats. Thanks!
The story of my life! These people are so friendly, but when they say “let’s try moving this link down by three pixels, just on this page” it’s like they’re _trying_ to make my life hell.
Ha! Yeah, and usually they’re looking at Safari and telling you to shrink text sizes without knowing that it makes the size too small in some browsers *cough all windows browsers which make up 98% of your visitors cough*
Sometimes you’ve just got to be stubborn and tell designers that such minute control is often pointless. Browsers display certain things, like text, differently. In the immortal words of Roger Miller: “You can’t rollerskate in a buffalo herd.”
If you’re making an effort, then it doesn’t actually take *years* to adjust, I think.
My introduction was meant to point out that I’m actually pretty lazy, like a lot of the folks I’m trying to address (when compared to the hardcore _standardistas_)… but that I saw the value early on. I was making an effort to be faithful to the spirit of standards from Day One – to the extent that I could, in the beginning.
For straight-up HTML production, letter-perfect validation only holds immediate tangible benefits if you’re taking your production the whole distance, and intending your site templates to survive for years to come. Unfortunately, most managers don’t see the point to that level of attention to detail. Thus my point about long lead times.
Also, I don’t want to be seen as _excusing_ laziness… but at the end of the day, we all need to maintain our lives. I think we’d all be well off to remember that the future of ten years ago is *our present*.
Finally, a piece of advice (per comment 10) that didn’t make it into the final draft is that when you’re working with floats, column margins are important, too.
Unaware that this article was due to be pushed, I started work several days ago on a new look and feel for my (incomplete) shingle site (henick.net). Other than accounting for two added IA elements, I haven’t touched the markup *at all*. I’ve spent six hours on the project so far, split between Photoshop and my text editor.
…Just sayin’.
bq. using CSS to create standards-friendly sites requires a mindset that is alien to many experienced developers.
Absolutely true – but it is a mindset that is totally alien to the vast majority of people. If you’re used to using any sort of WYSIWYG editor, which most people are, the paradigm shift to a structured document – even for those people who do properly use styles within their word processor (which few do anyway!) – is huge.
I’ve worked with intelligent and experienced writers to produce [printed] publications, and so many of them just can’t get their heads round the idea of structure. They want it to look a certain way, so they make it look a certain way – they have no concept of marking sections according to purpose. The thought that presentation is not integral to the document is, as you say, completely alien to them.
If we expect these people to begin to quickly comprehend the power and proper use of CSS then we are on a hiding to nothing. We need to remember, when we are preaching the gospel of CSS, that most people are not using table-based layouts because of obstinacy but because they simply don’t see why it is not a good idea.
bq. It’s a constant annoyance and you can’t even use more than the system fonts until now
Huh? Traditional HTML limits the fonts you can use, because you can only specify one font at any one time, so you have to choose a font that you know everyone will have. With CSS, you can specify less common fonts first, so that users with those fonts installed will have them displayed – and those that don’t have the font installed will have one of the fallback fonts used. And (theoretically) you can use CSS to embed fonts in a page so that even users who don’t have that font installed will see it. _Yes, I know that doesn’t work perfectly, but it’s better than anything HTML tables can achieve!_
bq. I hope that one day we will be able to code websies in SVG, vector based and looking everywhere the same.
Great. So it will look the same on WAP as it does on my 1600×1200 desktop monitor? And the same again when I print it? That’s impressive! It’s nice to know that it will sound the same as it looks when blind people have it read to them too…
This is exactly the problem that CSS faces – people who don’t understand the internet.
Web pages are not about pixel perfect rendering – if that is what you *need*, PDF is a better tool. Most websites don’t need pixel perfect rendering – they only need to get the content and some basic presentation across, and as long as the website has achieved that goal, it has succeeded. And if one user sees it looking slightly different to another … so what?
I’m well aware of specifying obscure fonts and moving to more general fonts withing a CSS declaration, but since when has CSS provided a mechanism to embed fonts? This is in resposne to Stephen’s comment (#16).
bq. That’s impressive! It’s nice to know that it will sound the same as it looks when blind people have it read to them too”¦
Too bad scrolling would still sound like turning a page in too many websites…
“For the record, naysayers should know that I’ve yet to encounter any personal computer users who routinely browse the web with stylesheets enabled and images disabled.”
I’ll grant the distinction of mentioning “personal computer” in the above section, but as this article addresses CSS and standards, consider the mobile browser.
Certainly it’s a small market, but nevertheless an important consideration. I’ve personally encountered countless mobile users with CSS-enabled browsers, but due to slow data rates have images turned off by default.
The mobile platform is the one space that really bothers me, *especially* in regard to the issue of replacement (but others as well).
The fallback for that *should* be faithful use of the screen value for the media attribute, and gee, it _would_ be nice if mobile browsers would respect that.
My opinion for a while has been that mobile is the new frontier for standards advocates (especially given how expensive I perceive the cost of testing to be).
While I agree with the intent of rule number 4, I don’t think it’s very practical to restrict the use of “widgets” in a design. In some cases, your clients leave you with no choice. They want that custom border with the radius corners that will fit a box of any width or height.
You might be able to minimize your mark-up using pseudo-class and adjacent selectors, but will the browser display it properly?
What would your rule number 4 compliant solution for flexible radius corners be?
I’m fortunate in that I only wasted a few weeks messing around with tables-for-layout before “discovering” CSS. Thus I didn’t have to unlearn a bunch of bad habits 🙂
Great article!
“Dave Merwin”:http://www.davemerwin.com/ suggests a 13th lesson: “don’t give up”:http://www.betachurch.org/2006/09/26/when-it-comes-to-css-dont-give-up/ . I personally find that advice a bit on the fatalistic side, but there’s no arguing with common sense.
A lot of emphasis seems to be on whether CSS hacks are legitimate or not. I always found IE’s powerful conditional statements
the easiest way to live with browser differences (I haven’t read all comments, so this might have already been mentioned)
For those who don’t know what I’m referring to:
Many examples:
http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx
So make it work in Firefox, then look what breaks in IE and fix accordingly, right down to specific sub-versions. If a new version comes out, simply fix emerging problems by either specific styles from that version onwards, or by limiting your existing exceptions up until that version (or a mixture of both of course).
There really is no need for IE hacks.
_”Another common task for which I believe background images are appropriate is the replacement of headings with bitmapped type.”_
Why not put the image inside the header tag with an appropriate alt attribute? Semantically correct, search engines should find the alt text, text-only browsers should render it and no questionable CSS hackery.
The answer to this one is semantics-squared… woohoo! This is as close as I intend to get to pedantry, and figure that at the end of the day, the approach I *don’t* use is no better or worse. (Both approaches are ugly hacks in comparison to the ideal, if one considers things with the attitude of a purist.)
Desire for small, shiny objects aside, the primary content of the heading is definitely the copy, *not* its bitmapped representation… the bitmap is the fallback at the _semantic_ level. Thus the bitmap gets relegated to the stylesheet, while the actual heading _copy_ finds its way into the element’s textnode (rather than as some alternate value).
In a perfect world, the handheld media type would be respected, and the screen media type ignored by handhelds per the spec (7.3), unless the handheld user explicitly applies the screen stylesheet instead:
bq. Media types are mutually exclusive in the sense that a user agent can only support one media type when rendering a document. However, user agents may use different media types on different canvases. For example, a document may (simultaneously) be shown in ‘screen’ mode on one canvas and ‘print’ mode on another canvas.
So I wait for that Radiant Future, and implement a solution that looks forward (by keeping textual content at front-center) while managing to please most of the people most of the time.
On the other hand, use of RE-driven replacement validates the inline-image approach in terms of future-friendliness.
Bear in mind that in cases where the image *is* indisputably the primary content, this entire rationale gets thrown out on its ear.
The single biggest piece of advice that helped me of old-world page design techniques came from the Jedi Master himself.
It is very refreshing to finally discover others with the same problems I have experienced while trying to learn and use CSS in my web design projects. It took me years to understand html and table based layout. To now be told to throw out all I have learned in favor of CSS based design is extremely frustrating, confusing and difficult. This was an excellent article that gave validity to my why I still do not use CSS.
I am first and foremost a print designer who was dragged, kicking a screaming into this new media called web design in 1997. I was taught strict HTML and Table based layout. It is difficult to make such a global change to the way I design a web page from Table based layouts, which is visual to CSS based layouts, which is totally by code. Very left brain stuff. It has been the most difficult transition I have ever experienced in my career as a creative professional.
The biggest problem I have is that it is difficult to maintain layout consistency throughout all browsers and all computer platforms with CSS based design. For the majority of my clients, that is unacceptable. Table based layouts keep the design consistent over all and on all platforms and browsers. I can not say as much for CSS based layouts. Being that 98% of of my client’s customers are still using I.E. 5 On the PC, a CSS designed site is not ideal, at least not with my poor CSS skill set.
What I mean is, like with a lot in life, the hardest part is taking the decision, rather than acting on that decision.
So if you’re in the scenario where you’re going to convert your old-style website with table layouts to more modern CSS, just back up all your code and lock it up in a safe place, and let that be your security blanket to take the plunge.
The two approaches are so different that you might as well just strip the documents of the old tags and mark up the content again from scratch. Sounds drastic, but it’s probably the quickest and easiest way to focus on the new goal.
If you’re like me you’ll also find it breathtaking how you can do the same things as before with a fraction of the code and effort, and that you end up with documents where the code is actually easy to read. This is why I personally never felt the need to look back to the old methods… the new way is simply more fun, and that’s often forgotten when considering its much-vaunted worthiness.
Im one of them thats stuck myself between a rock and a hard place. So many projects hitting me that I never get the chance to go back and rework all the hundreds of table-tr-td-td-tr-table i’ve got. Its painful. I’ll refer to this article often. Especially the ubiquitous lesson 4. Thanks for this
Yay!
“Having to fight float and padding bugs and such on a daily basis I wish I could do table layouts once again.”
Thank you. I’m a crazy CSS fanatic but still recognize that in *some* ways tables really do handle things better. Anyone who doesn’t recognize that is sticking their head in the sand. I know it’s not “semantic” but I proposed a very good solution one time. Only problem was, my solution was proposed on the CSS discussion list and I got vilified because people thought my remarks didn’t relate to CSS.
“And (theoretically) you can use CSS to embed fonts in a page so that even users who don’t have that font installed will see it. Yes, I know that doesn’t work perfectly, but it’s better than anything HTML tables can achieve!”
What does selecting fonts have to do with HTML tables?
“Web pages are not about pixel perfect rendering.”
I’ve tried telling that to a couple prospective jobs and they thought it meant I was a bad web developer.
on the use of tables over css divs when appropriate! It seems sometimes that as we strive to move forward with new techniques we forget that there is a time and a place for all of the tools in our toolbox, old and new. A recent personal example of this was when we did some html emails that forced us to return to utilizing table layouts. It reinforced in us a pretty valuable lesson that we are not going to easily forget.
In reading these comments and other feedback – boy have I gotten a lot of IM’s the past three days! – there are three ideas that keep on hitting me on the head.
# The lust for pixel-perfection is the consequence of expectations set by print-trained designers, and is the single greatest obstacle to broader deployment of CSS-reliant sites, in my opinion.
# Clients tend to care about upfront cost and timeline more than they care about TCO or the potential to turn their site into a bonafide infosystem.
# The bastard child sites that try to get the best of both tables and CSS wind up leveraging both strengths *poorly*.
And Angela’s bit about the HTML e-mails was, for me, a bit of synchronicity. I was bopping about “http://boagworld.com/podcast”:http://boagworld.com/podcast/ and in one of the shows I played back, there was a long discussion of HTML e-mail that amounted to “you can do it with CSS but why on earth would you want to?” This is coming from a source that’s a reliable cheerleader for Web standards.
Sometimes, no matter how badly you want it, it can’t be done.
For all that, I come away with the feeling that the bottom line of standards-friendly design and production isn’t being sold _nearly_ well enough.
I liked your article a lot, but disagree with the comment you made #”36″:/comments/12lessonsCSSandstandards?page=4#36. In my job the design team and the dev team are separate. The designers go through a lot of effort to make the design pixel perfect. We go back and forth for weeks with the client perfecting a design. And in passing the design over to dev we go through the layouts and make photoshop layers specifying exactly what we want the pixel spacing to be.
Pixel perfect is possible with CSS and worse comes to worse throw a table in there. Comment #”34″:/comments/12lessonsCSSandstandards?page=4#34 made the same mistake.
Many agency put design quality over CSS perfection, and rightfully so. Most clients will appreciate the perfect layout and spacing more than they will appreciate the perfect CSS but imperfect spacing.
Kris, you are ENTIRELY missing the point. Nobody here is saying to make your CSS perfect but not to worry about what the design looks like. What is being said is that print media and web media are two different things.
To put all your emphasis on having different elements of a design spaced an exact number of pixels apart or to have fonts appear in an exact pixel size doesn’t help much in the web world because anyone viewing your website can change how your page is displayed in numerous ways. This is what needs to be drilled into the heads of print designers who are beginning to work in the world of web design (repeat over and over until it sinks in): YOU CANNOT PRECISELY CONTROL THE FINAL DISPLAY OF YOUR WEB DESIGN. If you have an aversive reaction to such a statement then you just need to keep repeating it.
You can, however, learn to understand how browsers display pages so that the elements of your design will 99.99% of the time relate to each other in a logical and attractive way.
Jeez hacks for different browsers versions. Do you people work for outfits with bottomless pockets and where the boss is your spouse’s Dad? Or perhaps if you work for yourself you are on some sort of anorexic kick? Or you don’t have a life outside of making sites pixel perfect.
In the real world not many people want to pay for your CSS indulgences especially when our competition in south Asia is churning out sites with nested tables within nested nested tables for peanuts. And you know what? They work – at least until somebody has to maintain them but that can be an issue with CSS and standards compliant sites too.
You clearly have never had to unglue someone elses hack for a client with a change that had to be published online 5 minutes ago and have to explain why the “simple” change isn’t working on their browser and the page just won’t display properly.
I agree it would be really nice to work in the way suggested but Rule #1 is get it out on time and on budget.
I am afraid you are preaching to the converted as the comments here attest.
bq. I’m well aware of specifying obscure fonts and moving to more general fonts withing a CSS declaration, but since when has CSS provided a mechanism to embed fonts?
It’s more complicated than we might like, but by using CSS you can embed a font – have a look at “www.spoono.com/html/tutorials/tutorial.php?id=19”:http://www.spoono.com/html/tutorials/tutorial.php?id=19 for the details.
bq. What does selecting fonts have to do with HTML tables?
OK, maybe I didn’t write very clearly. It was in response to the comment that CSS offers nothing beyond system fonts (which is utter rubbish) with the implication that a table-based page written purely in HTML is better. It isn’t, on so many levels.
bq. “Web pages are not about pixel perfect rendering.”?
I’ve tried telling that to a couple prospective jobs and they thought it meant I was a bad web developer.
It’s hard to do, but sometimes you have to try to educate your clients. If they have design skills, these are likely to be print-orientated, rather than screen-orientated – but often, they won’t know much about design at all.
The fact is that it is not possible to get a pixel perfect layout that gives an identical rendering across all platforms – but that doesn’t matter. What is important is that each rendering gives an aesthetically pleasing website with the appropriate content and branding. How many customers are going to compare the website on different computers to see if it looks identical?
bq. In the real world not many people want to pay for your CSS indulgences especially when our competition in south Asia is churning out sites with nested tables within nested nested tables for peanuts. And you know what? They work — at least until somebody has to maintain them but that can be an issue with CSS and standards compliant sites too.
It depends – you can have it cheap and quick and of limited use _or_ you can have it efficient, effective and easy to keep going. In the long term, a table-based layout is going to be more expensive, because any redesign (or even rewording) is a mammoth undertaking, whereas with properly structured CSS it is a doddle.
And that’s even before you look at the savings on bandwidth costs or the increased sales that can be generated by a page that everyone can access quickly.
If businesses are only going to look at the costs this month, then yes, a CSS-based design may be slightly more – but if they have any concern at all about the sustainability of their website, CSS _ought_ to be a no-brainer.
I started web design seriously about a year ago. When I first started designing I used all XHTML and tables for the layout of my designs, which I also did recently for a client also. I find it hard to design a website using just CSS for layout due to the fear of having it look differently in current and older browsers. But I have to admit that I’m a big fan of CSS in alot of ways, so lately I been putting extra time into using CSS more. Does anybody else have this fear?
I think the first steps in HTML are always done without CSS and with using tables. And as you learn more you learn that almost every layout is possible that way. And after some weeks, months or years of developing web pages someone comes along and says CSS layout is better. And, yes, he’s right! But starting with the old style and then switching is the tough part. So the beginner tutorials should start with CSS right away as the normal way to layout your pages.
When I first started to learn about layout I learned CSS before I learned tables. But because my g’f used tables alot I decided to give it a try. I also did find out that clients wanted websites built fast and as cheap as possible. Alot weren’t interested in whether CSS is more powerful or easier to update, or about web standards. First thing they ask is, what’s the cost going to be. How can a designer make standards based sites with all the competiton out there?
bq. I also did find out that clients wanted websites built fast and as cheap as possible. A lot weren’t interested in whether CSS is more powerful or easier to update, or about web standards. First thing they ask is, what’s the cost going to be. How can a designer make standards based sites with all the competiton out there?
I know I keep banging on about this but what you have to stress to your clients is the *long term cost*. If a client will want their website updated – either the content or the style – then it will take longer, and cost more, if it is written in table-based tag soup.
For clients who know little or nothing about HTML, it may not be easy to convince them of this. But if the competition is only quoting an up-front price, and is being hazy about ongoing costs, it’s likely they are trying to hide something.
You owe it to yourself, your clients and your industry to encourage people to commission sites that are well-designed and follow the standards. At the end of the day, sometimes you may need to sacrifice your principles rather than sacrifice a sale, but every time you do that, you make it more difficult for the next time.
Hi,
well, i do surf with stylesheets but without graphics! I do this while surfing at work. And this for a simple reason: It produces less traces in the corporate log files. Every single file loaded produces an entry in the corporate log. So surfing without graphics reduces the amount of log entries to about 20%, which is quite much. So from the corporates view this is me surfing 80% less 🙂
I recently built a website for a client that wanted a website as cheap as possible. My original goal was to build a website using nothing but CSS and XHTML. I was going to create some beautiful but fast loading graphics, and use a form along with providing his e-mail to make it very easy for visitors to contact him on his site. Well, it didn’t work out that way at all. He wanted the website very fast and wanted to pay almost nothing. He also insisted that it be as simple as possible. What he ended up with was an extemely simple site that ended up costing him only $500. You can see this site on my website portfolio.
Lesson 2 is something I might carry round with me to show clients at meetings. I’m happy to say that I generally know when to let lie.
Great rest of article too. I can definitely associate with almost all your points.
Only thing I would disagree with is Lesson 9. I feel stylesheet hacks are unnecessary. I think it is definitely a better solution to use conditional comments. I don’t think I’ve come across a case that can’t be solved with conditional comments. And I feel a lot better about the impending welcomed approach of IE7.
🙂
I remember writing my first CSS page some years ago. It was a pain, especially since IE and Opera behaved quite different with the margins and stuff. But I fought through that and converted a whole site from old style table layout to a CSS one. After some more sites I finally found the new style not only better, but also faster to implement.
I’m sick of having to consider IE bugs when developing a Web site. I had my hopes on IE7 but I was disappointed yesterday when I found that it stills doesn’t work. Isn’t it time that we stop worrying about it? I think most users would start to use better browsers if most pages didn’t look good on IE.
Thank you for this support.
It’s clear, concise and helpful.
Thanks for the article Ben. I’ve been teaching web design for around 10 years. Your article rings bells for me as I’ve wrestled with CSS in the same way, over the same period as you illustrate. For me the struggle is in teaching it to students, with a varied range of skills. Tables where doable, simple at a basic level but could get complex for those that required and understood it.
In class a mistake in a table was reasonably easy to spot (and fix). With CSS it’s a whole different kettle of fish!
Students often run before they can walk. The create layouts with a multitude of divs, classes and id’s without fully understanding what each element does. Trying to spot the error is almost impossible. How far back in the cascade of styles does the root cause of the error lie? Or is it a browser compatibility error?
As an Information and Communications department, we’ve always taught from a standards / usability / accessibility standpoint. Getting the combination with CSS definitely isn’t straight forward!
There’s one other advantage to semantic, fully valid XHTML markup. When you have an XHTML website, you have all your content in XML. You can then use all the great XML tools available to extract data from your site extremely easily. This is especially easy if your content is correctly marked up semantically, as the same advantages to CSS are available to you using DOM. We are even able to easily push our content to one of our partner sites, transforming it to their non-semantic markup with XSLT!
I work in a company where we manage sites for several in-house brands. The brands are always on us about pixel-prefection and “branding”. Unfortunately what they don’t grasp is that their branding should be more focused on their content than the imagery. Our sites are currently a hybrid of CSS designs and table-based. I’m beginning to have an influence on migrating to standards-based design. The hard part is convincing print-oriented designers that it works, and is the better solution.
As for whoever said, _”Thank you. I’m a crazy CSS fanatic but still recognize that in some ways tables really do handle things better. Anyone who doesn’t recognize that is sticking their head in the sand.”_ I must be sticking my head in the sand, because I can make CSS layouts do far more than tables could ever achieve. It took me a while to make the plunge, but I’m never going back.
I would disagree with using css hacks, only because as other posters have said, there are other ways of doing it (conditional comments, etc.). My opinion is that it may be good to be backwards compatible (or _sideways_ compatible) but at some point you need to start providing markup that is future-proof. I’d rather read a plain-text website than a broken mess of td’s and rows that place content all over the page with no logical flow.
I was needing to know where is the images for article #192?
So, we can see how and where the images work with the code.
Thank you very much and we like your web site. It helps us all in class.
I read ALA lots & lots, but missed this one when it was published. I just caught the interview you did with Paul Boag, and I too am thrilled with this. Thanks!
{it’s probably listed in the comments, but if you’re running late like me, here’s the interview: http://www.boagworld.com/archives/2006/11/podcast_57_afraid_of_standards.html