Acts of Volition

Comments

Comments are locked. No additional comments may be posted.

Adrian Pop -

First, regarding the FONT element and changing type size.

You said you are not a big fan of customization and yet this is one of the most dramatic ways in which a design can be altered (and, of course, ruined) by the user, since your pages consist mostly of text. The basic rules of typographic design involve careful adjusting of the size of the letters and the white space between the lines in relation to the general proportions of your page. When type size changes, so should line height and the size of the blocks of text, and the change may not always be proportional. If you are big on resizable type you could design several style sheets with the few useful type sizes and allow the user to switch between them. Anyway, I imagine that those who have accessibility issues probably favor browsers that promote accessibility. Even Internet Explorer offers the option of ignoring font sizes specified in the page.

Second, deciding in the matter of tables versus CSS boxes is a no-brainer once you see a web site made with a true understanding of the standards. The first time I saw Bluerobot.com I was thrilled. Go there, turn CSS on and off, and see what separating content from presentation means. It's not a practical matter (indeed, what's the difference in the amount of work between editing a CSS stylesheet or an HTML template?), but rather a logical/functional one.

The problem with table-based layouts is that they force you to think of the page as a spatial structure instead of a semantic outline. For example, take the current design of AOV: the menu on the left, the main content on the right. A visitor who uses a graphical browser immediately recognizes the structure of the page and moves freely inside it. But someone who uses a text browser or a screen reader will have to go through the menu time and again for each new page that s/he downloads, before getting to the actual content. With tables, you'd have to move the menu to the right if you want it to come at the end in text browsers and screen readers, and that may not correspond to your design choice. But once you have the menu and the main content in two different CSS boxes instead of table cells, you can move them around at will, regardless of where their content appears within the HTML mark-up. This applies to many other design decisions.

Of course, since the content is in a database, separate from your templates, you can always output as many versions as there are types of clients. But this is not the original nature of the Web. Pages are sometimes saved and then opened later in a different browser, or they are archived/cached by search engines. Relying on a browser sniffer to choose the right mark-up makes difficult or impossible many of the things that are great about the Web. That is why separation of content and presentation is meant to happen on the client side, not on the server side (where, in most cases, it already exists).

Good luck with the re-development.

Steven Garrity -

Adrian, thanks for the feedback. I agree with your point about spacial structure vs. semantic outline. In fact, I think I agree with just about everything you say.

However, it seems to be that you're forgetting (or more ignoring) that unfortunate but important fact that a gazillion users still run Netscape 4.

While I could make the descision to disregard NS4 for aov, since it's a personal site - I wouldn't do the same for client sites.

My question to you is, how does the reality of old browser usage affect how we interpret and implement all of the befenits of CSS?

And yes, I agree, using a browser-sniffer isn't ideal - but when it comes to making client sites work as well as possible on the broadest number of browser/OS configurations, I think it is an unfortunate but worthwhile tradeoff.

Thanks again for the feedback.

Adam Kalsey -

Cut their teeth on Netscape 3? I started developing sites when Netscape 1.2 was the state of the art. I remember when frames, tables, and cookies were new technology.

When cookies came out I was flabbergasted. I ad so many problems with state management in my 1995 ecommerce site that cookies solved completely.

Steven Garrity -

Adam, your asking for trouble asking web designers to brag about hold old-school they are ;-) I even have a gallery of some nasty old designs (although they only go back to 96/97). I remember NSCA Mosaic, before netscape. Although you've got me beat with ecommerce in 1995.

SU -

I look at CSS this way: We're never going to shake the backwards-compatibility problem, but we might as well take advantage of current programming tips and tricks so long as they don't completely destroy the experience for old skool visitors.

Look at MacOSX or Windows XP—both of these new-fangled operating systems allow you, through various means, to run software from the last century in this one. If, in the case of OSX, you want to take advantage of all the features NeXT has to offer, you upgrade your software to Cocoa or Carbon versions. If you want to save money or your software has not yet been updated for the new OS, you run the "Classic" version. In the case of web sites like this, you could offer a Netscape 4-compatible version and a progressive, CSS-enabled version for the more up-to-date visitors. If you're lucky enough to have control over the audience's browser choice (extranet, etc.), no need to offer a "Classic" version.

So why use CSS at all? For me, it comes down to simplicity and flexibility. In a recent test, we coded the exact same site in XHTML 1.0/CSS and HTML 4.01 Transitional (w/font-related CSS). The first thing we noticed was that by stripping out the tabled and spacer GIF formatting, the XHTML/CSS code was much easier to manage and read. It was cleaner. Then we looked at the file sizes. Under HTML 4.01, we created files that ranged from 4k-12k (keeping in mind that we generally keep things very simple). With XHTML, the file sizes shrank down so that they were almost all 4-6k. Percentage-wise, that's a nice difference. On bigger pages, these differences could really begin to affect download time.

As for flexibility, with XHTML/CSS, you have to do far less fidgeting when it comes to block element spacing, column stretching, text formatting, and various other design tweaks across a site with many different page templates. Want to change the way a block of error message text looks on 7 different page templates? Just change a few lines in the stylesheet. Want to change the location of the sidebar navigation on 23 different page templates? Why change the table structure when you can change 1 line in the stylesheet? CSS, while just as subject to various browser quirks as everything else, makes managing design changes throughout your site just plain easier.

Of course, this coming from a Macintosh user still steadfastly refusing to run Mac OSX ;)

Adam Kalsey -

One solution for resizable fonts is to use relative font sizes in your CSS. Instead of using 12pt, use x-small. There's a slight compatibility issue in what font size the browser uses for a reference point. x-small fonts on IE are smaller than x-small fonts on Mozilla or Opera.

http://www.alistapart.com/stories/sizematters/

I don't view it as a huge problem since all of my fonts are relative and someone having huge fonts on their screen won't break my design.

Matt Round -

As well as the same old technical arguments let's consider something often neglected in this type of discussion -
<b>pride in your work, and improving your skills</b>.

If you're building a new site nowadays the question is why <b>not</b> use XHTML and CSS, or at least <b>try</b> to use them. I got into XHTML and CSS for layout purely out of curiosity and wanting to improve my skills; it all proved interesting and worked nicely so I tried to encourage others to do the same.

Now in my day job we only use anything else when we either need to do a layout not well-suited to CSS, or have to (grudgingly) work with someone else's HTML. Yes, we're all now pain-in-the-ass HTML snobs who turn our noses up at shoddy Dreamweaver-generated stuff, but we enjoy our work more (satisfaction of working to newer standards; <b>no more crappy nested tables to wade through!</b>) and the sites we build are far better for it (faster to download, better looking, more accessible, easier to maintain).

So if you're a developer who's still not even trying to use XHTML combined with CSS for layout, fair enough, carry on with your tables and spacer gifs indefinitely, but you're missing out on new opportunities and seemingly lacking the hunger for new knowledge that's produced this industry. <b>Keep trying new things, try to find better ways to build.</b>

Steven Garrity -

Matt Round: You bring up an important point. I neglected to mention using CSS for my own curiosity/education in the article to simplify the issue - but that may end up making the descision.

I'm proud of my knowledge of how the current browsers render HTML and graphics. Like many experienced web developers, I can debug a lot of HTML by simply looking at the rendered page. CSS cell background images turning black in NS4? Turn off the GIF transparency. Last line of a paragraph have different line spacing? Add a BR tag after the FONT. These are just a few trivial examples, but if you ad enough of these up, you get close to being able to tame the nasty browsers.

While I don't think CSS is ready for all of my client sites (many of which still have over 30% Netscape 4 usage), I do want to have a good understanding of CSS and the compatability issues that follow.

So yes Matt, part of the reason I may look at using CSS here on aov is because I want to experiment and eventually bring that knowledge to my client work. That's why our clients come to us - because we can help distill this enormous glut of web publishing info. The other day a client who runs a catalog-based business contact me wonder about this new Google Catalogs site he'd heard about. I was able to tell him that we've had his catalog in there for about three weeks already. I want to have as many client calls as possible go like that.

Welcome to those of you who are new readers via Scripting News. I appreciate all of your feedback.

John Lloyd-Jones -

This is why you are wrong:
"it is generally understood that the only safe method to define font size in today's browsers is to use pixels."

In pushing people to believe this, Zeldman has done the Web design community a disservice. Pixel defined font sizes make for unreadable sites (and section 508 inaccessible). See Zeldman's "A List Apart" where he has been forced to provide an alternate style sheet for those of us who prefer to configure our monitor dpi higher than 96.

Steven Garrity -

Ever get the feeling that somewhere someone is talking about you in Hebrew?

Neil -

The reality is that, for commericial or client Web sites, support for CSS just isn't there yet. There's just too many slow-moving corporations and happily oblivious surfers out there who still use broken, old browsers. The WaSP's browser upgrade campaingn was the first real attempt I've seen to get people to upgrade their browsers... unfortunately, there's no stats on actual pay off: I'd like to know just how many people actually went and downloaded a new browser through this.

For now, I'm using XHTML and CSS for personal sites, and for client sites where the browser install base is 100% known... but I'm still sticking with tables for sites that require full backwards compatibility.

One thing I do believe, however, is that we need to start moving away from the expectation that Web pages will look exactly the same in every single browser. We don't expect pages to look the same between a wireless device and IE 6.0, and I don't believe the same expectations should be held for Web browser compatibility.

IMHO the goal is a good user experience. Style sheets cascade, and designers should use that power to create pages that look good in both compliant and non-compliant browsers. They just won't look exaclty the SAME.

One person who's done a great job of cascading his style sheets is a fellow named Mark Howells. His <a href="http://www.mark.ac/" target="_top">personal site</a> looks great and degrades nicely.

That said, unfortunately I still believe that client expectations realistically prohibits the widespread adaptation of CSS positioning, at least for me.

Plus (and this is a whole other arguement), I do think that one's layout options are somewhat constrained when using CSS positioning, because of continuing browser-flakiness, and lack of widespread support for CSS2. You just can't "place" items on the page with CSS with complete confidence that all CSS-compliant browsers will position them properly... at least not yet.

Matt Round -

<i>"The reality is that, for commericial or client Web sites, support for CSS just isn't there yet. "</i>

I hear these <i>"CSS isn't ready for prime time"</i> comments all the time and it simultaneously puzzles and frustrates me.

I get <b>puzzled</b> because I've been using it commercially for a couple of years, and in that time I've built CSS-laid-out sites ranging from little graphical branding things to information-heavy government projects (unfortunately can't name names as I'm not on here representing my employers and so have to keep my big mouth partly shut).

I get <b>frustrated</b> because it's as if people are regularly telling me that what I do every day can't/shouldn't be done. You <b>can</b> build CSS sites that work even in Netscape 4, it just takes a bit of care and research. Not all layouts are feasible purely with CSS (you can usually at least reduce table nesting though), and you need to rethink the whole way you work, but it's not rocket science.

Alan -

Without the slightest sarcasm, let me say I am sure this is riviting but I haven't got a clue about what you are talking about...or why I should care. Keeping in mind that it is your guys's interest in these ideas that makes the facility of AOV and other such sites available and useful [for technical reasons I do not understand in the slightest], I still wonder whether there is an aspect to the move to a new format which is mere technical challenge and novelty. <p>Garth in <i>Wanye's World</i> and Marshall McLuhan both warned of the reason to fear change - things get lost unexpectedly. When I see web apps get more complex/"useful" I wonder when I will be jetsom in terms of my Pentium 75/Opera Brower set up: (java script loading? bye-bye.) Whatever you do keep it structurally ecumenical. <p>[PS: maybe also toss a conversational topical bone to the idle content AOVers (ie a geekery moron like me) parallel to a thread like this.]

Steven Garrity -

Debate on this topic is also happening between diveintomark and CounterProductive. Good points on both sides.

Oh, Alan, you've requested a topic for non-web-heads. Coming right up. I've got a post about evolution and general relativity that should keep you busy tonight. It'll be up later - apparently there's some kind of popular ice sporting event I shouldbe taking in right now.

Mike from Canmore -

I have to join in here with Matt Round and state that I am puzzled. We have been using DHTML and CSS in closed corporate environments for some time. A number of big name corporate portal vendors make extensive use of these technologies, providing rich functionality that the casual web browser just can't believe comes from HTML and related standards.

Clearly when you have control over the browser, the technology makes sense to employ and can greatly simplify many things.

Ok the public web is a little different. I wouldn't begrudge anyone who has to support large NS4 populations, especially *paying* public, from using the lowest common denominator.

But where feasible, why not nudge users to moving modern browsers so we can leave the web equivalent of the dark ages of procedural code where GOTO was the most used branching tool.

Neil -

Matt and Mike:

Good points, and I generally agree. The problem is, which you touched on, is the fact that if one is trying to be NN4.x compliant, the breadth of possible layouts plummets... that is, without using ugly hacks that we were trying to get away from in the first place!

"...you can usually at least reduce table nesting though"

Not exactly sure what you mean, here: my understanding is if you're doing CSS positioning for layout it's either 100% or not at all. Care to elaborate?

I'm as frustrated as you are: I'm koo-koo for CSS and XHTML sites and try to educate clients as to why this approach is a worthy one. Unfortunately, I also need to make a living.

As much as I would like to do more sites like this, the fact of the matter is if I can't deliver what clients think they want (or convince them otherwise), they'll find someone else who will.

All of that said, I'm willing to admit that I've personally made concessions as far as advocating these kinds of Web sites to clients: being hungry does that.

Matt Round -

<i>"...you can usually at least reduce table nesting though"</i>

You can almost always noticeably improve a site by moving away from a tables-with-everything mentality.

Let's say for example you need to put a border around something, say a table (but not around each table cell) or maybe a paragraph. You could bung it in a table with narrow rows and columns containing spacer gifs to produce the outline. Or you could specify the border with CSS and leave users of browsers like Netscape 4 without the border. Providing it's not a vital part of the layout it should be worth the trade-off - the small % of Netscape 4 users won't know they're missing out on a minor graphical touch, the vast majority get pages that are quicker to download and render, you get a site that's quicker and easier to produce and maintain.

Similarly, you can often use CSS to indent text rather than nest it in a table, and even conventional multicolumn pages using tables for the main columns can often use CSS for positioning the logo and navigation across the top (much cleaner than yet more tables).

I recently had to produce a site using HTML 4 and tables for the client to integrate with their CMS. Using CSS for as much of the layout as possible knocked 3-10K off each page and saved the client days of work as the HTML was so much simpler to work with.

Alan -

For conversational purposes, an example of a Garthian/McLuhanian unexpected side effect of the IT era, see this article from BBC News .

dave rau (dmr) -

Let us all remember: Authoring HTML is a matter of philosophies.

<p>Separation of style from content<br>
Embedding elements of presentation in documents is a costly deed. Merging style and content compromises core concepts about the portability and accessibility of information on the Web, not to mention making for much larger file sizes and maintenance costs.

Back-end separation of style from content allows for control in the hands of the developer where the same separation on the front-end allows for control for both the developer and the user. Why not combine the approaches and utilize both?

<p>Font size issues<br>
Zeldman has arrested font resizing issues by not specifying any size related information in the basic style sheet (typical style reference utilized by 4.0+ browsers) and performing the font size keyword hack in the sophisticated style sheet (utilizing @import for 5.0+ browsers). See the NYPL online Style Guide (http://www.nypl.org/styleguide/index.html).

<p>Liquidity & the designer<br>
The issue of a more fluid approach to design is certainly interesting and the Web offers good potential right now for such an approach. Mr. Briggs certainly understands what this is all about (http://www.thenoodleincident.com/tutorials/design_rant/), but the designer has to exercise some control over layout.

As designers, people trust that we intelligently shape the content which we present. Designers serve as the facilitators from those expert in content to the lay person (many of us serve as those experts). This facilitation cannot come without some control, so in some instances, total user customization is unnecessary and dangerous. Users who understand, and are familiar with, what is being communicated might prefer customization, but those who are not yet expert in the content should have their hand held and be lead by efficient, thoughtful and attractive design.

<p>What is your definition of "works"?<br>
This seems to be a dangerous trip wire. I believe "works" to mean is accessible. I have no problem with employing only an @import method for style sheet references and leaving 4.0 browsers to serve content quickly, without style. Many believe this is giving the finger to 4.0 users; what is your definition of "works"?

Steven Garrity -

dave rau (dmr): <i>"what is your definition of "works"?"</i>

Good question. My answer would have to be based on context. For example, with a weblog like aov, having a simple style-free version in Netscape 4.x wouldn't be too much of a problem (like alistapart for example). However, as simple as we try to keep them, moke complex web applications require more complex formatting. A shopping cart or checkout page, for example, has a lot of important information, and visual control is important.

Michael Boyle -

Interesting article, except that as most people have done, there's an important component missing from the analysis. HTML is at its most basic level a structural language, and by using CSS to take care of the style issues, we allow the HTML to become structured again.

That's the missing piece in this whole discussion - this isn't about separating style from content at all, it's about returning the third variable in web development to its place in the sun. Web development is about style and content, but also structure. So we now have style (CSS), structure (HTML/XHTML), and content (usually XML managed by a CMS), whereas without CSS we're left with HTML to do style, content in any of a hundred CMS systmes, and no sematic structure that can be interpreted by agents that decode pages for humans.

When HTML was first developed, it is pretty clear that it was JUST about structure (and hyperlinks, but that's a separate story). When the graphical browsers came along, style issues came to the fore and structure was more or less banished. That was probably reasonable for that time - but now that we can, it's reasonable to do what we can to return HTML to its original job, and give the job of styling the structure to CSS.

Michael Webb -

The font size issue is, in general, unrelated to the css/not css question. The question of relative or fixed applies to either. Zeldman's pixel sizing argument is prompted by changes in display technology, not css. If you use pixel sizes, understand that they will make resizing difficult for most users, and don't set them too small.

The persuasive point for css, in my opinion, apart from the theory, is that raw page sizes are smaller, lower markup/content ratio, and therefore friendlier to search engines.

Many of us are experienced at designing with tables, and the process of designing with css is often frustrating. How to take advantage of css in a design sense is the interesting question.

A css based page will degrade differently, depending on the order of elements. Want the content to show up on top of the page?, put it ahead of the navigation, etc. Anyone browsing today with Netscape 4 knows they are using an old browser, for many (not all) sites, I say let it be readable, and navigatable in NS 4, the loss of style may prompt them to upgrade.

Randal Rust -

I think that there is a fundamental misunderstanding of CSS from web designers/developers who have not taken the time and effort to actually study what is possible. I find this to be quite baffling, since we of all people are supposed to be the ones always on the cutting edge.

The fact of the matter is, Netscape 4.x and any browser that does not support the standards are like horse-drawn carts. They are obsolete. Do you think Ford still provides service for the Model-T? No way. Neither does your local mechanic, because cars have been upgraded consistently through the years. Why can’t the web do the same thing?

Alan -

Why should site users be restricted by designers in their choice of browser - sounds like the desire to use the tools which provide the most gratification to the designer is more important than communicating though the medium. If design art is what you are after, then ditch the majority of potential site users through use of new but more obsure browser limitations.<p>VW, by the way, does allow you to buy parts for their products many years after the fact.

Pat Rock -

Alright, as someone sitting here right now trying to do a site in validating, accessible CSS/XHTML and reading articles about why my SHIT won't work, I have to say that I agree with our Author Herr Steven. To wit: WHY BOTHER.

I am right now reading about the number of workarounds necessary to get my DAMN DIV to center on the page. The fact that I'm reduced to using a workaround makes me think I should just write this all in tables anyways.

Why? Because as our Author notes, I seperate style from content via a Database. So once my template is in place the content is filled in from my DB. So as much as I want to use CSS/XHTML I just can't see why, if I'm just going to be reduced to using some CSS hax0rz to get it to work in the first place. I'll just use the tried and true table hacks.

My $.02
Pat

Tim Swan -

I think you're right to question whether using css would enhance content delivery on your site. There's no doubt that it would be fairly easy to duplicate your existing layout with css positioning and to use browser detection ( or link/@import) to serve a simpler css stylesheet (including simpler css positioning) to NN 4.

BUT, my question remains why you would do this when your content is already in a database, your code is fairly straightforward, and it works in current browsers.

The whole "we must separate style from content" debate is one that I don't buy, at least as a hard and fast rule. Yes, if your pages are a blog or scientific papers, then it's relatively trivial to dump it all into a predefined format. Sometimes, though, content must be read, understood, and enhanced on a line-by-line, paragraph-by-paragraph basis and this is where the structural advantages of css become a bit of a straightjacket. Content shouldn't be driven by limitations in the available technology.

The other argument that drives me out of my mind is that we should stop expecting pages to display "exactly" the same in all browsers and on all platforms -- frankly I've never met a web designer who even thought that was possible. But there's a mile of difference between *exact* display and acceptance of stacked divs as an acceptable compromise.

Don't get me wrong, I *love* css for it's beautiful simplicity (well, in theory anyway) -- I'm just longing for the day that I can use it for some of my commercial clients, who tend to be much, much less interested in all this theory.

dave rau -

Separating style from content isn't strictly about making our lives easier. What about the rest of the world; search engines, the visually impaired, those with cell phones/PDAs or text-only browsers? When I think of the separation of style from content, I am thinking of the separation occuring in the output, what you see in the browser.

Don't miss the point on all of this; it's not just about saving time and costs on our end. Sending pages to users with font tags and content placed in tables doesn't make it faster for them, nor does it allow them to employ their own style sheets.

I ask you all: why would you want to complicate matters with font tags and tables? Why not aim for this separation on both ends (front and back).

dave rau -

From my perspective, you have the entire question backwards Steven: Why shouldn't you employ cascading style sheets in your pages?

If you can't hang with no tables, use them. You can create sexy two column layouts with tables and still use some mean CSS:
http://www.sizefactory.com/20th/

I shoved my foot in my mouth when I made that site; though I am only employing CSS layouts now:
http://www.i-4band.com

Donimo -

"Acts of volition and the mechanics of data transfer" would be a good title to a summary of all the talk about whether or not to use style sheets for layout. Any reason not to would have merit only if it was sensible for mechanical reasons.

There's really no technically sound argument for prefering to keep whole page content inside of tables that isn't tied to something specific in the mechanics of a particular display agent and these arguments are few, as well as temporary.

The problems were forseen before the popular use of tables for layout began, but it happened anyway.

It is only confusing, now because of having developed a preference for, and wanting to continue, working with what is familiar. Yeah, it's annoying to have to change your way of thinking about layout, but getting over it is not really too hard. You just do it.

Continuing to do the wrong thing over and over in order to try to make it seem like a 'rational' thing to do is the same kind of logic drives a serial killer.

Timothy Martens -

"Internet Explorer does allow the user to resize fonts defined by keyword and by percentage."

Actually Steve, In IE* you can override fonts defined in pixels as well. Tools > Internet Options > Accessibility > check box: 'Ignore font sizes specified on Web Pages'

*IE6 Windows - not sure about earlier releases.

draca -

Note: Zeldman's recommendation of pixels was predicated on the need to create a site backwards compatible to IE 3. If you forget about IE3, then pixels are not as necessary. Ems will work if you use them carefully with version 4 browsers and later.

It seems that somebody has not done their homework well.

Daniel -

Matt and Mike were arguing the possibilities of css layout in NN4. Unofotunately they weren't free to name sites. I offer www.shabbatbox.com which displays almost perfectly in NN4 and validates except for one attribute, and that only because I wanted a border graphic. I built the NN4 compatible layout as a liquid width page with left column fixed width. It works.

If you want to use a more complex css file for new browsers and a limited layout for NN4, check http://www.alistapart.com/stories/n4switch/ for a style switcher that will work in NN4 and direct it towards the right style sheets.

Hope it helps, cheers.

Michael Webb -

draca No, he was refering (as far as I can tell) to the mac/windows os dpi difference, more noticable as resolution has increased, and the variation in default browser font sizes. Ems are based on a base font size, either explicitly declared or default, but some browsers (early NN 4, (larger), early macs (smaller)) do not render it correctly . see http://developer.apple.com/internet/fonts/fonts_sizing.html
Ems are a viable "relative" option, but do not necessarily render consistently across platforms or browsers. Any solution requires testing. Try opening a font test page in two different browsers side by side, and check on different platforms. I am not arguing for one approach or the other, as I think each has its place.

ecd -

Steven,
I'm right there with you. I use CSS for basic stuff, like :hover and borders. My inventory mgmt application is nothing but data: forms and reports. The occasional map.

Ahh, the map. The daunting task of not creating an image map, but making an image into a report: it must display dynamic data. This is only possible with CSS or custom server-side applications.

Being a coldFusion developer, not a java, vb, c+, etc. developer, lends more easily to my adoption of XHTML, XML, and CSS. The CSS code for the states' positions is fifty lines long; the HTML code is fifty lines long. I can combine it into fifty lines. It will work perfectly for 95% of moderately advanced users, and display properly in all user agents.

Can you do that on the backend, based on data you pass it, in java? in C? in HTML? in 100 lines? Oh, and if I store the locations in a database, the actual code I produce would come in under 20 lines total.

Hence, the proper use of CSS is, like everything else, in the proper place.

Don't kludge up a table with slices around data - words and numbers - cells , don't create the image on the fly. Use your templates as they are meant to be used. Maybe you'll want to redevelop the back-end while someone else develops the front-end. You agree on certain data standards (how is the post referred to? the date?) and you meet up in two weeks (or however long your app takes). Barring a few tweaks, you're ready for launch.

Yes, the same can be said for design via HTML, but look at what can be achieved with CSS: usable, unique-to-the-web experiences. Television doesn't let you do this stuff. Books? Hah! Little scrolly windows, fixed background images, stuff that does stuff when you point at it. And you don't even have to learn Flash! or Lingo!

Plus, according to the cascade, this design can degrade to allow for tolerable designs in older browsers, and compatible designs in future browsers. But you know this already. To the point!

Here's my point, in two parts:

There are amazing things to be done with CSS. Positioning is just one. Have you heard of the font-size-adjust property? Look it up.

There are amazing things coming from the w3c, and the sooner we make the manufacturers understand that we want them, the better. Full DOM support. More intelligent forms. More precise design. A more unique web.

End point.
End letter.
Goodbye.

ecd.

Matt McIrvin -

As others have said, Zeldman's insistence on pixels was based on the state of the browser art as of a few years ago, and the worst offenders are much less common than they were in those days. On my pathetic little site, I use the @import trick to give font sizes in ems to the good browsers, and to the bad ones, I give no font sizes at all. What little font sizing I need beyond that, and beyond the default styles for structural elements, I control with BIG and SMALL.

The implementation troubles with ems (if not with the relative font size names) stopped being a major problem some time ago. What's still a problem is the box model, since it was badly messed up as recently as Internet Explorer 5 on Windows, and even relatively good browsers like IE5/Mac have some problems with it that crop up when you try to do something really ambitious, like stacking up multiple floats.

It's also a fact that while some very recent CSS revisions include a display model that mimics a table, the CSS that is actually widely supported doesn't have that, and therefore lacks some of the flexibility of tables (though it can be more flexible in other ways).

That's why, even though I was a vocal advocate for CSS way back in the Dark Ages of 1997, I've still got a nasty old table layout on my front page.

You can take an evolutionary approach. (In fact, that seems to be what you're doing now, since you've already got a style sheet.) There's been too much emphasis in CSS-based design circles on swearing off the Demon Table, as if CSS and tables were somehow antithetical. Remember, tables exist even in XHTML Strict. In un-nested form, they exist even in XHTML Basic! They're supposed to be just for tabular information, but what is tabular information? Maybe more things that you might think. If it logically falls into columns and rows, hey, I'd say it's tabular.

What's more important is the realization that you *can* get rid of table hacks and FONT tags where it makes things easier. I'm an amateur, and a somewhat lazy one. If I had to use a bunch of nested tables just to put margins on things, I'd never bother with it. CSS means I don't have to bother. Maybe I could make it painless by making my site database-driven, but that's more than I want to get into as well.

stylo~ -

I completely disagree with the idea that templates and a database can just as easily be used to serve up displays.

I am presently ripping tables and bad coding from a complete ecommerce package. The difference in the templates is astounding. It would be a nightmare to have a choice of tables/basic markup in the template (and would involve extra processing time anyway). Or to have two templates that need to be synchronized.

Instead, my templates will pump out nice clean xhtml table-free mark up that will then be formatted by a stylesheet. (Well, I've done the category pages without tables, and we'll see about the forms and such. May need tables there, but nothing wrong with that.)

The first huge reason to do it is page size. The resulting pages should be about 50% lighter! For a real-life example, take a look at the redesign I did of http://mozillazine.org but in css: http://scootrs.com/moz/ . 55% of the original! Compare the source code!

The second major reason is that upkeep and redesign is vastly simplified with css.

The third is good semantically clear code for search engines and whatever else is/will be out there.

CSS is where you deal with nn4. You give them a simplified stylesheet. They don't get what the better browsers get. (***NOTE: Much can be done, though, as noted above by someone. The http://scootrs.com/moz/ can easily be done in nn4 if you want, but I didn't bother.)

The main thing is this: You have to get over the idea that nn4 should get the same design, even if 30% of your audience. They get a different design - usually simpler, but nice and clean. I don't see how any enterprise - Amazon, eBay, Yahoo, yourshop.com - would suffer in the least. THEN, go nuts with the css for the newest browsers. Heck, offer nn4 a screenshot so they can see what they get by upgrading.

<anti-w3c rant>
The *only* thing that upsets me with css is the absolute stupidity of the float spec. Is it not blindingly obvious that float should NEVER cause an element to leave or overflow it's container? Never, never, ever?

And that it should be something like:

float: top|right|bottom|left|center

where "center" means center the damn thing in the container, or could be used with one of the sides as in "float: left center". This one horrible spec brings endless frustrations with overlapping elements - especially on dynamic pages - and must be fixed pronto. For now we must follow funky floats with a an extra div with a break and height set to 1px, break:both.

What non-webpage-designing [censored] came up with the float spec??? And why did browser makers not say anything?
</anti-w3c rant>

But other than that, css is great and doesn't require (m)any hacks if done well. Serve ie a box-model fix if necessary via an ie conditional statement. Done.

stylo~

Luke Melia -

A few things I haven't seen mentioned yet...

First, I'd say that pages built with CSS tend to be smaller (fewer kilobytes) than pages built with tables. Simply less HTML. And all the code in an external stylesheet will cache on the client, making subsequent pages that share the same stylesheet load faster.

Second, CSS layouts require less slicing and dicing of images. That results in less work and easier maintenance.

Third, pages built with CSS are easier to manipulate using Javascript and the DOM. This makes DHTML features and functionality possible, and even easy to implement. If used well, that means happy users.

I work for a media company with a significant online presence, and we're in the process of weaning ourselves off of Netscape 4 support. It won't take long given the above benefits of CSS and others that folks have mentioned above.

stylo~ -

>Third, pages built with CSS are easier to manipulate using Javascript and the DOM.

Good point. I assumed that was implied in "good clean code," but good to make explicit. And, for those who hate js, we should also say that clean code simply displays better even if not manipulating it via the dom.

stylo~

Peter Kläs -

>http://mozillazine.org but in css: http://scootrs.com/moz/ [...]
>Compare the source code!

Beeing a programmer who is just occasionaly involved in Web-Design, I think this is quite an issue. If you have some external constraints - like the above stated 95% rule of thumb - it's simple math wether to use css or tables. If you are free to choose, I don't know why on earth you would prefer to maintain source code like http://mozillazine.org over the css variant.

But then again, I reformat every loop in my source until the indendation is consistent.

"programs must be written for people to read, and only incidentally for machines to execute". Does the same hold for web-design as well (otoh does it even hold for programs)?

matt -

OK, here's another reason for not using tables:

How is a voice browser supposed to make any sense of a table layout?

Semantic mark-up can easily be read by a voice browser, because the tags actually mean something to it: <h1> heading, <p> paragraph, <h2> sub-heading, etc..

Randal Rust -

Whenever I meet with a client for the first time, and ask them their goals for the web site, they state two things:

"Pages have to load fast."

"It needs to look the same in all browsers."

I then have to educate them that they can't have their cake and eat it too. It's one way or the other. And what it boils down to is speed. And that's what CSS layouts give you. In download times and in maintenance. Table-based designs simply do not compare.

It makes absolutely no sense to build a client's web site so that it displays the same in NN4 and NN6. Doing this simply wastes time and money. Netscape 4 is not used by a significant enough portion of the customer base to spend the effort on designing for it.

Designers tend to hang on to outdated browsers and test pages in them. We tend to find alternative ways of browsing the web that don't involve Microsoft. The regular web surfer that buys things on the web is not like this.

Build for the future. Not the past. Netscape 4 is the past. Follow the W3C specs, most importantly the Web Content Accessibility Guidelines.

David LaRocque -

<p>What really won me over to CSS is being able to control the order content loads in the page. Instead of watching a header appear, then the body of the text, with CSS positioning you can have the main content load and display first, and then the navigation loads around it afterward. Really cool, and especially practical for lower speed users.</p>
<p>I'm just getting started on my site, which isn't at all complicated, but seeing that content load first gave me that "wow, this is cool" thrill you get when you successfully do something really different for once.</p>

Dave -

Steven-

Your letter has some very very good points and I agree with most of them. One suggestion I have for font sizes: If you use 'em' for all your sizes, then they will be user-resizable, which, as you say, is key (and it is).

Regarding "CSS still emerging": Tables versus CSS:

There are still a LOT of things that tables can do that CSS cannot do. Yes, one may argue that they were only meant for tabular data, but how do you, for example, guarantee X, Y, or Z number of elements span a width N in CSS? In other words: CSS has a long way to go.

I hope some if it made sense.

-Dave

Noah Lazar -

<p>There are two points people have not really discussed yet.</p>

<p>The first one is maintenance. If you are making your own personal web site or will be maintaining it yourself, then feel free to choose the technology right for you. But for sites that you design/develop for clients, they typically will maintain the pages well after you leave. In most cases, they have no HTML knowledge and use FrontPage 2000, Dreamweaver 3, or some other editor. Those editors were built on tables, so they can edit that layout type without a problem. Throw in CSS-only layouts and you will run into many problems. Your clients won’t be too happy if they can’t update their own content!</p>

<p>The second issue concerns the arguments surrounding leaving some percentage of people with a non-ideal design. If your client’s president uses Netscape 4.0, your site better look just like the comps you presented in that browser. They do not care about the technology or how you made the site, they care that what they see is what you promised. Businesses rely on everyone being able to have the best user-experience possible while browsing their information. If 10% of the audience get piles of div tags, bordered images, and no sidebars, then they lost a possible 10% of their sales.</p>

<p>I have switched to CSS-only layout for intranet and internal-only sites were the browser usage could be limited. It’s a big plus for accessibility too. But for the mainstream sites, I have to stick with tables for layout. I don’t have time to make and debug two separate versions of the site either.</p>

<p>How many of you get server logs with Netscape 3 reported? I get a few each month, and I want to keep those users relatively as happy as those with IE 6, Opera 6, Lynx, or even JAWS. Until people upgrade, it's all about compromise.</p>

Carlos from Madrid -

I agree, in some part or another, with almost everything I've read here. However, I think we still give too much importance to the NS4 (and the rest of old browsers) issue.

What I mean is, doesn't people have to buy a modem to get online? To upgrade their computer to play that game, or use that word processor? To get a mouse when they didn't had one, and an inkjet printer when they came out? And all of this costs money.

Browsers, however, are free nowadays. I don't think it would be such a BIG offense for a user, to inform him/her he's using an old sofware application to browse web pages, and that he/her would have a much better experience by downloading a new version. Some links to do so and voilà.

This kind of principle applied really really good to Flash/Shockwave, etc. Almost everyone I know downloaded QT, because they wanted to see the movie. So, if they want to see the web, they'll have to download a browser. That's it.

Or perhaps, we -I still code for NS4, mea culpa- are still thinking with the [now old?] 'you'll be millionaire if you got a website' philosophy, and we're being really mean and we want a zillion visitors per day and we can't stand loosing just one.

I want to visit a website with my NS4 and read a big H1-ed "your browser SUCKS. We don't want to make our site visible for that crap, because we'd loose time & mood. Don't be lazy and get a better one. For free, if you were asking."

Why can't we just be honest? ;)

Matt Round -

<i>"If 10% of the audience get piles of div tags, bordered images, and no sidebars, then they lost a possible 10% of their sales."</i>

What about the countless people who are leaving table-based sites because they're too slow (slow download is always near the top of the list of reasons why people give up on sites), or the missed opportunities for better design, or the many companies spending precious time & money building, maintaining and serving clunky tables when they could be spending it on site improvements, new products, etc?

It's easy to be cautious, to point at simple browser statistics and safely make sure noone's offended by the site looking slightly worse for them. Users are all dragged down to the same level, but because it's hard to measure the negative effects people carry on doing it.

As for maintenance by clients, well only the smallest of clients should be using something like FrontPage to manage content, design and layout themselves, and the site will almost inevitably be a complete mess within weeks. If they're hiring a Web design firm it's because they can't do it themselves, so look into cheap/free CMS solutions to give them the control they need without the power to put green Comic Sans on the home page.

PK -

You will always have to consider the trade-offs when designing a commerical website. You will want it to be functional and look basically the same in all browsers, all versions and on all platforms.

This means using CSS only for the basics, and making sure the rest is defined in your HTML itself.

Unfortunately, while the design community raves about the wonders of CSS and XHTML, those outside the design community say "wtf? I cant read your page in NS4 on my 486DX, Ill just go look at this other site".

In business, that means you lose customers. And that can ultimately lose you your client.

Steve, I think for your personal site its worth experimenting with CSS and even XHTML, I doubt you will lose that much readership - do you have stats that show aproximately the amount of people using old browsers?

If you are really worried about those people using older browsers, there are some very basic tricks you can use (like @import to hide your sheet from netscape 4) to make the transition a little less painless for your visitors. Or you can dedicate a page/area to experimentation and leave your base site as it is - functioning exactly as you want it to in most browsers.

Learning new technologies will empower you to better understand what will and wont work for your clients, and will give you the tools to build better websites now and in the future.

draca -

<snip>
Unfortunately, while the design community raves about the wonders of CSS and XHTML, those outside the design community say "wtf? I cant read your page in NS4 on my 486DX, Ill just go look at this other site".

In business, that means you lose customers. And that can ultimately lose you your client.
</snip>

Comments like this one make clear that some people don't "get it" yet. If XHTML/CSS layout became the standard for every Web site, just what Web site would that customer be jumping to...another Web site that looks exactly the same way in their old, broken browser?

Seriously, if all Web designers and developers united on this front, the issue of customers jumping ship would be an issue...EVER.

draca -

That last sentence was supposed to read:

Seriously, if all Web designers and developers united on this front, the issue of customers jumping ship would *not* be an issue...EVER.

PK -

Draca, I think you missed my point. Web standards are good. But they are rendered almost uselss when people continue to use old (and not so old) web browsers that will not render standards compliant code in the way it was meant to be rendered.

If everyone had the ability to use the newest, shiniest most compliant web browser you would *still* see this happening while browser manufacturers dont give two hoots about standards.

Oh sure, they do a good job of pretending to care. But you just have to look at IE's botching of the box model to realise its a snow job for the masses.

There would be no need for hacks and work arounds if browsers were manufactured to render the existing (and developing) standards correctly.

simon -

I just want to clap loudly for Carlos from Madrid. I like what he says and the way he says it! Really! And I love his idea of including CSS screen shots for non-compliant users.

I'd like to add a couple of other points.

I think its fine not to provide styling for NS4, above and beyond naked HTML. Was a time I used to serve browser-specific style sheets etc, but not now. But dont lets disrespect NS4 users. The design should degrade gracefully when unstyled. This limits you a little, takes a little thought and some additional work. I didnt use to - now Im starting to!

Finally, a question. Or a rant. Do we really think CSS provides a valid basis for a long term standard, with its assumptions cast in concrete etc? If not, maybe we neednt get too excited about it! I understand the intent to allow automatic adaptation to the characteristics of different browsing devices. And I can live with temporary browser incompatibility. I guess. But Float and Position, much as I love them, seem pretty bizarre ways to run a computer, no?

(For instance, why not an option to close up the space vacated by relative repositioning. And an option to reserve the space entered by abolute positioning. Named positions and spaces might be nice too...)

Maybe Im just a parallel skier converting to snowboarding. But it seems to me - to answer Steve's original question - he should implement the AOV upgrade whichever way is easiest for him. In his own opinion. I dont think it really matters. Not yet.

Kevin -

Steven:

I am in virtually the same situation as you are on this issue.

I am presently working on a redesign of my website. When I began this process, I decided that perhaps I should update my HTML knowledge and look at CSS for some design elements. Picking up a good book on CSS I set to work.

The first beta of the new site combined the use of tables and CSS. I was pretty pleased with the layout, but didn't have quite the control with tables that I would like to have.

So, I thought - why not do this with NO tables at all. I set about doing exactly that. Before long I had created an exact copy of the previously design except with no tables. Again, I was pleased with the look of the site.

The one aspect I really like about CSS is the positioning control of elements. I very much like working at the pixel level to place things where I want them on the display. I do the same type of thing when I create database designs in Lotus Domino, and found it to be a great way to work.

However, when I started to test the design with browsers other than IE 5.5 -- I got really annoyed. Opera 6 likes to play with padding in a bad way, so I changed that and it looks great there now too. BUT - - the biggest problem is Netscape 4.x code.

As you say, it sucks big time. However this is nothing new. The first code I wrote was used with Mosaic .96 "way back when" -- we've been having the same problems ever since.

Facts are that we cannot support all backlevel browsers forever. What happens a year, two years from now? Does web content suffer because of the off chance that some chucklehead on the dark side of the moon has Netscape 4?

Usability is one thing, accessability is another...but if we applied the same principal of universal support to the general software industry, we'd have Win 3.0 users running Office XP. We simply never want to ask the user to actually keep current on their browser.

I fear that I will cave and end up having a combo design again. Something I don't want to do.

The longer we continue to cave to the lowest common denominator, the more web content suffers. It is a fact that many web users say there is a lack of quality content online. I would contend that a good part of this is due to the fact that designers are hampered by browser technology.

K.

pixelkitty -

"It is a fact that many web users say there is a lack of quality content online."

I wouldnt go confusing the lack of content with poor design.

Plenty of websites out there have excellent content, yet ugly design and no degradability.

Content and Design are two very VERY different things.

Sure you didn't mean design is hampered by browser technology?

sasha -

NEVER EVER EVER use font size="2". Do you even know what this does on certain machines? Unix people will love you for making their font size "2pt", which is what size="2" is translated into. Anyone who does this deserves a big slap on the wrist.

Netscape 4.x can make text just as 12px blue arial sans-serif as any other browser with css. Netscape 4 should always continue to be important as long as it is the number 1 non-IE browser appearing in the web logs. Once it hits the ranks of AOL 3, sure, you can start ditching it. I don't like M$, so I don't like seeing people who choose not to use M$ browsers/products getting shafted. I have NS 4.73 and 6.0, and as bloated as 6.0 (as well as buggy and loves to crash..) is, I can see why few NS 4.x users have upgraded.

Using browser detection is a terrible way to do things, especially when fairly well known browsers on the "cutting edge" of compliancy get the shaft (such as Opera 6, Konqueror, or maybe even that fancy new mac only browser: OmniWeb).

You can't make people change their browser just because you don't like it. This is a fact of life. You going to get all those big ecommerce sites to agree with you? "We want some help getting everyone to upgrade their browsers to one of our liking. This means kicking users away that have an older browser. Sure, we know that this may turn away 10-20% of your customers, but it is for the better good!" Not everyone lives in America and has a p2 and 56k modem or better. Forcing people to upgrade their browser is not being very sympathetic to the fact that maybe they can't download a newer browser in less than 5 hours or maybe it wont't even run on their ancient hardware. Maybe you will tell them to upgrade their computer too?

I want to know why Kevin believes that there is no quality content online because of poor web technology. Content is mostly just text. I don't see how that could be hampered at all by HyperText Markup Language.

lionel -

Backward compatibility is keeping us and the Web from moving forward. Old browsers should not be deserving any respect because of this.

And who said users can't do anything about it? Getting a new browser doesn't cost a leg. Carlos has put this point down well.

Justin Pease -

I am very interested in this topic. As a designer I am looking into the benefits of using CSS for layout. Many of the benefits sound very good. My concern is that I have only been able to find fairly simple layouts using CSS. Does anyone know of some rather complex table-less sites using CSS? The 3 column examples are nice, but I am looking for more.

Thanks!

lionel -

There's a page in my website that consists of a 3-column panel within a 2-column layout. That wasn't a very good description of it, but it's beautiful anyway. I'm not a designer, so I'm just so very proud of it.

Steven Perry -

It's possible this entire issue arose from wysiwyg html editors creating absolutely messed up code. Using the changes that the wc3 is proposing (absolute positioning and external stylesheets) may allow all html editors to create code that is clean, compliant, and efficient.

My real opinion is that these contstant changes are just turning a mundane task (writing html) into an absolute chore. Using notepad to write html will no longer be an option when you have to find the "absolute" location for every component on your site using one time-wasting technique or another.

And then there are plenty of website layout effects that I like to use, but just aren't possible without using tables as a formatting tool. (How do you absolutely position an element that stays just to the left of center even when the browser resizes?)

David Burnett -

Here is a very interesting article about ESPN's transition to a 'tableless' site.

http://devedge.netscape.com/viewsource/2003/espn-interview/02.

Basically, ESPN is moving away from support of NN4.
And I don't blame them at all.

Join the campaign to help people upgrade!

David Burnett

Kevin Mort -

Sasha:

As pixelkitty observed -- my comment regarding quality content was a bit misstated.

As is noted, what I really intend to say is that I feel web designers are hampered in the designs they can create due to inconsistant support of design technologies within browsers.

To extend that comment, many times web designers are taking the fall for sites which don't "pop" with all of the latest & greatest code wizardry. The truth is that I can code a page to 100% compliant HTML standards and have it rendered differently in as many browsers as I try.

Thus the requirement for creativity of design for the web community (which isn't a bad thing) -- and really the need to compromise between what effectively presents the content you wish to show and is supported by the greatest number of browsers.

K.

David Power -

Ok- I've taken quite a bit of time to look through these posts and look at the examples- and I find that they all have one thing in common. The layouts are all very simple. Most sites just seem to be 3 vertical columns and some basic text.
I like tables because of the graphical freedom they give. Imagine trying to complete a site like www.taramed.com using CSS. Forget it. True, a simple layout with clear information makes sense- but what if you're dealing with a client who wants something that looks different? In this case the client wanted it to look like a brochure.
Things like not being able to centre a layer in the browser are just unacceptable (yes I've tried the workarounds)- imagine having a restriction like this in Quark Express or Photoshop! And none of that BS about "well that's the design challenge"- they've had long enough to get it right.
CSS places huge restrictions on Graphic designers.
Show me a site that proves me wrong! Please!

kashif -

this sie is not open in my personal computer plz help me