99.9% of Websites Are Obsolete
September 6, 2002 6:51 AM Subscribe
99.9% of Websites Are Obsolete An excerpt from an upcoming book by Mr. Zeldman in which he continues to argue the practice of standards compliance - "Held up as a Holy Grail of professional development practice, backward compatibility sounds good in theory. But the cost is too high and the practice has always been based on a lie." I enjoy his writing but he seems to be repeating himself as usual. Still, it is a good argument: where do we focus our priorities for future development - pure standards compliant CSS models, backwards compatibility, or somewhere in between? I know this has been discussed before but thought it postworthy due to the new book and all.
Make all the buttons blue dammit!
Oh, and beveled...make them beveled too!
posted by dangerman at 7:10 AM on September 6, 2002
Oh, and beveled...make them beveled too!
posted by dangerman at 7:10 AM on September 6, 2002
In practice, its always been about who to protect, and who to screw over. It's about who has a legitimate claim not to upgrade, versus who should legitimately have upgraded by now.
Amusing that Zeldman mentions 99.9% of Websites being obsolete because 0.01% of users don't get a wonderful browsing experience. Considering that, circa 2002, any wireless web experience short of a laptop is hideous (at best), I'm not sure strict adherence to XHTML would even assist that miniscule (for a reason) niche.
Also amusing that Zeldman has no idea how revolutionary the "it renders, no matter what" model was, and how its extraordinary flexibility and complete disavowal of error handling actually made the web the addictively usable authoring and browsing environment it became. One wonders if Zeldman was around for the early days of the web...if he ever played with Gopher...heh, if he's ever tried to do page layout in Swing.
Honestly, one wonders if Zeldman browses the web at all. To claim Yahoo has useless layout that nobody would miss, after clawing through rasterbatory Big Corporate Sites for even a day, takes some chutzpah.
I'm sorry. It so happens that Zeldman makes a number of quite reasonable and fair observations -- his list of suggestions at the end, if a bit vapid, do reflect the reality that HTML has gotten astonishingly hairy and Some Things need to change. But the whole point of the web is that you didn't need to be a programmer to know how to make a web site. We need standards that let users easily create modern sites using simple, clear techniques.
I'm absolutely convinced XML and CSS can't do this. I'm nearly convinced nothing again can come that will.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
posted by effugas at 7:13 AM on September 6, 2002
Amusing that Zeldman mentions 99.9% of Websites being obsolete because 0.01% of users don't get a wonderful browsing experience. Considering that, circa 2002, any wireless web experience short of a laptop is hideous (at best), I'm not sure strict adherence to XHTML would even assist that miniscule (for a reason) niche.
Also amusing that Zeldman has no idea how revolutionary the "it renders, no matter what" model was, and how its extraordinary flexibility and complete disavowal of error handling actually made the web the addictively usable authoring and browsing environment it became. One wonders if Zeldman was around for the early days of the web...if he ever played with Gopher...heh, if he's ever tried to do page layout in Swing.
Honestly, one wonders if Zeldman browses the web at all. To claim Yahoo has useless layout that nobody would miss, after clawing through rasterbatory Big Corporate Sites for even a day, takes some chutzpah.
I'm sorry. It so happens that Zeldman makes a number of quite reasonable and fair observations -- his list of suggestions at the end, if a bit vapid, do reflect the reality that HTML has gotten astonishingly hairy and Some Things need to change. But the whole point of the web is that you didn't need to be a programmer to know how to make a web site. We need standards that let users easily create modern sites using simple, clear techniques.
I'm absolutely convinced XML and CSS can't do this. I'm nearly convinced nothing again can come that will.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
posted by effugas at 7:13 AM on September 6, 2002
Obsess on backwards compliance and you end up shackled to Windows the super kludge and floppy drives. Innovation requires movement, and movement leaves some behind.
posted by rushmc at 7:16 AM on September 6, 2002
posted by rushmc at 7:16 AM on September 6, 2002
I thought that the Web's success had beaten down this kind of argument years ago. It's depressing to see it pop up again. Clay Shirky says it better than I ever could: "Good tools allow users to do stupid things", "Only solutions that produce partial results when partially implemented can succeed". David Weinberger wrote an entire book around Tim Berners-Lee's idea that "The Web will always be a little broken".
The Web works because it allows anyone to get on with building things, without having to be an expert in normalized DTDs. Pedants like Zeldman can't accept that the best solution from a social perspective is not the best solution from a software engineering perspective.
posted by fuzz at 7:22 AM on September 6, 2002
The Web works because it allows anyone to get on with building things, without having to be an expert in normalized DTDs. Pedants like Zeldman can't accept that the best solution from a social perspective is not the best solution from a software engineering perspective.
posted by fuzz at 7:22 AM on September 6, 2002
You took the words right out of my mouth ruschmc. Trying to be "all to things to all people" is simply not a reality with the constant change taking place. All of the sites I've designed look simply smashing in IE, ok in Netscape and who knows how, in Opera. My clients only care about how it looks in IE. Since they write the checks, I'm down with that.
posted by KevinSkomsvold at 7:23 AM on September 6, 2002
posted by KevinSkomsvold at 7:23 AM on September 6, 2002
One wonders if Zeldman was around for the early days of the web
Well, zeldman.com has been around since May 1995, and Zeldman had a few runs on the board by then. But he probably wasn't privy to Berners-Lee's early CERN memos.
Amusing that Zeldman has no idea how revolutionary the "it renders, no matter what" model was
Amusing that people presume to know the entire contents of his mind on the basis of one brief article excerpted from a full-length book.
Pedants like Zeldman can't accept that the best solution from a social perspective is not the best solution from a software engineering perspective.
Again, amusing that... ah, what's the use.
posted by rory at 7:24 AM on September 6, 2002
Well, zeldman.com has been around since May 1995, and Zeldman had a few runs on the board by then. But he probably wasn't privy to Berners-Lee's early CERN memos.
Amusing that Zeldman has no idea how revolutionary the "it renders, no matter what" model was
Amusing that people presume to know the entire contents of his mind on the basis of one brief article excerpted from a full-length book.
Pedants like Zeldman can't accept that the best solution from a social perspective is not the best solution from a software engineering perspective.
Again, amusing that... ah, what's the use.
posted by rory at 7:24 AM on September 6, 2002
Right. I'm quite critical of standards zealotery, of course it is definitely a good thing if a page looks exactly the same on IE, Mozilla and Opera and degrades nicely so it can be read with Lynx, but when these guys start advocating the evil of the FONT and TABLE tags (on other words: radical separation between style, structure and content), it is obvious that their attitude is totally unrealistic. Still too many companies ask their workers to build webpages from Freehand or Corel or Photoshop layouts using WYSIWYG tools and a 100% CSS approach is just unthinkable of.
Q: Why do most 100% standards-compliant webpages look like the 'less is more' idealized by Mies Van Der Rohe? A: Something else entirely based on CSS is a nightmare.
Damn, these guys are building webpages on many thousand-dollar budgets. 99% of companies don't have that kind of resources.
posted by edsousa at 7:26 AM on September 6, 2002
Q: Why do most 100% standards-compliant webpages look like the 'less is more' idealized by Mies Van Der Rohe? A: Something else entirely based on CSS is a nightmare.
Damn, these guys are building webpages on many thousand-dollar budgets. 99% of companies don't have that kind of resources.
posted by edsousa at 7:26 AM on September 6, 2002
when these guys start advocating the evil of the FONT and TABLE tags (on other words: radical separation between style, structure and content), it is obvious that their attitude is totally unrealistic
Like the totally unrealistic World Wide Web Consortium, you mean? The ones who deprecated the font tag in HTML 4.01 and developed the CSS2 boc model to discourage the use of tables for layout rather than the presentation of tabular data?
these guys are building webpages on many thousand-dollar budgets
Who guys? Standards-compliant guys? What "many thousand-dollar budgets"?
posted by rory at 7:39 AM on September 6, 2002
Like the totally unrealistic World Wide Web Consortium, you mean? The ones who deprecated the font tag in HTML 4.01 and developed the CSS2 boc model to discourage the use of tables for layout rather than the presentation of tabular data?
these guys are building webpages on many thousand-dollar budgets
Who guys? Standards-compliant guys? What "many thousand-dollar budgets"?
posted by rory at 7:39 AM on September 6, 2002
Zeldman and the members of the Web Standards Project are not advocating that Billy, your 9-year-old nephew, has to use completely validated XML/CSS to have his little web page on how cool frogs are.
Amateurs will put out work that is not as good as pros. Hard to argue with that. Those of us who do this for a living should produce independently varifiably quality work. Validation works great for that.
Adding long term value and viability to our web sites makes things easier for us and our clients. Putting an instant expiration date on your work isn't very wise.
For HTML 4.01 and XHTML 1.0, we have the Transitional DOCTYPE. For right now, this is where it's at. Major websites don't have to go right for CSS-only layout and fully XHTML 1.1 Strict compliance, but they can move towards it.
As soon as you can abandon the illusion of uniformity of appearance across any and all point releases on browsers dating back 5 years, you can start to move towards a more easily manageable, updateable markup solution. This only benefits search engine ranking and cataloging, accessibility, usability, and usefullness.
For example, not using a basic style sheet for fonts and colors (works on NS 4.x) is just silly. Littering your site with FONT tags just so it looks the same on NS 3.x is a big waste of bandwidth and coding time.
So can we agree that a total, Web-wide switch to total, most-recent web standards is not the issue here? How about a Transitional path up from solid HTML 4.01 towards XHTML and XML for WEB PROS, not amateurs?
posted by Phatbank at 7:39 AM on September 6, 2002
Amateurs will put out work that is not as good as pros. Hard to argue with that. Those of us who do this for a living should produce independently varifiably quality work. Validation works great for that.
Adding long term value and viability to our web sites makes things easier for us and our clients. Putting an instant expiration date on your work isn't very wise.
For HTML 4.01 and XHTML 1.0, we have the Transitional DOCTYPE. For right now, this is where it's at. Major websites don't have to go right for CSS-only layout and fully XHTML 1.1 Strict compliance, but they can move towards it.
As soon as you can abandon the illusion of uniformity of appearance across any and all point releases on browsers dating back 5 years, you can start to move towards a more easily manageable, updateable markup solution. This only benefits search engine ranking and cataloging, accessibility, usability, and usefullness.
For example, not using a basic style sheet for fonts and colors (works on NS 4.x) is just silly. Littering your site with FONT tags just so it looks the same on NS 3.x is a big waste of bandwidth and coding time.
So can we agree that a total, Web-wide switch to total, most-recent web standards is not the issue here? How about a Transitional path up from solid HTML 4.01 towards XHTML and XML for WEB PROS, not amateurs?
posted by Phatbank at 7:39 AM on September 6, 2002
I'm absolutely convinced XML and CSS can't do this. I'm nearly convinced nothing again can come that will.
Why? Thanks for the prophecy, but it's a little light on substance.
CSS isn't the problem, the browsers are the problem. Complete seperation of style and content is a very useful goal. And what's to say someone (hint) couldn't write WYSIWYG software to design webstuff WITH stylesheets? That would go a long way towards clearing up your "shouldn't have to be a programmer" argument.
Just because it doesn't work 100% properly right now doesn't mean it's a bad idea. It seems like you are advocating changing nothing until some magic bullet comes and shoots us in the ass, solving all of our problems.
posted by Fabulon7 at 7:41 AM on September 6, 2002
Why? Thanks for the prophecy, but it's a little light on substance.
CSS isn't the problem, the browsers are the problem. Complete seperation of style and content is a very useful goal. And what's to say someone (hint) couldn't write WYSIWYG software to design webstuff WITH stylesheets? That would go a long way towards clearing up your "shouldn't have to be a programmer" argument.
Just because it doesn't work 100% properly right now doesn't mean it's a bad idea. It seems like you are advocating changing nothing until some magic bullet comes and shoots us in the ass, solving all of our problems.
posted by Fabulon7 at 7:41 AM on September 6, 2002
FYI - a backup of my point about professionals being the focus here can be found at Zeldman's site this morning: http://www.zeldman.com/.
posted by Phatbank at 7:42 AM on September 6, 2002
posted by Phatbank at 7:42 AM on September 6, 2002
When he began evangelizing I thought someone finally discovered the path to sanity. Use the same procedures guaranteed to work in the newer browsers, make certain everything is readable in the old browsers. Do things once, do them right, and be confident that it will work whatever users' choices are.
But then I began reading the practical css list started by Eric Myer. Everyday there are questions about why this or that doesn't work in Netscape 6, why it doesn't work in Opera, why it doesn't work in Explorer, why it won't work on a Mac. The idea that all these technologies work cross-platform even in the newest browsers seems like a false promise.
Even Zeldman's first exhibitions began detailing hacks (because the box model in Explorer 5 differs from the standard), as did all the early three column layouts. He may be on the right track, but right now any of us trying to work practically are still stuck with the suspicion that however you build your pages, they're going to blow up badly on someone's setup. (usually the client's)
posted by TimTypeZed at 7:45 AM on September 6, 2002
But then I began reading the practical css list started by Eric Myer. Everyday there are questions about why this or that doesn't work in Netscape 6, why it doesn't work in Opera, why it doesn't work in Explorer, why it won't work on a Mac. The idea that all these technologies work cross-platform even in the newest browsers seems like a false promise.
Even Zeldman's first exhibitions began detailing hacks (because the box model in Explorer 5 differs from the standard), as did all the early three column layouts. He may be on the right track, but right now any of us trying to work practically are still stuck with the suspicion that however you build your pages, they're going to blow up badly on someone's setup. (usually the client's)
posted by TimTypeZed at 7:45 AM on September 6, 2002
Who guys? Standards-compliant guys? What "many thousand-dollar budgets"?
I work for a dev company and we charge many thousands. We tend to stay middle of the road for now. A big reason is that we'll build a site for a client and then the client will come back to us later saying they're getting complaints from their customers that the site doesn't look right in NS4, etc. One time we had to go through an entire site and build a hack because NS4 wasn't reading the font styles correctly. Standards-compliant? No. Is it what the client demanded? Yes.
I believe that for now we should follow the rules as closely as possible but if the site is actually breaking on older browsers/platforms, then as far as I'm concerned we have no choice. Fix the problem, even if it is only temporary. Duct tape does have it's uses.
posted by poopy at 7:52 AM on September 6, 2002
I work for a dev company and we charge many thousands. We tend to stay middle of the road for now. A big reason is that we'll build a site for a client and then the client will come back to us later saying they're getting complaints from their customers that the site doesn't look right in NS4, etc. One time we had to go through an entire site and build a hack because NS4 wasn't reading the font styles correctly. Standards-compliant? No. Is it what the client demanded? Yes.
I believe that for now we should follow the rules as closely as possible but if the site is actually breaking on older browsers/platforms, then as far as I'm concerned we have no choice. Fix the problem, even if it is only temporary. Duct tape does have it's uses.
posted by poopy at 7:52 AM on September 6, 2002
I'm in the process of designing a very large regional site and just scraped about 3 months of work to redesign the site's templates in XHTML and more CSS. This site will be up for a couple of years, so I have to be more advanced today, so that at the end of 2004 it can still be useful and not look like crap when viewed in IE 9 or Netscape 15. Standards are not just for the present, but for the future.
posted by mkelley at 7:55 AM on September 6, 2002
posted by mkelley at 7:55 AM on September 6, 2002
When he began evangelizing I thought someone finally discovered the path to sanity ... But then I began reading the practical css list ... The idea that all these technologies work cross-platform even in the newest browsers seems like a false promise.
Yes, but it was largely Zeldman's evangelical push in early 2001 that prompted a lot of people to start finding out whether or not it was workable. Maybe the promise hasn't fully been realised, but a lot has been learned. And at least it's possible to imagine a web page rendering in some sort of workable fashion on all the weird and wonderful browsers and devices out there (like the hand-helds mentioned before) if you're using XHTML and a bunch of device-tailored style sheets; it's hard to imagine it of a table-and-transparent-gifs approach.
posted by rory at 7:57 AM on September 6, 2002
Yes, but it was largely Zeldman's evangelical push in early 2001 that prompted a lot of people to start finding out whether or not it was workable. Maybe the promise hasn't fully been realised, but a lot has been learned. And at least it's possible to imagine a web page rendering in some sort of workable fashion on all the weird and wonderful browsers and devices out there (like the hand-helds mentioned before) if you're using XHTML and a bunch of device-tailored style sheets; it's hard to imagine it of a table-and-transparent-gifs approach.
posted by rory at 7:57 AM on September 6, 2002
<Sanity>
I believe that for now we should follow the rules as closely as possible but if the site is actually breaking on older browsers/platforms, then as far as I'm concerned we have no choice. Fix the problem, even if it is only temporary. Duct tape does have it's uses.
</Sanity>
posted by Fabulon7 at 7:58 AM on September 6, 2002
I believe that for now we should follow the rules as closely as possible but if the site is actually breaking on older browsers/platforms, then as far as I'm concerned we have no choice. Fix the problem, even if it is only temporary. Duct tape does have it's uses.
</Sanity>
posted by Fabulon7 at 7:58 AM on September 6, 2002
I believe that for now we should follow the rules as closely as possible but if the site is actually breaking on older browsers/platforms, then as far as I'm concerned we have no choice. Fix the problem, even if it is only temporary. Duct tape does have it's uses.
Well, on the one hand, the customer is always right, so of course one would want to meet their demands; but on the other, professionals have some responsibility to educate their customers/employers about what is in their best long-term interests.
But even granting that one has to write for NS4 if a customer absolutely insists on it, how does that invalidate what JZ is saying in this particular article?
posted by rory at 8:05 AM on September 6, 2002
Well, on the one hand, the customer is always right, so of course one would want to meet their demands; but on the other, professionals have some responsibility to educate their customers/employers about what is in their best long-term interests.
But even granting that one has to write for NS4 if a customer absolutely insists on it, how does that invalidate what JZ is saying in this particular article?
posted by rory at 8:05 AM on September 6, 2002
Phatbank, how do you distinguish between amateur and professional on the Web? Is MeFi an amateur site or a professional site? What about all the Weblogs out there? Lots of sites start out as a hack and develop into something more professional.
I agree with your idea about transitioning. Zeldman needs to focus his argument on the places where the cost-benefit ratio is highest from this transition. Should Matt take the time to remove the deprecated TABLE tags from MeFi? Every little extra cost counts, and needs to be justified in terms of right here, right now.
posted by fuzz at 8:06 AM on September 6, 2002
I agree with your idea about transitioning. Zeldman needs to focus his argument on the places where the cost-benefit ratio is highest from this transition. Should Matt take the time to remove the deprecated TABLE tags from MeFi? Every little extra cost counts, and needs to be justified in terms of right here, right now.
posted by fuzz at 8:06 AM on September 6, 2002
I'm very supportive of open standards for the Internet, but people will switch to 100% XHTML/CSS when it is advantageous to do so and not before. Adaptation of new technology is not driven simply by ideology but by practicalities as well. If there are not clear advantages to XML, XHTML, and CSS over old HTML then people will not use the newer tech.
I have a particular problem: I'm leading a team that is creating a Web site for international development researchers. Our site needs to be compatible not just with the latest Web browsers, but with old (sometimes very old) Web browsers in very many southern countries all around the world. It would actually be silly for us to suggest to someone in rural Kenya using expensive dial-up access to download and upgrade to IE6 so that our pages will be legible to them. Instead, I'm going to use CSS for text formatting (which degrades fine) and tables for layout.
posted by tranquileye at 8:09 AM on September 6, 2002
I have a particular problem: I'm leading a team that is creating a Web site for international development researchers. Our site needs to be compatible not just with the latest Web browsers, but with old (sometimes very old) Web browsers in very many southern countries all around the world. It would actually be silly for us to suggest to someone in rural Kenya using expensive dial-up access to download and upgrade to IE6 so that our pages will be legible to them. Instead, I'm going to use CSS for text formatting (which degrades fine) and tables for layout.
posted by tranquileye at 8:09 AM on September 6, 2002
Customers don't want to be educated...they want a site that looks like Dells.
posted by dangerman at 8:10 AM on September 6, 2002
posted by dangerman at 8:10 AM on September 6, 2002
I work for a dev company and we charge many thousands.
I was actually wondering about edsousa's implication that the 'standards-zealots' have many-thousand-dollars budgets. A lot of the push for standards and experimentation with CSS came from professional designers, it's true, but they did their evangelising and experimenting on their personal sites on the whole. It was done on their own time, not on big budgets. The big-budget companies are the ones still sticking with 1997-style code.
posted by rory at 8:12 AM on September 6, 2002
I was actually wondering about edsousa's implication that the 'standards-zealots' have many-thousand-dollars budgets. A lot of the push for standards and experimentation with CSS came from professional designers, it's true, but they did their evangelising and experimenting on their personal sites on the whole. It was done on their own time, not on big budgets. The big-budget companies are the ones still sticking with 1997-style code.
posted by rory at 8:12 AM on September 6, 2002
Well, on the one hand, the customer is always right, so of course one would want to meet their demands; but on the other, professionals have some responsibility to educate their customers/employers about what is in their best long-term interests.
Oh, we tried. Boy did we try. They wouldn't budge though. The irony of it all is that it is a gov't agency and they had just been handed down new regulations to comply with the new Standards. That cracks me up.
Adaptation of new technology is not driven simply by ideology but by practicalities as well. If there are not clear advantages to XML, XHTML, and CSS over old HTML then people will not use the newer tech.
True, true.
Customers don't want to be educated...they want a site that looks like Dells.
hehe...dangerman rocks.
posted by poopy at 8:23 AM on September 6, 2002
Oh, we tried. Boy did we try. They wouldn't budge though. The irony of it all is that it is a gov't agency and they had just been handed down new regulations to comply with the new Standards. That cracks me up.
Adaptation of new technology is not driven simply by ideology but by practicalities as well. If there are not clear advantages to XML, XHTML, and CSS over old HTML then people will not use the newer tech.
True, true.
Customers don't want to be educated...they want a site that looks like Dells.
hehe...dangerman rocks.
posted by poopy at 8:23 AM on September 6, 2002
Customers don't want to be educated...they want a site that looks like Dells.
Again, how does this invalidate JZ's argument? "Want a site like Dell's? You got it. What? Doesn't work in Netscape 7, which you just upgraded to on Netscape's own advice? Sorry, but you asked for it."
It's a fair point, dangerman, but it's exactly the sort of problem JZ is trying to counteract by writing his book: by presenting the arguments for building forward-compatible sites, he's giving designers the mental tools to use in persuading their customers/bosses to let them do the same.
posted by rory at 8:23 AM on September 6, 2002
Again, how does this invalidate JZ's argument? "Want a site like Dell's? You got it. What? Doesn't work in Netscape 7, which you just upgraded to on Netscape's own advice? Sorry, but you asked for it."
It's a fair point, dangerman, but it's exactly the sort of problem JZ is trying to counteract by writing his book: by presenting the arguments for building forward-compatible sites, he's giving designers the mental tools to use in persuading their customers/bosses to let them do the same.
posted by rory at 8:23 AM on September 6, 2002
Should Matt take the time to remove the deprecated TABLE tags from MeFi?
uhh, the table tag isn't deprecated. The spirit of css is to replace tables as a layout tool, but a website can use tables for layout and still be 100% standards-compliant.
posted by jnthnjng at 8:23 AM on September 6, 2002
uhh, the table tag isn't deprecated. The spirit of css is to replace tables as a layout tool, but a website can use tables for layout and still be 100% standards-compliant.
posted by jnthnjng at 8:23 AM on September 6, 2002
Oh, we tried. Boy did we try. They wouldn't budge though.
Then more power to you. And your punchline shows exactly why it isn't a waste of time. If people want to dig their own graves, so be it. At least now they can't come after you for damages.
posted by rory at 8:26 AM on September 6, 2002
Then more power to you. And your punchline shows exactly why it isn't a waste of time. If people want to dig their own graves, so be it. At least now they can't come after you for damages.
posted by rory at 8:26 AM on September 6, 2002
I am of the belief that the "standards at all costs" approach is lacking, as the standards are not supported well in any browser. TABLEs are still the way to go. Whenever I encounter one of these uber-standards-compliant behemoth sites, I always make a note of how slow it is when scrolling up and down the page, and how they all use the same cookie-cutter effects (dotted lines, funky mouse cursors, etc). All-CSS pages are often slow. Browsers simply don't optimize the layout for CSS yet; they're still accustomed to rendering TABLEs. The push for proper DOCTYPEs (which signal the browser as to what kind of content/markup combo to expect) is a step in the right direction, but it's still not there yet.
Now admittedly, Zeldman's sites are quite nice, and most people couldn't lace his boots (to borrow a pro wrestling diss) in the web design arena. But since the WaSP initiative took flight, there's been a rash of poorly-designed but standards-compliant sites, whose authors take every possible opportunity to pat themselves on the back for not using "that evil TABLE". But are TABLEs that bad? Just because they're "obsolete" (strong language indeed; TABLEs are no more obsolete than, say, IE 5), not using them is good web design? Bollocks, I say. There are plenty of ways to seperate markup from content. What about XML/XSLT? Hell, what about Movable Type? I know it's not quite staunch seperation, but how much do you need?
I like Zeldman's push to get the browser makers implementing the W3C standards. That's a good cause, and I hope the WaSP presses on with it. But until the browsers themselves catch up with the standards, I'm not abandoning my beloved TABLEs, no way, no how.
posted by Succa at 8:29 AM on September 6, 2002
Now admittedly, Zeldman's sites are quite nice, and most people couldn't lace his boots (to borrow a pro wrestling diss) in the web design arena. But since the WaSP initiative took flight, there's been a rash of poorly-designed but standards-compliant sites, whose authors take every possible opportunity to pat themselves on the back for not using "that evil TABLE". But are TABLEs that bad? Just because they're "obsolete" (strong language indeed; TABLEs are no more obsolete than, say, IE 5), not using them is good web design? Bollocks, I say. There are plenty of ways to seperate markup from content. What about XML/XSLT? Hell, what about Movable Type? I know it's not quite staunch seperation, but how much do you need?
I like Zeldman's push to get the browser makers implementing the W3C standards. That's a good cause, and I hope the WaSP presses on with it. But until the browsers themselves catch up with the standards, I'm not abandoning my beloved TABLEs, no way, no how.
posted by Succa at 8:29 AM on September 6, 2002
Rory: My guess is that CSS is being used by people who have the extra budget to do "the right thing" from a software engineering/aesthetic/future-proofing perspective. That means either big corporate budgets with lots of extra padding, or personal sites done by people with a passion for good Web design.
The problem is how to justify standards-compliance for those who care more about budgets, delays, and customers. Reviewing Zeldman's bullet-point list of benefits at the end of his article, they're mostly about a theoretical future. There are only two points that I could hope to justify to a business manager in a recessionary economy:
Redesign in hours instead of days or weeks, reducing costs and eliminating grunt work.
Manager's response: But the savings only comes when I redesign, I'll pay that cost later instead of now.
Support multiple browsers without the hassle and expense of creating separate versions, and often with little or no code forking.
Manager's response: Sounds great. Do what you have to do to get it working fast with the majority of browsers my customers are using (including the older browsers).
Zeldman has to find a way to tell that manager how standards-compliance is cheaper, faster, better today.
posted by fuzz at 8:30 AM on September 6, 2002
The problem is how to justify standards-compliance for those who care more about budgets, delays, and customers. Reviewing Zeldman's bullet-point list of benefits at the end of his article, they're mostly about a theoretical future. There are only two points that I could hope to justify to a business manager in a recessionary economy:
Redesign in hours instead of days or weeks, reducing costs and eliminating grunt work.
Manager's response: But the savings only comes when I redesign, I'll pay that cost later instead of now.
Support multiple browsers without the hassle and expense of creating separate versions, and often with little or no code forking.
Manager's response: Sounds great. Do what you have to do to get it working fast with the majority of browsers my customers are using (including the older browsers).
Zeldman has to find a way to tell that manager how standards-compliance is cheaper, faster, better today.
posted by fuzz at 8:30 AM on September 6, 2002
Solution:
1) We need an international comitee - within the UN perhaps ? - to come up with new browser guidelines.
2) Until their work is done we put a ban on all software development (& technological progress in general while we're at it).
This will give everybody a chance to catch up. Within 10 years the comittee will have come up with something good, and by then everybody will be compliant with everybody.
posted by *JazZ* at 8:37 AM on September 6, 2002
1) We need an international comitee - within the UN perhaps ? - to come up with new browser guidelines.
2) Until their work is done we put a ban on all software development (& technological progress in general while we're at it).
This will give everybody a chance to catch up. Within 10 years the comittee will have come up with something good, and by then everybody will be compliant with everybody.
posted by *JazZ* at 8:37 AM on September 6, 2002
Should Matt take the time to remove the deprecated TABLE tags from MeFi?
There's only a couple uses of table tags on this site, for what it's worth. The top header graphic and nav, and form elements and buttons are using tables for layout, although a couple enterprising members have rewritten both to use pure CSS. I will eventually move to them, Netscape 4 be damned (the site will still look ok in NN4, just not pixel perfect).
The layout for all text (the margins, placement of comments, etc) has been CSS-based since early 1999.
posted by mathowie at 8:41 AM on September 6, 2002
There's only a couple uses of table tags on this site, for what it's worth. The top header graphic and nav, and form elements and buttons are using tables for layout, although a couple enterprising members have rewritten both to use pure CSS. I will eventually move to them, Netscape 4 be damned (the site will still look ok in NN4, just not pixel perfect).
The layout for all text (the margins, placement of comments, etc) has been CSS-based since early 1999.
posted by mathowie at 8:41 AM on September 6, 2002
i still use the table tag, sometimes, when i do layout. i think it can be used for purposes of layout and acceptably so. for example, i have a page on my website which lays out text side by side in two visual columns. i want the columns to be aligned; to have equal height, that is, so as to retain some visual connection between the two sides. i could use floats, and the height property; yet the height property is exactly defined, whereas the actual height of columns may differ according to context, and the height can still be ignored if text overflows. as i try to wrap my head around the hacks necessary to use css for the layout, i realize that the simpler solution is to use a table. each column gets a td cell, and the height expands for both cells to the maximum of either (which is what i wanted). it works for me, and it's not complicated.
posted by moz at 8:42 AM on September 6, 2002
posted by moz at 8:42 AM on September 6, 2002
As Succa says, you can produce perfectly valid (in the sense that it validates) XHTML + CSS and still use tables for layout. Did it myself, from Feb 2000 onwards; didn't start experimenting with CSS layout until a year or so later. It's a reasonable halfway house. But JZ's talking about future-proofing, which I suspect is why he gets up people's noses - it's impossible to really know the future, all we can do is guess, and some people don't like his guesses. Perhaps we are doomed to a future of pragmatic render-anything-no-matter-how-clunky browsers, so perhaps he's wrong. But the trend in browsers like Moz and NS7 suggests otherwise.
I'm not sure about 'css slow, tables fast' though, Succa. Loaded a Slashdot thread lately?
My guess is that CSS is being used by people who have the extra budget to do "the right thing" from a software engineering/aesthetic/future-proofing perspective. That means either big corporate budgets with lots of extra padding, or personal sites done by people with a passion for good Web design.
Maybe you're right. I was just thinking of people like Owen who've put major effort into mapping the strengths and weaknesses of CSS, pretty much as a labour of love.
posted by rory at 8:52 AM on September 6, 2002
I'm not sure about 'css slow, tables fast' though, Succa. Loaded a Slashdot thread lately?
My guess is that CSS is being used by people who have the extra budget to do "the right thing" from a software engineering/aesthetic/future-proofing perspective. That means either big corporate budgets with lots of extra padding, or personal sites done by people with a passion for good Web design.
Maybe you're right. I was just thinking of people like Owen who've put major effort into mapping the strengths and weaknesses of CSS, pretty much as a labour of love.
posted by rory at 8:52 AM on September 6, 2002
Should Matt take the time to remove the deprecated TABLE tags from MeFi?
You know, comments like that make me think "yup, 99% of web-designers know nothing about web applications" (I'm assuming you are). Web applications. You know, applications. They are not static, but perform a function depending on the user's interaction. MeFi is a database driven site feeding the user content from a database.
My point? Ever tried using CSS layers and DB content? Nightmare. Good 'ol HTML tables work well though for dynamic content. You'll find most of the popular web-sites use a truly dynamic content (not static) therefore the simpler the template, the better.
posted by SpaceCadet at 8:54 AM on September 6, 2002
You know, comments like that make me think "yup, 99% of web-designers know nothing about web applications" (I'm assuming you are). Web applications. You know, applications. They are not static, but perform a function depending on the user's interaction. MeFi is a database driven site feeding the user content from a database.
My point? Ever tried using CSS layers and DB content? Nightmare. Good 'ol HTML tables work well though for dynamic content. You'll find most of the popular web-sites use a truly dynamic content (not static) therefore the simpler the template, the better.
posted by SpaceCadet at 8:54 AM on September 6, 2002
Incidentally, why does Zeldman rarely mention database driven sites? He lives in a 1994 bubble where he assumes the whole internet is made up of static HTML pages uploaded by bloggers/corporate lackies. Why, in 7 years of web-designing, has he not at least picked up MS Access or SQL Server and seen the light of truly dynamic content (also a true separation of content and design where templates are used). He seems to have plateaued at some point in the mid-90's and from then on, meticuously focussed on standards.
posted by SpaceCadet at 9:00 AM on September 6, 2002
posted by SpaceCadet at 9:00 AM on September 6, 2002
zeldman.com just crashed my NS 4.7! ok, so it didn't crash but nothing came up and it told me there were javascript errors.
it takes tons more time to code layout for all browsers, but i do it the best i can (within reason) b/c for websites that are there to make money you just can't leave out anyone - they are all potential buyers no matter how ancient their setup.
but as someone mentioned earlier - you can write code to work on 4.x and higher and you'll still have problems. i was in the last week of finishing up a site for a client and it looked fine on all the browsers i checked in but then NS released v6 and suddenly the site didn't work anymore. it really pissed me off and i just wrote it off as netscape's problem.
posted by ggggarret at 9:02 AM on September 6, 2002
it takes tons more time to code layout for all browsers, but i do it the best i can (within reason) b/c for websites that are there to make money you just can't leave out anyone - they are all potential buyers no matter how ancient their setup.
but as someone mentioned earlier - you can write code to work on 4.x and higher and you'll still have problems. i was in the last week of finishing up a site for a client and it looked fine on all the browsers i checked in but then NS released v6 and suddenly the site didn't work anymore. it really pissed me off and i just wrote it off as netscape's problem.
posted by ggggarret at 9:02 AM on September 6, 2002
Why I use tables for layout:
<td valign="top">
When CSS has a simple equivalent to this (and a couple of other easy things with tables), I'll switch.
posted by normy at 9:04 AM on September 6, 2002
<td valign="top">
When CSS has a simple equivalent to this (and a couple of other easy things with tables), I'll switch.
posted by normy at 9:04 AM on September 6, 2002
Q: How is this any different from one of the proclamations from on high Jakob Nielsen throws out and everyone slams?
A: Not very. Do what works, as efficiently as possible.
posted by owillis at 9:07 AM on September 6, 2002
A: Not very. Do what works, as efficiently as possible.
posted by owillis at 9:07 AM on September 6, 2002
That'll teach me to try and make short posts. I meant <td valign="middle">, of course.
posted by normy at 9:07 AM on September 6, 2002
posted by normy at 9:07 AM on September 6, 2002
Those of you accusing Zeldman of ivory-tower zealotry disconnected from the problems of real-world Web design should read his Table Layouts, Revisited.
I love the anchor in that: "Regrets, I've had a few, but then again, too few to mention."
posted by timeistight at 9:14 AM on September 6, 2002
I love the anchor in that: "Regrets, I've had a few, but then again, too few to mention."
posted by timeistight at 9:14 AM on September 6, 2002
That's funny, I just got out of a meeting where the big-wigs requested blue links & the lines under them to diffuse confusion about what's "clickable" and what's not. I really don't trust these people to update their browsers--but I do trust I'll be the first one they call when something doesn't look right on their cousin's computer...
posted by Ms.JaneDoe at 9:15 AM on September 6, 2002
posted by Ms.JaneDoe at 9:15 AM on September 6, 2002
IMHO etc:
- 99.9% of web sites are not compliant, but 99.9% of web sites are also badly designed aesthetically (or, built to bad design briefs supplied by mangagement-clients-whose-kids have showed-them-a-flash-site...).
- Exploring the const raints of a just a few basic tags can produce good looking stuff.
- Many badly designed pages are also part of sites with horrendous architecture and navigation, which the page design then tries to cope with and compensate for.
- Ba d design ignor es the potential of mobile computing, very thin clients, etc.
FYI, here's Eric Raymond's HTML hell page. Eric also does not like using tables for layout.
Also FYI, here's the 5k web page challenge..
posted by carter at 9:17 AM on September 6, 2002
- 99.9% of web sites are not compliant, but 99.9% of web sites are also badly designed aesthetically (or, built to bad design briefs supplied by mangagement-clients-whose-kids have showed-them-a-flash-site...).
- Exploring the const raints of a just a few basic tags can produce good looking stuff.
- Many badly designed pages are also part of sites with horrendous architecture and navigation, which the page design then tries to cope with and compensate for.
- Ba d design ignor es the potential of mobile computing, very thin clients, etc.
FYI, here's Eric Raymond's HTML hell page. Eric also does not like using tables for layout.
Also FYI, here's the 5k web page challenge..
posted by carter at 9:17 AM on September 6, 2002
Succa, I've never noticed the slowdown on CSS sites, but in response to the boring CSS design, I would say without a doubt that What Do I Know? is probably the best designed XHTML 1.1 weblog I've seen. Great use of typography and graphics. Easy on the eyes and compliant.
My point? Ever tried using CSS layers and DB content? Nightmare. Good 'ol HTML tables work well though for dynamic content. You'll find most of the popular web-sites use a truly dynamic content (not static) therefore the simpler the template, the better.
spacecadet, dude you could not be more wrong. There's a huge justification for using CSS with db output, which is why I did it on this site three years ago: pages render MUCH, MUCH, MUCH faster in CSS than in a table.
Why?
A table will not display in a browser until the entire content of each table has completely been sent. If you have a slashdot.org account, you might notice the 20-30 second lag in mid-day when loading up slashdot. The top banner ad comes in fine, since it's not in a table, but the entire page's content must get sent from the db before showing up.
MetaFilter purposely doesn't use any tables for db output so pages can load incrementally. Load up a 100-200 comment thread and notice how you can read the initial link and first couple screenfulls of comments in a second or two, even though it may take 5 seconds or more to finish loading the page.
posted by mathowie at 9:22 AM on September 6, 2002
My point? Ever tried using CSS layers and DB content? Nightmare. Good 'ol HTML tables work well though for dynamic content. You'll find most of the popular web-sites use a truly dynamic content (not static) therefore the simpler the template, the better.
spacecadet, dude you could not be more wrong. There's a huge justification for using CSS with db output, which is why I did it on this site three years ago: pages render MUCH, MUCH, MUCH faster in CSS than in a table.
Why?
A table will not display in a browser until the entire content of each table has completely been sent. If you have a slashdot.org account, you might notice the 20-30 second lag in mid-day when loading up slashdot. The top banner ad comes in fine, since it's not in a table, but the entire page's content must get sent from the db before showing up.
MetaFilter purposely doesn't use any tables for db output so pages can load incrementally. Load up a 100-200 comment thread and notice how you can read the initial link and first couple screenfulls of comments in a second or two, even though it may take 5 seconds or more to finish loading the page.
posted by mathowie at 9:22 AM on September 6, 2002
fuzz: obviously there is a continuum of amateur to professional web developers out there. i'm not advocating a hardline cut-off point. what I am saying is that the more professional you are (i.e. designing and developing web sites, for clients, for money) the more you should stay abreast of developments in technology.
The more you know about standards, and how easy some of them are to incorporate (e.g. closing empty tags), the more it will creep into your normal workflow. I can't see a reason to actively NOT KNOW about something that pertains to your industry, and will become increasingly common as time goes by.
"Zeldman has to find a way to tell that manager how standards-compliance is cheaper, faster, better today."
-- it's my understanding that his new book is all about this. The business case for web standards. I may be wrong, but that's my impression.
Once again, I re-iterate my observance of the transitional nature of this discussion. JZ saying "we call for all web developers out there to make incremental improvments in their coding standards" isn't exactly a clarion call to action. So there's a little hyperbole; it's meant to gather attention.
In reality, we can still use a basic "framing" TABLE layout, fortified with a reasonable amount of CSS for fonts and colors, and STILL VALIDATE, even against HTML 4.01 Transitional, without parting with targets, heights, widths, cellpadding, etc. etc. etc.
Let's start moving towards the goal of fully standards-compliant design. NOT A WHOLESALE JUMP FOR EVERY IMAGINABLE SITE. Or is there a really good reason to intentionally avoid all standards? What do you gain by not closing P tags? I don't follow the logic here.
And as for the idea that the web wouldn't have been the same if the browsers weren't fault-tolerant, that's just crazy. I mean, if I want to make an ordered list, I use OL. I do so because that's how it's done. If, this whole time, you had to close empty tags (<br />) for example, everyone would just do that, and every WYSIWIG tool would put out tags like that. We don't see FrontPage generating <breaker> instead of <br> do we?
posted by Phatbank at 9:22 AM on September 6, 2002
The more you know about standards, and how easy some of them are to incorporate (e.g. closing empty tags), the more it will creep into your normal workflow. I can't see a reason to actively NOT KNOW about something that pertains to your industry, and will become increasingly common as time goes by.
"Zeldman has to find a way to tell that manager how standards-compliance is cheaper, faster, better today."
-- it's my understanding that his new book is all about this. The business case for web standards. I may be wrong, but that's my impression.
Once again, I re-iterate my observance of the transitional nature of this discussion. JZ saying "we call for all web developers out there to make incremental improvments in their coding standards" isn't exactly a clarion call to action. So there's a little hyperbole; it's meant to gather attention.
In reality, we can still use a basic "framing" TABLE layout, fortified with a reasonable amount of CSS for fonts and colors, and STILL VALIDATE, even against HTML 4.01 Transitional, without parting with targets, heights, widths, cellpadding, etc. etc. etc.
Let's start moving towards the goal of fully standards-compliant design. NOT A WHOLESALE JUMP FOR EVERY IMAGINABLE SITE. Or is there a really good reason to intentionally avoid all standards? What do you gain by not closing P tags? I don't follow the logic here.
And as for the idea that the web wouldn't have been the same if the browsers weren't fault-tolerant, that's just crazy. I mean, if I want to make an ordered list, I use OL. I do so because that's how it's done. If, this whole time, you had to close empty tags (<br />) for example, everyone would just do that, and every WYSIWIG tool would put out tags like that. We don't see FrontPage generating <breaker> instead of <br> do we?
posted by Phatbank at 9:22 AM on September 6, 2002
spacecadet, dude you could not be more wrong. There's a huge justification for using CSS with db output, which is why I did it on this site three years ago: pages render MUCH, MUCH, MUCH faster in CSS than in a table.
First thing, ever heard of paging? I know /. don't do that and neither do MeFi, but paging content is better than displaying a massive list of posts/FPPs (easier to scroll too) - 20 posts per page or something. Also, in ASP, it's possible to display content IMMEDIATELY as it's rendered even in individual table cells (Response.Flush). Apps programmers have full control over the rendering of a page, tables or not.
But come on! What does your code look like with layers and dynamic content? You still tabulate your data, right? You know, basically rows and columns to make it easier to read? If that's what you do, what's wrong with tables? If you choose to physically layer data over each other, then that's up to you. Each to their own.
posted by SpaceCadet at 10:04 AM on September 6, 2002
First thing, ever heard of paging? I know /. don't do that and neither do MeFi, but paging content is better than displaying a massive list of posts/FPPs (easier to scroll too) - 20 posts per page or something. Also, in ASP, it's possible to display content IMMEDIATELY as it's rendered even in individual table cells (Response.Flush). Apps programmers have full control over the rendering of a page, tables or not.
But come on! What does your code look like with layers and dynamic content? You still tabulate your data, right? You know, basically rows and columns to make it easier to read? If that's what you do, what's wrong with tables? If you choose to physically layer data over each other, then that's up to you. Each to their own.
posted by SpaceCadet at 10:04 AM on September 6, 2002
BTW, mathowie, nothing strong against MeFi's design personally...just wanted to show you there's more than one way to skin a cat (as you're probably as much aware of as we all are).
posted by SpaceCadet at 10:10 AM on September 6, 2002
posted by SpaceCadet at 10:10 AM on September 6, 2002
But come on! What does your code look like with layers and dynamic content? You still tabulate your data, right? You know, basically rows and columns to make it easier to read? If that's what you do, what's wrong with tables?
I think there's some sort of disconnect here between what I'm talking about with CSS and what you mean by "layers."
Tables are for tabular data, but there is very little of that in the apps I build. Most the apps I build, like this one, are basically just content management systems, so while the data exists in a tabular structure on the db server, on the output side of things, it's basically just text.
If you are going to put a table around every comment or post in a site, you're going to have a slow app, regardless of your server side technology. Instead of putting the entire metafilter page in a table, with 50 pixel wide blank gifs in empty cells on the sides, I simply make margins with CSS. Throw a div around the output and add "margin-left:50px; margin-right:50px;" and it looks exactly the same, but renders quickly in all browsers I've tested vs. tables.
I could create a test page if you don't believe me on the speed thing.
posted by mathowie at 10:15 AM on September 6, 2002
I think there's some sort of disconnect here between what I'm talking about with CSS and what you mean by "layers."
Tables are for tabular data, but there is very little of that in the apps I build. Most the apps I build, like this one, are basically just content management systems, so while the data exists in a tabular structure on the db server, on the output side of things, it's basically just text.
If you are going to put a table around every comment or post in a site, you're going to have a slow app, regardless of your server side technology. Instead of putting the entire metafilter page in a table, with 50 pixel wide blank gifs in empty cells on the sides, I simply make margins with CSS. Throw a div around the output and add "margin-left:50px; margin-right:50px;" and it looks exactly the same, but renders quickly in all browsers I've tested vs. tables.
I could create a test page if you don't believe me on the speed thing.
posted by mathowie at 10:15 AM on September 6, 2002
I agree with SpaceCadet on the web applications argument. Here's a challenge for the CSS crowd: Why won't you try building a fully functioning and pleasing PHP-Nuke theme without using a single TABLE (Oh, and don't you forget to change Nuke's table generation routines as well)?
Is it just me or 99% of CSS-only websites are typical two collumn weblogs?
posted by edsousa at 10:20 AM on September 6, 2002
Is it just me or 99% of CSS-only websites are typical two collumn weblogs?
posted by edsousa at 10:20 AM on September 6, 2002
I'm not sure about 'css slow, tables fast' though, Succa. Loaded a Slashdot thread lately?
Try going to a CSS-only page with a couple of screens worth of data, using IE. Scroll up and down. Notice the lag. Then go to a table-driven site with the same amount of data, and repeat. Notice the difference.
There's a difference on my end, anyway, and I'm using IE 6. Not sure if Mozilla has the same problem.
Also, in IE, dotted-line borders around page elements don't render very well while the page is being scrolled.
What Do I Know? is beautiful, yes. But I still find that CSS-only sites have a "feel" to them. I can almost always tell a CSS site from a TABLE site without looking at the source, just by how slow the rendering engine is while I browse around. Am I alone here?
posted by Succa at 10:29 AM on September 6, 2002
Try going to a CSS-only page with a couple of screens worth of data, using IE. Scroll up and down. Notice the lag. Then go to a table-driven site with the same amount of data, and repeat. Notice the difference.
There's a difference on my end, anyway, and I'm using IE 6. Not sure if Mozilla has the same problem.
Also, in IE, dotted-line borders around page elements don't render very well while the page is being scrolled.
What Do I Know? is beautiful, yes. But I still find that CSS-only sites have a "feel" to them. I can almost always tell a CSS site from a TABLE site without looking at the source, just by how slow the rendering engine is while I browse around. Am I alone here?
posted by Succa at 10:29 AM on September 6, 2002
phpnuke could easily be replicated in CSS. Take this layout, throw a div around all three columns, so they're on a single white background, then simply use CSS borders for posts along the middle. I'm building a site right now that's about as complex as phpnuke.org, and it's all in CSS. It's not that hard to do.
Someone even got Amazon.com into XHTML 1.1 strict, and it also meets section 508 and Bobby specs, and not a single table was used.
posted by mathowie at 10:31 AM on September 6, 2002
Someone even got Amazon.com into XHTML 1.1 strict, and it also meets section 508 and Bobby specs, and not a single table was used.
posted by mathowie at 10:31 AM on September 6, 2002
From my own perpsective as a page monkey for an academic institution, it is a tough battle - bringing along an administration without an interest in how the information is served to them from a theoretical standpoint has had more than a few compromises. On the other hand, we are on the cusp of unveiling a site-wide redesign that uses tables for tabular data or in the event of non-essential display-oriented mark-up (ie head banners).
Along the way I've had the support of my supervisor to devote some extensive time to developing a system of CSS selectors that help pages degrade gracefully in non-compliant browsers without losing much aesthetic value.
All of this to say that, standards-compliant coding IS important, the 'radical' separation of content from display IS possible, and that all of this can be done on a commercial/professional level. It isn't as easy as one might hope, but why should a professional discipline be easy?
posted by Fezboy! at 10:34 AM on September 6, 2002
Along the way I've had the support of my supervisor to devote some extensive time to developing a system of CSS selectors that help pages degrade gracefully in non-compliant browsers without losing much aesthetic value.
All of this to say that, standards-compliant coding IS important, the 'radical' separation of content from display IS possible, and that all of this can be done on a commercial/professional level. It isn't as easy as one might hope, but why should a professional discipline be easy?
posted by Fezboy! at 10:34 AM on September 6, 2002
One more URL to share: Blogroots is pretty close to many phpnuke/slash/scoop site designs, and it's pure CSS for layout. I coded it using CSS techniques that are backward compatible with Netscape 4, from realworldstyle
posted by mathowie at 10:36 AM on September 6, 2002
posted by mathowie at 10:36 AM on September 6, 2002
I would just like to say, from personal experience, that it is far easier to learn CSS and XHTML than it is to learn nonsensical "presentational" HTML. I tried learning HTML about three years ago, and gave up because of the ridiculousness of the whole affair -- none of it made any sense. A year later, I started learning about CSS, and all of a sudden everything made sense. I love doing CSS layouts, and I've been using one on my personal site for a while now. In fact I just did my first professional design (for a non-profit client, so the budget was definitely small). I've actually got a pretty good intuitive sense of this stuff, and I find that I can make my pages look virtually identical in Moz and IE without even resorting to box-model hacks and the like.
I still can't do table layouts, and I often find myself resorting to the W3C recommendations whenever I have to put down some tabular data. To each his own.
posted by Ptrin at 10:57 AM on September 6, 2002
I still can't do table layouts, and I often find myself resorting to the W3C recommendations whenever I have to put down some tabular data. To each his own.
posted by Ptrin at 10:57 AM on September 6, 2002
Amusing that Zeldman has no idea how revolutionary the "it renders, no matter what" model was
Amusing that people presume to know the entire contents of his mind on the basis of one brief article excerpted from a full-length book.
Well, he exposes some pretty nasty lack-o-clues -- the Yahoo swipe, believing the problem with wireless web has anything to do with markup languages, zero tolerance for people who can't grasp every last shibboleth of web coding...
Yack. Like I said, the man certainly knows some stuff, but damn. Those who forget the past are condemned to repeat it, a la the inevitable return to the fat client / thin client wars.
I'll actually poke around more of his writings -- I think you're right, in that I should know more about what he thinks.
Incidentally, the locality that CSS "elegantly removes" is astonishingly critical for usability purposes. Styles have existed since the early days of Word; I know nobody who uses them. Insult users if you like, but humans tend to attach the modifier to the word, not the type.
You dynamic website programmers have a decent handle on why.
--Dan
posted by effugas at 11:02 AM on September 6, 2002
Amusing that people presume to know the entire contents of his mind on the basis of one brief article excerpted from a full-length book.
Well, he exposes some pretty nasty lack-o-clues -- the Yahoo swipe, believing the problem with wireless web has anything to do with markup languages, zero tolerance for people who can't grasp every last shibboleth of web coding...
Yack. Like I said, the man certainly knows some stuff, but damn. Those who forget the past are condemned to repeat it, a la the inevitable return to the fat client / thin client wars.
I'll actually poke around more of his writings -- I think you're right, in that I should know more about what he thinks.
Incidentally, the locality that CSS "elegantly removes" is astonishingly critical for usability purposes. Styles have existed since the early days of Word; I know nobody who uses them. Insult users if you like, but humans tend to attach the modifier to the word, not the type.
You dynamic website programmers have a decent handle on why.
--Dan
posted by effugas at 11:02 AM on September 6, 2002
Succa said: ... I still find that CSS-only sites have a "feel" to them. I can almost always tell a CSS site from a TABLE site without looking at the source, just by how slow the rendering engine is while I browse around. Am I alone here?
I'm with you. CSS-only sites are many times slower than table-based ones, especially when pages get long. Example: try scrolling up and down Kung Fu Grippe, an XHTML/CSS concoction, versus scrolling up and down this page. There's a noticable stutter with KFG.
posted by dayvin at 11:09 AM on September 6, 2002
I'm with you. CSS-only sites are many times slower than table-based ones, especially when pages get long. Example: try scrolling up and down Kung Fu Grippe, an XHTML/CSS concoction, versus scrolling up and down this page. There's a noticable stutter with KFG.
posted by dayvin at 11:09 AM on September 6, 2002
> 99.9% of Websites Are Obsolete
Warning, self link. Here's one of those obsolete pages that I wrote in the mid-90s and which (I note with some pride in these days when sites come and go like dandilions) is still up lo these many years later -- people refer to it all the time to get the analytical protocols.
Some other party has rather crudely pasted on a "new" squawk on the top page about a Toshiba TOC analyzer that I didn't have when I ran the lab, and I also note that they've thoroughly dicked up the fees page (oval buttons, forsooth,) but otherwise the whole site is just exactly as I left it when I quit being a bench chemist and went off to do computers full time.
I mention this in order to note that this whole set of pages renders in IE6 and Mozilla 1.0 just exactly the same as it did in Netscape 3 and Mosaic I-forget-what, the then-dominant browsers I wrote them for.
You want an eternal, universal, renders-the-same-everywhere standard? I give you html 1.0
posted by jfuller at 11:12 AM on September 6, 2002
Warning, self link. Here's one of those obsolete pages that I wrote in the mid-90s and which (I note with some pride in these days when sites come and go like dandilions) is still up lo these many years later -- people refer to it all the time to get the analytical protocols.
Some other party has rather crudely pasted on a "new" squawk on the top page about a Toshiba TOC analyzer that I didn't have when I ran the lab, and I also note that they've thoroughly dicked up the fees page (oval buttons, forsooth,) but otherwise the whole site is just exactly as I left it when I quit being a bench chemist and went off to do computers full time.
I mention this in order to note that this whole set of pages renders in IE6 and Mozilla 1.0 just exactly the same as it did in Netscape 3 and Mosaic I-forget-what, the then-dominant browsers I wrote them for.
You want an eternal, universal, renders-the-same-everywhere standard? I give you html 1.0
posted by jfuller at 11:12 AM on September 6, 2002
"1994 bubble"
99.9% of Happy Cog's sites work with a content management system. Sometimes it's one we've inherited. Other times we produce it. One of our partners has been designing custom publishing tools since the mid-90s for companies like Intel and Business Week.
I author my personal site by hand because it pleases me to do so. I "hand-code" all the sites I design because doing so affords me the greatest control over my markup, code, and style sheets. But what I'm generally designing is templates for use in a database-driven site.
The few examples of bad markup used in this first draft excerpt from one chapter of my upcoming book were taken from pages we inherited when Happy Cog was asked to re-design large, CMS-driven commercial sites. In nearly every case we were able to replace the bad markup with good clean valid markup. Note that in so doing we did not break the existing CMS. We simply got it to replace one set of tags and attributes with another. It's not always possible to do that but it often is.
Nowhere in the chapter excerpt do I insist on pure CSS layout. Nowhere in the book will I insult people who use transitional solutions. We use transitional solutions too, and the book will include tips on creating them.
If you visit zeldman.com today you'll find some additional thoughts that may change some misunderstandings.
posted by Zeldman at 11:19 AM on September 6, 2002
99.9% of Happy Cog's sites work with a content management system. Sometimes it's one we've inherited. Other times we produce it. One of our partners has been designing custom publishing tools since the mid-90s for companies like Intel and Business Week.
I author my personal site by hand because it pleases me to do so. I "hand-code" all the sites I design because doing so affords me the greatest control over my markup, code, and style sheets. But what I'm generally designing is templates for use in a database-driven site.
The few examples of bad markup used in this first draft excerpt from one chapter of my upcoming book were taken from pages we inherited when Happy Cog was asked to re-design large, CMS-driven commercial sites. In nearly every case we were able to replace the bad markup with good clean valid markup. Note that in so doing we did not break the existing CMS. We simply got it to replace one set of tags and attributes with another. It's not always possible to do that but it often is.
Nowhere in the chapter excerpt do I insist on pure CSS layout. Nowhere in the book will I insult people who use transitional solutions. We use transitional solutions too, and the book will include tips on creating them.
If you visit zeldman.com today you'll find some additional thoughts that may change some misunderstandings.
posted by Zeldman at 11:19 AM on September 6, 2002
Well, seeing as this site is done in CSS, not tables, I don't quite get your point, dayvin. But I'd also like to say that since neither site stutters in Mozilla 1.0, maybe your browser sucks? Actually, since neither site stutters on my PII 300 machine with NS 6, either, I'm going to go right ahead and take out that maybe.
And why does every damn table-based site look like it was made in '98? Why can't we get some innovation?
[/attitude]
You know, CSS really is the bees knees. It makes tables look square, daddio! You should try it some time : )
posted by Ptrin at 11:28 AM on September 6, 2002
And why does every damn table-based site look like it was made in '98? Why can't we get some innovation?
[/attitude]
You know, CSS really is the bees knees. It makes tables look square, daddio! You should try it some time : )
posted by Ptrin at 11:28 AM on September 6, 2002
dayvin:
I'm with you. CSS-only sites are many times slower than table-based ones, especially when pages get long. Example: try scrolling up and down Kung Fu Grippe, an XHTML/CSS concoction, versus scrolling up and down this page. There's a noticable stutter with KFG.
in mozilla 1.1, both Kung Fu Grippe and Metafilter scroll at just about the same speed on my machine (a p2 300 with 128M ram). i'm not really sure what's causing the stutter, but i will say that it sounds like a browser problem.
posted by moz at 11:33 AM on September 6, 2002
I'm with you. CSS-only sites are many times slower than table-based ones, especially when pages get long. Example: try scrolling up and down Kung Fu Grippe, an XHTML/CSS concoction, versus scrolling up and down this page. There's a noticable stutter with KFG.
in mozilla 1.1, both Kung Fu Grippe and Metafilter scroll at just about the same speed on my machine (a p2 300 with 128M ram). i'm not really sure what's causing the stutter, but i will say that it sounds like a browser problem.
posted by moz at 11:33 AM on September 6, 2002
The web is PowerPoint...standards are not necessary.
Seriously tho...try making a valid technical point to a corporate Marketing VP or BU VP and see how well it flys.
These folks barely know how to use their browser/email and are completely unconcerned with any behind-the-curtain xhtml goodness. All they want is a Flash intro like so-and-so and to implement this document conversion tool as a CMS (transit central)...and if you start giving any lip about it...you're fired.
Hey I love standards...I get hard thinking about well structured valid markup...
...but these decisions are not in the designer/developers hands...they're in the clients hands and we are at the mercy of whatever they thought looked neat-o-jet in their AOL4 browser last night. Educate the client...fuck...not in this corporate world.
posted by dangerman at 11:40 AM on September 6, 2002
Seriously tho...try making a valid technical point to a corporate Marketing VP or BU VP and see how well it flys.
These folks barely know how to use their browser/email and are completely unconcerned with any behind-the-curtain xhtml goodness. All they want is a Flash intro like so-and-so and to implement this document conversion tool as a CMS (transit central)...and if you start giving any lip about it...you're fired.
Hey I love standards...I get hard thinking about well structured valid markup...
...but these decisions are not in the designer/developers hands...they're in the clients hands and we are at the mercy of whatever they thought looked neat-o-jet in their AOL4 browser last night. Educate the client...fuck...not in this corporate world.
posted by dangerman at 11:40 AM on September 6, 2002
I have to agree with mathowie (because I'm an enormous ass-kiss) about CSS and dynamic sites. To truly learn PHP, I set out to replicate most of the behavior of this site from scratch. The difference between rendering posts and/or comments as individual tables and rendering in DIVs was, well, I dunno, minutes. Seriously. It's ok if you're just generating rows dynamically, but anything more is unacceptably slow. And the CSS source code is beautifully readable*.
* assumes a certain amount of anal-retentiveness**
** I don't know what ass-kiss + anal-retentive equals, but it can't be good.
posted by yerfatma at 11:55 AM on September 6, 2002
* assumes a certain amount of anal-retentiveness**
** I don't know what ass-kiss + anal-retentive equals, but it can't be good.
posted by yerfatma at 11:55 AM on September 6, 2002
Also, the bigger the budget, the more backwards-compatible in my experience. The only times I've been allowed to romp around in unfettered CSS glory were HTML interfaces for online applications that could dictate browser requirements.
posted by yerfatma at 11:57 AM on September 6, 2002
posted by yerfatma at 11:57 AM on September 6, 2002
Dangerman:
What we do is show the client the templates and say "we've created a system that will make it easier for you to update these pages." When possible we let the client update the content live on the staging server and see how the design effects stay crisp in milk. This is before the CMS, with clients who are web-savvy. With those are less than web-savvy, we change the content for them on the fly, show them how the design stays in place, and they walk away thinking they were smart to hire us. We don't talk CSS2 etc. unless we have to, and we rarely have to.
Not every tag can always be structural, not every site can or should use pure CSS layout. The book is for working people, not purists. But the business case also must be made, and in the first part of the book I hope to do that. If I succeed, it will make your job easier and more importantly it will make MY job easier.
posted by Zeldman at 11:59 AM on September 6, 2002
What we do is show the client the templates and say "we've created a system that will make it easier for you to update these pages." When possible we let the client update the content live on the staging server and see how the design effects stay crisp in milk. This is before the CMS, with clients who are web-savvy. With those are less than web-savvy, we change the content for them on the fly, show them how the design stays in place, and they walk away thinking they were smart to hire us. We don't talk CSS2 etc. unless we have to, and we rarely have to.
Not every tag can always be structural, not every site can or should use pure CSS layout. The book is for working people, not purists. But the business case also must be made, and in the first part of the book I hope to do that. If I succeed, it will make your job easier and more importantly it will make MY job easier.
posted by Zeldman at 11:59 AM on September 6, 2002
Ptrin, I am using IE5/Win right now, which does indeed suck, but I have also noticed the problem at home on IE5.1/Mac, so go figure. Indeed, Metafilter does not use tables, but it also doesn't have <div>s all over the place like KFG. Still, I continue to agree with Succa that CSS sites have a certain "feel" about them that's different from their table-based counterparts.
posted by dayvin at 12:00 PM on September 6, 2002
posted by dayvin at 12:00 PM on September 6, 2002
Those of you accusing Zeldman of ivory-tower zealotry disconnected from the problems of real-world Web design should read his Table Layouts, Revisited.
By the way, I believe the "bug" mentioned towards the end of that article can be fixed by setting the height of the div to 100%. That certainly seems to have fixed it on one of my sites, after someone recommended it to me.
posted by walrus at 12:00 PM on September 6, 2002
By the way, I believe the "bug" mentioned towards the end of that article can be fixed by setting the height of the div to 100%. That certainly seems to have fixed it on one of my sites, after someone recommended it to me.
posted by walrus at 12:00 PM on September 6, 2002
These folks barely know how to use their browser/email and are completely unconcerned with any behind-the-curtain xhtml goodness. All they want is a Flash intro like so-and-so and to implement this document conversion tool as a CMS (transit central)...
This is so true. Reminds me of a client who a couple of years ago created their own flash animation and insisted that we use it on the homepage. It was of a big wiggly red lizard-like creature that danced back and forth, back and forth. It was murder on the eyes and destroyed an otherwise nice layout. Even worse, most people couldn't even tell what the hell it was supposed to be...from a distance, it looked like a big red dancing penis.
Needless to say, it didn't take long before the complaints came pouring in and our red penis friend had to take a premature departure.
posted by poopy at 12:03 PM on September 6, 2002
This is so true. Reminds me of a client who a couple of years ago created their own flash animation and insisted that we use it on the homepage. It was of a big wiggly red lizard-like creature that danced back and forth, back and forth. It was murder on the eyes and destroyed an otherwise nice layout. Even worse, most people couldn't even tell what the hell it was supposed to be...from a distance, it looked like a big red dancing penis.
Needless to say, it didn't take long before the complaints came pouring in and our red penis friend had to take a premature departure.
posted by poopy at 12:03 PM on September 6, 2002
Speaking of CSS bugs, there's a nasty one on IE6 where many CSS-only sites (typically weblogs) won't scroll to the end of the content (i.e. imagine a typical two-collumn blog - the main content area has more vertical information than the side collumn, but won't scroll past the end of the small collumn). Apparentely hitting F11 twice (switching full-screen mode on and off) solves the thing. But yes, CSS rendering still has a long way to go. CSS-only sites are a pain in the arse when I use IE5.5 on my old Cyrix166 (which I use mostly for testing purposes).
Funny thing, when I took my Dreamweaver course 3 years ago rule number one was "Don't use 'Layers'/DIVs when you can use tables".
posted by edsousa at 12:12 PM on September 6, 2002
Funny thing, when I took my Dreamweaver course 3 years ago rule number one was "Don't use 'Layers'/DIVs when you can use tables".
posted by edsousa at 12:12 PM on September 6, 2002
A wise person once said:
"Most company owners will rather spend 5000euros on a doormat than 500euros on a good website for their business."
Mind you, Portugal has perhaps the worst record in company performance in Europe, but this might be true in other countries, no?
posted by edsousa at 12:15 PM on September 6, 2002
"Most company owners will rather spend 5000euros on a doormat than 500euros on a good website for their business."
Mind you, Portugal has perhaps the worst record in company performance in Europe, but this might be true in other countries, no?
posted by edsousa at 12:15 PM on September 6, 2002
designing sites for businesses who make all their money on web sales is tough due to all the browser issues and standards. i use netscape 4.78 as my bottom of the barrel compatibility tester - is it time to move on? what percentage of possible customers are you leaving out by bumping up the version cuttoff to NS6/IE6?
there are depressingly few CSS styles that seem to work correctly in NS4.78 and some that still don't work in NS6. as much as i'd love to build all my sites with more CSS layout and not just font control, i rarely find a site that renders the same in both NS and IE. metafilter.com doesn't do it, zeldman.com doesn't do it, i can't think of anyone's site that does. where's the incentive to change to something that looks like poop for 15% of the traffic?
posted by ggggarret at 12:20 PM on September 6, 2002
there are depressingly few CSS styles that seem to work correctly in NS4.78 and some that still don't work in NS6. as much as i'd love to build all my sites with more CSS layout and not just font control, i rarely find a site that renders the same in both NS and IE. metafilter.com doesn't do it, zeldman.com doesn't do it, i can't think of anyone's site that does. where's the incentive to change to something that looks like poop for 15% of the traffic?
posted by ggggarret at 12:20 PM on September 6, 2002
Big Z you're missing my point...we don't have a say...we are not some hip cool SF design firm approaching Big Bobs Sporting Goods for a new web site.
This is corporate web...Global Marketing teams and 30 year vested VP's dictate what we make...how we make it...and with what. You want to reach me...you want to understand why 99.9% of the web is broke...sit in this cubicle for 2 years.
I'm tired of reading all the SC's preaching about how ignorant and lazy we designers and developers are.
I can write code so sweet it would make you cry...
I can spin CSS that would make glish wet himself...
Thing is...I just got told our new global template is a 6 framed site with tables used as buttons.
I never once got asked "Hey...you think this stays crispy in milk?"
posted by dangerman at 12:24 PM on September 6, 2002
This is corporate web...Global Marketing teams and 30 year vested VP's dictate what we make...how we make it...and with what. You want to reach me...you want to understand why 99.9% of the web is broke...sit in this cubicle for 2 years.
I'm tired of reading all the SC's preaching about how ignorant and lazy we designers and developers are.
I can write code so sweet it would make you cry...
I can spin CSS that would make glish wet himself...
Thing is...I just got told our new global template is a 6 framed site with tables used as buttons.
I never once got asked "Hey...you think this stays crispy in milk?"
posted by dangerman at 12:24 PM on September 6, 2002
Just a chime-in from an Amazon.com webdev. That CSS XHTML-strict demo page of Amazon.com that mathowie pointed to (here) looks great, yes - in a newer browser. Have you seen what it looks like in NN4? (screenshot).
I don't mean this a cheap shot, but just wanted to point out the difficulty in changing what is essentially ugly-but-functional markup into standards-compliant-but-widely-viewable markup. By widely viewable, I mean you have to give a hard business case to either spend the time to redesign in a cross-platform manner and not lose any customers - or go whole-hog, move forward and lose potentially 10-20% of your customers.
Yes, I am aware that there are a great many shades of gray between noncompliant crufty code and full XHTML-validation, and every little step on the way counts (and Amazon is making strides, if slowly). I got too involved in this same discussion yesterday, and found it hard to summarize, but - In my opinion, from the standpoint of large-scale older sites: Yes, standards are good. Making half-steps toward standardization can be difficult, even with fantastic help, but full standardization is a mirage in the distance now. The payoff vs. the cost is is too lopsided. As long as there is no demonstrable detriment to publishing non-compliant code, it's going to exist. (I know there are arguments that future costs of maintaining broken code are saved by standardizing, but I honestly think that's an overstatement).
posted by kokogiak at 12:26 PM on September 6, 2002
I don't mean this a cheap shot, but just wanted to point out the difficulty in changing what is essentially ugly-but-functional markup into standards-compliant-but-widely-viewable markup. By widely viewable, I mean you have to give a hard business case to either spend the time to redesign in a cross-platform manner and not lose any customers - or go whole-hog, move forward and lose potentially 10-20% of your customers.
Yes, I am aware that there are a great many shades of gray between noncompliant crufty code and full XHTML-validation, and every little step on the way counts (and Amazon is making strides, if slowly). I got too involved in this same discussion yesterday, and found it hard to summarize, but - In my opinion, from the standpoint of large-scale older sites: Yes, standards are good. Making half-steps toward standardization can be difficult, even with fantastic help, but full standardization is a mirage in the distance now. The payoff vs. the cost is is too lopsided. As long as there is no demonstrable detriment to publishing non-compliant code, it's going to exist. (I know there are arguments that future costs of maintaining broken code are saved by standardizing, but I honestly think that's an overstatement).
posted by kokogiak at 12:26 PM on September 6, 2002
Speaking of CSS bugs, there's a nasty one on IE6 where many CSS-only sites (typically weblogs) won't scroll to the end of the content (i.e. imagine a typical two-collumn blog - the main content area has more vertical information than the side collumn, but won't scroll past the end of the small collumn). Apparentely hitting F11 twice (switching full-screen mode on and off) solves the thing.
Or by setting the height of the div to 100%.
posted by walrus at 12:33 PM on September 6, 2002
Or by setting the height of the div to 100%.
posted by walrus at 12:33 PM on September 6, 2002
ps - zeldman, nice tunes - i've been enjoying them all day.
posted by ggggarret at 12:36 PM on September 6, 2002
posted by ggggarret at 12:36 PM on September 6, 2002
Dangerman:
What you've described is common and I've been there. Simply because I'm older than you, I've probably spent more years than you doing stuff I didn't believe in at the dictate of clueless @$#wits who thought they knew best.
That's exactly why I'm spending so much energy making the business case for standards in the book I'm writing. Because it's business people with little to no web expertise who far too often decide how sites should be designed, built, written, structured, served, etc. Maybe a few of them will have an awakening if the book hits the mark, is adequately promoted, etc. Many won't, and that's the way of the world.
You seem to imply you're being judged for turning out sites built to the dictates of less-than-knowledgeable managers. Who's judging you? Not me. You think all my sites are perfectly compliant? You think I always sell the beautiful design, the good words, the smart architecture? Nobody does. Not to get all hippieish on your ass but in a real way those of us who do this work are brothers and sisters. At the very least, we're colleagues. Judgmental people are lacking in humanity, whether they're putting you down for doing your job, or putting me down for doing mine.
posted by Zeldman at 12:44 PM on September 6, 2002
What you've described is common and I've been there. Simply because I'm older than you, I've probably spent more years than you doing stuff I didn't believe in at the dictate of clueless @$#wits who thought they knew best.
That's exactly why I'm spending so much energy making the business case for standards in the book I'm writing. Because it's business people with little to no web expertise who far too often decide how sites should be designed, built, written, structured, served, etc. Maybe a few of them will have an awakening if the book hits the mark, is adequately promoted, etc. Many won't, and that's the way of the world.
You seem to imply you're being judged for turning out sites built to the dictates of less-than-knowledgeable managers. Who's judging you? Not me. You think all my sites are perfectly compliant? You think I always sell the beautiful design, the good words, the smart architecture? Nobody does. Not to get all hippieish on your ass but in a real way those of us who do this work are brothers and sisters. At the very least, we're colleagues. Judgmental people are lacking in humanity, whether they're putting you down for doing your job, or putting me down for doing mine.
posted by Zeldman at 12:44 PM on September 6, 2002
edsousa:
Youngpup came up with a simple JavaScript workaround for that CSS rendering bug in IE6. See CSS Layout Revisited on my site, then view source on the primary JavaScript file for A List Apart. The first few lines force IE/Win to reiterate the content div, reflowing the page and "fixing" the display bug. You'd want to rename the variable from .content to the name of the div that contains your content.
posted by Zeldman at 12:49 PM on September 6, 2002
Youngpup came up with a simple JavaScript workaround for that CSS rendering bug in IE6. See CSS Layout Revisited on my site, then view source on the primary JavaScript file for A List Apart. The first few lines force IE/Win to reiterate the content div, reflowing the page and "fixing" the display bug. You'd want to rename the variable from .content to the name of the div that contains your content.
posted by Zeldman at 12:49 PM on September 6, 2002
Z,
In the last week or two I've read articles from some of your webstandards partners...who made it perfectly clear that the lack of compliant sites was due to ignorant and lazy designers...not the decision making dicklicks above them.
posted by dangerman at 1:00 PM on September 6, 2002
In the last week or two I've read articles from some of your webstandards partners...who made it perfectly clear that the lack of compliant sites was due to ignorant and lazy designers...not the decision making dicklicks above them.
posted by dangerman at 1:00 PM on September 6, 2002
btw...I'm far too grumpy for a Friday.
Bring me singing and dancing kittens!
posted by dangerman at 1:07 PM on September 6, 2002
Bring me singing and dancing kittens!
posted by dangerman at 1:07 PM on September 6, 2002
like Fezboy!, I am a page monkey (head page monkey, actually) for an academic institution, and for more than a year, I've been working towards more and more standards and accessibility compliance. it's a slow climb uphill, but I find it quite rewarding personally and professionally.
I work in the marketing department, and my boss is not terribly knowledgable about the Web. he'd be the first to admit it, which probably helps, because for most things he asks me what we should do. if I can make a good case for something, then that's what happens. (we've had some interesting conversations about the meaning of links.)
so I have a pretty free hand to make most of our site with standard XHTML and CSS, and I do. afterwards, I tell him that I was able to propagate a new look for the site with 10 minutes of work, instead of 4 hours, and so I can spend more time writing a new events calendar program (for example), and he's happy. even more so when I tell him that our site will meet accessibility standards he's only vaguely aware of...but he knows are good PR. (and would be terrible PR if we had a complaint!)
for my internal clients, I don't tell them a whole lot about "standards", but when they ask for something to be green instead of blue, and it takes me 5 minutes, I know they appreciate it. I sometimes have problems with the (very large) consitutency that uses N4, but I've learned (a) a set of tricks that help and aren't too time-consuming and (b) a gentle spiel about how their browsers is rare and old. :) (they usually get it.)
we're not using a CMS (yet), but where I have created or updated data-driven (db or xml) sites or used php-based templates, I find that going to a simpler XHTML/CSS design only improves things. (and one of the reasons I want to go to a CMS is to get away from having my clean simple designs completely broken by people working in Frontpage.)
I could say more, but I'm taking enough of the lovely blue as it it.
posted by epersonae at 1:10 PM on September 6, 2002
I work in the marketing department, and my boss is not terribly knowledgable about the Web. he'd be the first to admit it, which probably helps, because for most things he asks me what we should do. if I can make a good case for something, then that's what happens. (we've had some interesting conversations about the meaning of links.)
so I have a pretty free hand to make most of our site with standard XHTML and CSS, and I do. afterwards, I tell him that I was able to propagate a new look for the site with 10 minutes of work, instead of 4 hours, and so I can spend more time writing a new events calendar program (for example), and he's happy. even more so when I tell him that our site will meet accessibility standards he's only vaguely aware of...but he knows are good PR. (and would be terrible PR if we had a complaint!)
for my internal clients, I don't tell them a whole lot about "standards", but when they ask for something to be green instead of blue, and it takes me 5 minutes, I know they appreciate it. I sometimes have problems with the (very large) consitutency that uses N4, but I've learned (a) a set of tricks that help and aren't too time-consuming and (b) a gentle spiel about how their browsers is rare and old. :) (they usually get it.)
we're not using a CMS (yet), but where I have created or updated data-driven (db or xml) sites or used php-based templates, I find that going to a simpler XHTML/CSS design only improves things. (and one of the reasons I want to go to a CMS is to get away from having my clean simple designs completely broken by people working in Frontpage.)
I could say more, but I'm taking enough of the lovely blue as it it.
posted by epersonae at 1:10 PM on September 6, 2002
As Succa says, you can produce perfectly valid (in the sense that it validates) XHTML + CSS and still use tables for layout. Did it myself, from Feb 2000 onwards; didn't start experimenting with CSS layout until a year or so later. It's a reasonable halfway house. But JZ's talking about future-proofing, which I suspect is why he gets up people's noses - it's impossible to really know the future, all we can do is guess, and some people don't like his guesses.
It's a false but sexy argument to say that if you do A, B and C today, you have "future-proofed" your site. But it's still false.
Who would've guessed back in 1996 that if you spent millions of dollars building a Web site that was standards-compliant then using font tags, that you'd have to redesign the entire site to keep up with the ever-moving target of "standards" as set by some organization that most ordinary people can't afford to join as a member?
I think it's silly to sit here and act, "Well, if you all move to CSS now, you've "future-proofed" your site!!" BS. All you've done is spent a lot of additional development effort and time trying to comply with the latest standards.
Which will be outdated 5 years from now.
I, like most developers, am not going to waste my time trying to do so because it's fruitless to try and keep up with it. If they set the standard then walked away from it for a few years to let people breath, let the development tools support them (only now are development tools fully supporting the XHTML 1.0 standard), and give people some time to actually adopt them before proposing the next release version, then maybe we'd try to keep up. Otherwise it's like trying to plug a boat hole with a tissue. Most of us don't have the time, bandwidth, energy, money, resources, to recode continually for all of our clients to remain "standards compliant."
Meanwhile, our sites look fine, act fine, and function when properly tested. I can find perfectly acceptable pure-CSS sites that still are broken, just as Zeldman found non-CSS sites that were. I'm not sure pointing to a few examples proves anything.
And he seems to be just plain whacked talking about Yahoo. It always surprises me when a person makes assumptions about a site's motivations when picking up a telephone and talking to their developers directly would easily confirm (or disconfirm) his assumptions. Apparently that would be too much work... it's easier to assume. Doesn't bode well for the rest of the book.
posted by yarf at 1:22 PM on September 6, 2002
It's a false but sexy argument to say that if you do A, B and C today, you have "future-proofed" your site. But it's still false.
Who would've guessed back in 1996 that if you spent millions of dollars building a Web site that was standards-compliant then using font tags, that you'd have to redesign the entire site to keep up with the ever-moving target of "standards" as set by some organization that most ordinary people can't afford to join as a member?
I think it's silly to sit here and act, "Well, if you all move to CSS now, you've "future-proofed" your site!!" BS. All you've done is spent a lot of additional development effort and time trying to comply with the latest standards.
Which will be outdated 5 years from now.
I, like most developers, am not going to waste my time trying to do so because it's fruitless to try and keep up with it. If they set the standard then walked away from it for a few years to let people breath, let the development tools support them (only now are development tools fully supporting the XHTML 1.0 standard), and give people some time to actually adopt them before proposing the next release version, then maybe we'd try to keep up. Otherwise it's like trying to plug a boat hole with a tissue. Most of us don't have the time, bandwidth, energy, money, resources, to recode continually for all of our clients to remain "standards compliant."
Meanwhile, our sites look fine, act fine, and function when properly tested. I can find perfectly acceptable pure-CSS sites that still are broken, just as Zeldman found non-CSS sites that were. I'm not sure pointing to a few examples proves anything.
And he seems to be just plain whacked talking about Yahoo. It always surprises me when a person makes assumptions about a site's motivations when picking up a telephone and talking to their developers directly would easily confirm (or disconfirm) his assumptions. Apparently that would be too much work... it's easier to assume. Doesn't bode well for the rest of the book.
posted by yarf at 1:22 PM on September 6, 2002
Youngpup came up with a simple JavaScript workaround for that CSS rendering bug in IE6.
Sorry for carping on about this. I'm interested to know why a javascript fix would be preferable to the CSS fix I mentioned above. It's not my idea at all (I found it here) but it does have the advantage of seeming to work. Alternatively if it doesn't work, I'd like to be told so that I can go and implement the javascript fix instead.
</offtopic>
posted by walrus at 1:26 PM on September 6, 2002
Sorry for carping on about this. I'm interested to know why a javascript fix would be preferable to the CSS fix I mentioned above. It's not my idea at all (I found it here) but it does have the advantage of seeming to work. Alternatively if it doesn't work, I'd like to be told so that I can go and implement the javascript fix instead.
</offtopic>
posted by walrus at 1:26 PM on September 6, 2002
three comments
1.) you know....sometimes it take balls to tell the boss that he/she is wrong. if they want circa. 1996 frames, tell them they are outdated and antiquated.
2.) the only way the use of Netscape 4 will be discouraged is to stop designing for it. As more people come upon sties that don't appear "normal" and will upgrade browsers or gripe at the IT guys about changing browsers.
3.) Nucleus is a neat little PHP/MySQL-based weblog program that reminds me a lot of PHPNuke...it comes with a css only template and doesn't choke on it's rendering. saying you can't use CSS with a CMS or DB powered site is an old wife's tale. It's done and it works.
posted by mkelley at 1:36 PM on September 6, 2002
1.) you know....sometimes it take balls to tell the boss that he/she is wrong. if they want circa. 1996 frames, tell them they are outdated and antiquated.
2.) the only way the use of Netscape 4 will be discouraged is to stop designing for it. As more people come upon sties that don't appear "normal" and will upgrade browsers or gripe at the IT guys about changing browsers.
3.) Nucleus is a neat little PHP/MySQL-based weblog program that reminds me a lot of PHPNuke...it comes with a css only template and doesn't choke on it's rendering. saying you can't use CSS with a CMS or DB powered site is an old wife's tale. It's done and it works.
posted by mkelley at 1:36 PM on September 6, 2002
Sometimes clients can't be talked out of bad decisions, but at least we can try to make a case based on business value. It helps to present your point obliquely, illustrating, as Mr. Zeldman and others have, the various benefits of doing it clean and then working to minimize problems and mitigate risks (redundant redundancy). Note that this requires planning, dialogue, and agreement--and it's *very different* from blithely announcing "Your browser is too old" on launch day. Surprises make terrible deliverables.
There's only so much you can do for people, though, and if they are stuck on having a dancing sausage on the home page with a WAV of "Baby Got Back" playing in the background, XHTML validation and a clean Bobby report may be the least of your problems.
[BTW, stuttering on the div-ridden concoction called Kung Fu Grippe may be from the large amount of crap I have in the left and right bars. The content well appears first in the actual html with the sidebars thereafter; because the sidebars are being drawn and redrawn on the (sometimes scrolling) page using absolute positioning, that might account for a slowdown. Either that or I'm just doing something wrong. I'm open to either.]
posted by merlinmann at 1:38 PM on September 6, 2002
There's only so much you can do for people, though, and if they are stuck on having a dancing sausage on the home page with a WAV of "Baby Got Back" playing in the background, XHTML validation and a clean Bobby report may be the least of your problems.
[BTW, stuttering on the div-ridden concoction called Kung Fu Grippe may be from the large amount of crap I have in the left and right bars. The content well appears first in the actual html with the sidebars thereafter; because the sidebars are being drawn and redrawn on the (sometimes scrolling) page using absolute positioning, that might account for a slowdown. Either that or I'm just doing something wrong. I'm open to either.]
posted by merlinmann at 1:38 PM on September 6, 2002
"I think it's silly to sit here and act, "Well, if you all move to CSS now, you've "future-proofed" your site!!" BS. All you've done is spent a lot of additional development effort and time trying to comply with the latest standards. "
You haven't future-proofed your site, but you made it easier to change formatting and position in future versions. If you just have to change one css file, then wouldn't that be easier than changing dozens of font tags? I like being able to change the fonts on my entire site just by opening one file and changing one or two lines.
posted by mkelley at 1:40 PM on September 6, 2002
You haven't future-proofed your site, but you made it easier to change formatting and position in future versions. If you just have to change one css file, then wouldn't that be easier than changing dozens of font tags? I like being able to change the fonts on my entire site just by opening one file and changing one or two lines.
posted by mkelley at 1:40 PM on September 6, 2002
1.) you know....sometimes it take balls to tell the boss that he/she is wrong. if they want circa. 1996 frames, tell them they are outdated and antiquated.
You want balls...I told the eBiz VP of a global brand he was a "fucking idiot"...and I'm still employed.
Giant gonads has nothing to do with corporate politics... by the time stuff like this trickles down...to many people have signed off on it. For upper management to back track would mean admitting that they were in error...and we all know that just aint going to happen.
posted by dangerman at 1:55 PM on September 6, 2002
You want balls...I told the eBiz VP of a global brand he was a "fucking idiot"...and I'm still employed.
Giant gonads has nothing to do with corporate politics... by the time stuff like this trickles down...to many people have signed off on it. For upper management to back track would mean admitting that they were in error...and we all know that just aint going to happen.
posted by dangerman at 1:55 PM on September 6, 2002
Sorry for carping on about this. I'm interested to know why a javascript fix would be preferable to the CSS fix I mentioned above.
I don't know for sure, but I seem to remember some weird things with heights of 100%...because of the question of whether it's 100% of the page or 100% of the viewport.
posted by epersonae at 1:59 PM on September 6, 2002
I don't know for sure, but I seem to remember some weird things with heights of 100%...because of the question of whether it's 100% of the page or 100% of the viewport.
posted by epersonae at 1:59 PM on September 6, 2002
CSS might seem like a good way of doing things for people who think too much about process. However, I'd like to point out a couple of things:
1. CSS is almost always overlooked in webdesign training, at least from my experiences here in Portugal (I mean, most webdesign courses teach FrontPage, for sake!), and I don't have any reason to believe that things are eny different in the US. However, people who are taught Dreamweaver MX might be trained otherwise.
2. My Modus Operandi consists of taking a look at all the options: I am still a TABLE fan, but I reckon CSS has killer typographical controls. And what's the grudge against frames? Weblogs and text-based pages might be better without frames (but then again, there are good weblogs that use frames), but typical frames and IFRAMEs have been quite handy when building graphics-based websites .
3. Future-proofing: CSS2, XHTML, etc might seem cutting edge, but what will happen when almost everyone has a DSL connection? I believe that in the future most text-based sites such as Metafilter or Slashdot will exist as APIs accessed by Flash-like interfaces. Search engines will index the database rather than a site's viewable content.
posted by edsousa at 1:59 PM on September 6, 2002
1. CSS is almost always overlooked in webdesign training, at least from my experiences here in Portugal (I mean, most webdesign courses teach FrontPage, for sake!), and I don't have any reason to believe that things are eny different in the US. However, people who are taught Dreamweaver MX might be trained otherwise.
2. My Modus Operandi consists of taking a look at all the options: I am still a TABLE fan, but I reckon CSS has killer typographical controls. And what's the grudge against frames? Weblogs and text-based pages might be better without frames (but then again, there are good weblogs that use frames), but typical frames and IFRAMEs have been quite handy when building graphics-based websites .
3. Future-proofing: CSS2, XHTML, etc might seem cutting edge, but what will happen when almost everyone has a DSL connection? I believe that in the future most text-based sites such as Metafilter or Slashdot will exist as APIs accessed by Flash-like interfaces. Search engines will index the database rather than a site's viewable content.
posted by edsousa at 1:59 PM on September 6, 2002
It's kinda funny, all this talk about web design....I've been at work all day and haven't written a single line of code...hehe....I love fridays.
posted by poopy at 2:13 PM on September 6, 2002
posted by poopy at 2:13 PM on September 6, 2002
Man, I love this thread. It gives me such a warm feeling of belonging that I can actually follow the discussion. And I care! I really care about layout and CSS and XHTML and all that stuff. Seriously.
Isn't it great to be a web developer?
posted by norm29 at 2:18 PM on September 6, 2002
Isn't it great to be a web developer?
posted by norm29 at 2:18 PM on September 6, 2002
yarf - you're right about 'future-proofing' - sorry I used the term (even if it was just to echo fuzz's use of it). But mkelley hits the nail on the head: the 'future-proofing', such as it is, is in making the site a lot easier to tweak or overhaul than if you'd used lots of tables and font tags and so on. So you're protecting yourself (or your successor) from the understandable inertia that comes from facing a pile of table-ridden pages and thinking 'I can't face tweaking all of that, I'll just leave it/start over from scratch/run screaming out the door'.
'Course, tweaking a table-based template for a database back-end isn't such a big deal, which is why those who build db-driven sites might just shrug their shoulders about CSS. But anyone who has grepped their way through a few hundred static pages of circa-1997 HTML to clean up a few basic stylistic differences won't.
posted by rory at 2:45 PM on September 6, 2002
'Course, tweaking a table-based template for a database back-end isn't such a big deal, which is why those who build db-driven sites might just shrug their shoulders about CSS. But anyone who has grepped their way through a few hundred static pages of circa-1997 HTML to clean up a few basic stylistic differences won't.
posted by rory at 2:45 PM on September 6, 2002
"That CSS XHTML-strict demo page of Amazon.com that mathowie pointed to (here) looks great, yes - in a newer browser. Have you seen what it looks like in NN4? (screenshot)."
I propose a solution. Tell any complaining NN4 user "I'm so sorry about your problem." NN4 is too stupid to live but will stagger around like the undead so long as people coddle it with table layouts and shim.gif and continue to make brochureware sites where Business Requirement 2.B. is pixel perfect equivalency from NN4 through the modern era.
Let it show its suckage, and natural attrition will take its course.
Launching off on an only vaguely related tangent:
If you have a page with a zooming blinking flaming eyesore Times Square UI like Amazon, you are (a) abusing the definition of "page", you're simply emulating a hypothetical GUI with the modern age's equivalent of mainframe terminal screens; and (b) likely to be doing heinous bass-ackwards things regardless of if you use old-fashioned HTML or DTD-strict XHTML/CSS.
Amazon is the Microsoft Word of the web -- functional at a superficial level but interntionally cluttered and obfuscatory -- and probably a poor example to cry "won't somebody think about the NN4 children!" with.
Both strict and compatible approaches allow for idiocy on the part of designers and front end code monkeys, but at least CSS is generally easier to work with if the stylesheets are sensibly built and print-material marketing weenies aren't demanding pixel-level control over layout across every conceivable user agent.
The problem isn't so much which particular technology is being used, as they all suffer deterioration over time, it is in how those technologies are being applied, and to what purpose.
See? I'm not bitter.
posted by majick at 4:13 PM on September 6, 2002
I propose a solution. Tell any complaining NN4 user "I'm so sorry about your problem." NN4 is too stupid to live but will stagger around like the undead so long as people coddle it with table layouts and shim.gif and continue to make brochureware sites where Business Requirement 2.B. is pixel perfect equivalency from NN4 through the modern era.
Let it show its suckage, and natural attrition will take its course.
Launching off on an only vaguely related tangent:
If you have a page with a zooming blinking flaming eyesore Times Square UI like Amazon, you are (a) abusing the definition of "page", you're simply emulating a hypothetical GUI with the modern age's equivalent of mainframe terminal screens; and (b) likely to be doing heinous bass-ackwards things regardless of if you use old-fashioned HTML or DTD-strict XHTML/CSS.
Amazon is the Microsoft Word of the web -- functional at a superficial level but interntionally cluttered and obfuscatory -- and probably a poor example to cry "won't somebody think about the NN4 children!" with.
Both strict and compatible approaches allow for idiocy on the part of designers and front end code monkeys, but at least CSS is generally easier to work with if the stylesheets are sensibly built and print-material marketing weenies aren't demanding pixel-level control over layout across every conceivable user agent.
The problem isn't so much which particular technology is being used, as they all suffer deterioration over time, it is in how those technologies are being applied, and to what purpose.
See? I'm not bitter.
posted by majick at 4:13 PM on September 6, 2002
...so long as people coddle it with table layouts and shim.gif
See, we don't call it that. We use 'dot' or 'dotty'. I prefer 'Dotty' myself; shim and dot are so impersonal.
posted by poopy at 4:42 PM on September 6, 2002
See, we don't call it that. We use 'dot' or 'dotty'. I prefer 'Dotty' myself; shim and dot are so impersonal.
posted by poopy at 4:42 PM on September 6, 2002
Sorry about the bitterness majick. Your proposal may be a fair one, asking the end user to upgrade, especially for a personal site - but for an ecommerce site it really is plainly unreasonable. You're basically telling a customer - "oh, you could shop here yesterday, but today you can't - we don't want your money unless you jump through these hoops." You'll be hard pressed to convice a business owner to turn away substantial sums of money purely on the principle of "Standardization". - And, as long as the DOM is accessible via script, what's so wrong with treating a page like both a GUI and a document?
posted by kokogiak at 4:58 PM on September 6, 2002
posted by kokogiak at 4:58 PM on September 6, 2002
When Netscape 4.0 was new, did e-commerce sites work in Netscape 1.0?
Now consider that a properly made standards-compliant (by both the letter and the spirit of the recommendations) site would work perfectly in Netscape 4, except for a somewhat different layout. Why is that so horrible? You aren't locking out anybody, just giving them a layout suitable for the capabilites of their browser.
Its better than what you did to the Netscape 1.0 users when Netscape 4.0 was new.
(and sorry for going off on you dayvin. I really don't know why I was being such a jackass.)
posted by Ptrin at 5:31 PM on September 6, 2002
Now consider that a properly made standards-compliant (by both the letter and the spirit of the recommendations) site would work perfectly in Netscape 4, except for a somewhat different layout. Why is that so horrible? You aren't locking out anybody, just giving them a layout suitable for the capabilites of their browser.
Its better than what you did to the Netscape 1.0 users when Netscape 4.0 was new.
(and sorry for going off on you dayvin. I really don't know why I was being such a jackass.)
posted by Ptrin at 5:31 PM on September 6, 2002
Now consider that a properly made standards-compliant... site would work perfectly in Netscape 4"
Negatory. Implementation bugs in the NN4 rendering engine are legion, and it is trivially easy to craft pages that validate yet crash the browser or fail to render whatsoever. Even reasonable CSS1 can cause spectacular rendering failures.
Netscape 4 is a broken user agent. That it remains common enough to still be a thorn in our sides is an artifact of our collective willingness to tolerate and work around the buggy implementation. We need to rid ourselves of it. It should start with a splash page of 40-foot high flaming letters that say "this software is a decrepit piece of shit."
It was nifty back in the day (although I stuck with NN3 for quite a while since UI quirks in NN4 bothered me from the get-go) while standards were in flux and the web was wild and wooly.
"...but for an ecommerce site it really is plainly unreasonable."
Tell that to the absolutely enormous number of sites that fail to work using any user agent other than IE, particularly banking sites although lots of sales sites are guilty. (One in particular irks me regularly)
Decisions to exclude significant user agent populations -- including those that have acceptable standards compliance -- are being made today, and on far thinner premise than the simple one that the cost and frustration of supporting buggy implementation is too great.
NN4 compatibility is not "backwards" compatibility. It's bugwards compatibility.
That said, I still use simple table-based layouts from time to time, if for no other reason than that they work well in w3m. I, at least, am not in the least opposed to backwards compatibility. My own personal site degrades quite nicely from CSS-based layout that looks pleasant enough in a proper browser to a quite readable if very bare-bones circa Mosaic-era text page in NN4 or Lynx. I haven't tested, but I imagine Netscape 0.93 beta would render it acceptably.
If I were selling something, I would consider my solution reasonable: it's backwards compatible but in no way bugwards compatible. It can be used by bizarre, obscure, or ancient user agents. Yet that backwards compatibility was at no cost. I simply wrote simple and decent code, ensured that the layout meant little other than some visual improvements, avoided designer-y crap like menus and bitmap text and "DHTML" and client scripting, and paid no attention whatsoever to how NN4 or any UA but my own rendered. I made no effort to take advantage of features that required any particular effort to support on NN4. As a result it renders as simple, readable but hardly gorgeous HTML text on the thing.
Compatibility came free with the price of adherence to KISS.
My personal site is vastly more usable in e.g. speaking browsers as well as ancient ones than the site I maintain professionally under those bitter conditions. Yet NN4 could fall off the face of the planet forever and I would only be happy for the poor end users who rid themselves of it.
Good thing I'm still not bitter, huh?
posted by majick at 7:39 PM on September 6, 2002
Negatory. Implementation bugs in the NN4 rendering engine are legion, and it is trivially easy to craft pages that validate yet crash the browser or fail to render whatsoever. Even reasonable CSS1 can cause spectacular rendering failures.
Netscape 4 is a broken user agent. That it remains common enough to still be a thorn in our sides is an artifact of our collective willingness to tolerate and work around the buggy implementation. We need to rid ourselves of it. It should start with a splash page of 40-foot high flaming letters that say "this software is a decrepit piece of shit."
It was nifty back in the day (although I stuck with NN3 for quite a while since UI quirks in NN4 bothered me from the get-go) while standards were in flux and the web was wild and wooly.
"...but for an ecommerce site it really is plainly unreasonable."
Tell that to the absolutely enormous number of sites that fail to work using any user agent other than IE, particularly banking sites although lots of sales sites are guilty. (One in particular irks me regularly)
Decisions to exclude significant user agent populations -- including those that have acceptable standards compliance -- are being made today, and on far thinner premise than the simple one that the cost and frustration of supporting buggy implementation is too great.
NN4 compatibility is not "backwards" compatibility. It's bugwards compatibility.
That said, I still use simple table-based layouts from time to time, if for no other reason than that they work well in w3m. I, at least, am not in the least opposed to backwards compatibility. My own personal site degrades quite nicely from CSS-based layout that looks pleasant enough in a proper browser to a quite readable if very bare-bones circa Mosaic-era text page in NN4 or Lynx. I haven't tested, but I imagine Netscape 0.93 beta would render it acceptably.
If I were selling something, I would consider my solution reasonable: it's backwards compatible but in no way bugwards compatible. It can be used by bizarre, obscure, or ancient user agents. Yet that backwards compatibility was at no cost. I simply wrote simple and decent code, ensured that the layout meant little other than some visual improvements, avoided designer-y crap like menus and bitmap text and "DHTML" and client scripting, and paid no attention whatsoever to how NN4 or any UA but my own rendered. I made no effort to take advantage of features that required any particular effort to support on NN4. As a result it renders as simple, readable but hardly gorgeous HTML text on the thing.
Compatibility came free with the price of adherence to KISS.
My personal site is vastly more usable in e.g. speaking browsers as well as ancient ones than the site I maintain professionally under those bitter conditions. Yet NN4 could fall off the face of the planet forever and I would only be happy for the poor end users who rid themselves of it.
Good thing I'm still not bitter, huh?
posted by majick at 7:39 PM on September 6, 2002
I should add that despite the fact that my personal site works just fine in NN4, I could care less if it did, so long as w3m worked OK. The compatibility is purely coincidental, that NN4 doesn't choke and die attempting to do anything with my CSS. It just as easily could have turned out to crash the browser and I would have merely said <nelson>ha, ha!</nelson>
posted by majick at 7:44 PM on September 6, 2002
posted by majick at 7:44 PM on September 6, 2002
Writing DTD-strict code (HTML 3.2 all the way up to XHTML) is future-proofing. Future versions of browser agents should know how to render out HTML 3.2 according to the Doctype. There's no reason that I can think of that the browser makers will ever "turn off" that ability. Just because XHTML 9.7 comes out in 2025 doesn't mean that IE 8 won't know how to render HTML 3.2.
What would be the purpose, for them to throw out rendering programming that knows these previous versions of the standard?
After they standardized the railroad track sizes, did someone come along 30 years later and launch a new size? No. They might've come up with new and better materials, but the basics, once agreed upon, stayed stable.
posted by Phatbank at 12:30 PM on September 7, 2002
What would be the purpose, for them to throw out rendering programming that knows these previous versions of the standard?
After they standardized the railroad track sizes, did someone come along 30 years later and launch a new size? No. They might've come up with new and better materials, but the basics, once agreed upon, stayed stable.
posted by Phatbank at 12:30 PM on September 7, 2002
Late to the party as always, and dangerman drank all the beer. ah well...
"Someone even got Amazon.com into XHTML 1.1 strict, and it also meets section 508 and Bobby specs, and not a single table was used."
That would be me.
"Just a chime-in from an Amazon.com webdev. That CSS XHTML-strict demo page of Amazon.com that mathowie pointed to (here) looks great, yes - in a newer browser. Have you seen what it looks like in NN4?"
kokogiak, it wasn't meant to be NN4 compatible. It was a one-off that someone else started and on a whim I redid just to see how far I could take it. The original didn't validate and I was lazy and didn't completely clean up the code he used. I just made it validate and added a few quick and dirty changes for 508 compliance. I can work up a nice NN4 compatible version if you like (in fact I will anyway).
Q: Why do most 100% standards-compliant webpages look like the 'less is more' idealized by Mies Van Der Rohe? A: Something else entirely based on CSS is a nightmare.
I disagree. I'd say it's because it's still unfamiliar territory and they don't understand the full potential yet. And it only becomes a nightmare when you want the CSS you write to work in browsers that don't support CSS.
"As soon as you can abandon the illusion of uniformity of appearance ..."
That's the crux of it right there. But it's also of major importance to management, the client, et al. So better to approach each project on a case by case basis, no?
Designers themselves though still have trouble getting past the feeling that they should always size an H2 tag larger than an H3. I say it depends on what you're doing. Do the markup, then if the presentation calls for it, change the size, not the tag. I see it all the time where designers use a tag because of the way it'll render and not because of its structural value. They can't seperate the structure from the visual presentation in their head.
Also, in IE, dotted-line borders around page elements don't render very well while the page is being scrolled.
It's a bug I documented and found a workaround for here.
"...there's been a rash of poorly-designed but standards-compliant sites,..."
Of which too many people set about using templates provided by others, with little understanding of how and why they worked and how to keep the sites compliant.
"...try scrolling up and down Kung Fu Grippe, an XHTML/CSS concoction, versus scrolling up and down this page. There's a noticable stutter with KFG.'
Perhaps if the code were valid, it might not have to jump through rendering hoops and it might just work better.
"Why won't you try building a fully functioning and pleasing PHP-Nuke theme without using a single TABLE (Oh, and don't you forget to change Nuke's table generation routines as well)?"
You're on.
posted by mikhail at 12:31 PM on September 7, 2002
"Someone even got Amazon.com into XHTML 1.1 strict, and it also meets section 508 and Bobby specs, and not a single table was used."
That would be me.
"Just a chime-in from an Amazon.com webdev. That CSS XHTML-strict demo page of Amazon.com that mathowie pointed to (here) looks great, yes - in a newer browser. Have you seen what it looks like in NN4?"
kokogiak, it wasn't meant to be NN4 compatible. It was a one-off that someone else started and on a whim I redid just to see how far I could take it. The original didn't validate and I was lazy and didn't completely clean up the code he used. I just made it validate and added a few quick and dirty changes for 508 compliance. I can work up a nice NN4 compatible version if you like (in fact I will anyway).
Q: Why do most 100% standards-compliant webpages look like the 'less is more' idealized by Mies Van Der Rohe? A: Something else entirely based on CSS is a nightmare.
I disagree. I'd say it's because it's still unfamiliar territory and they don't understand the full potential yet. And it only becomes a nightmare when you want the CSS you write to work in browsers that don't support CSS.
"As soon as you can abandon the illusion of uniformity of appearance ..."
That's the crux of it right there. But it's also of major importance to management, the client, et al. So better to approach each project on a case by case basis, no?
Designers themselves though still have trouble getting past the feeling that they should always size an H2 tag larger than an H3. I say it depends on what you're doing. Do the markup, then if the presentation calls for it, change the size, not the tag. I see it all the time where designers use a tag because of the way it'll render and not because of its structural value. They can't seperate the structure from the visual presentation in their head.
Also, in IE, dotted-line borders around page elements don't render very well while the page is being scrolled.
It's a bug I documented and found a workaround for here.
"...there's been a rash of poorly-designed but standards-compliant sites,..."
Of which too many people set about using templates provided by others, with little understanding of how and why they worked and how to keep the sites compliant.
"...try scrolling up and down Kung Fu Grippe, an XHTML/CSS concoction, versus scrolling up and down this page. There's a noticable stutter with KFG.'
Perhaps if the code were valid, it might not have to jump through rendering hoops and it might just work better.
"Why won't you try building a fully functioning and pleasing PHP-Nuke theme without using a single TABLE (Oh, and don't you forget to change Nuke's table generation routines as well)?"
You're on.
posted by mikhail at 12:31 PM on September 7, 2002
mikhail - I understand what you're saying about the Amazon mockup being a one-off, I was just pointing out the NN4 ugliness to make a point - the same way you made a point about it being easy to replicate a large site's HTML in compliant CSS/XHTML (nice job too, btw).
When/If you do make a nice mock of that page that degrades beautifully - or at least legibly ;) - in NN4, please post a link here, I'm sure others would like to see it too.
posted by kokogiak at 1:40 PM on September 7, 2002
When/If you do make a nice mock of that page that degrades beautifully - or at least legibly ;) - in NN4, please post a link here, I'm sure others would like to see it too.
posted by kokogiak at 1:40 PM on September 7, 2002
majick:
I tend to use imports, so I really don't have to worry for a second what Netscape 4 thinks of my CSS. As long as it is compliant for Moz and IE/Win only bungles it moderately, I'm set.
posted by Ptrin at 2:14 PM on September 7, 2002
I tend to use imports, so I really don't have to worry for a second what Netscape 4 thinks of my CSS. As long as it is compliant for Moz and IE/Win only bungles it moderately, I'm set.
posted by Ptrin at 2:14 PM on September 7, 2002
Succa said: ... I still find that CSS-only sites have a "feel" to them. I can almost always tell a CSS site from a TABLE site without looking at the source, just by how slow the rendering engine is while I browse around. Am I alone here?
I've noticed that, but I always thought that it was a function of how many javascript doodads were embedded in the page. I've used table-less layouts for nearly a year, and while some did seem to make the page stutter a bit on scrolling (on my old p2 400), some did not. Not very scientific, perhaps, but I'm not sure either of us have pinpointed the problem.
posted by stavrosthewonderchicken at 7:12 PM on September 7, 2002
I've noticed that, but I always thought that it was a function of how many javascript doodads were embedded in the page. I've used table-less layouts for nearly a year, and while some did seem to make the page stutter a bit on scrolling (on my old p2 400), some did not. Not very scientific, perhaps, but I'm not sure either of us have pinpointed the problem.
posted by stavrosthewonderchicken at 7:12 PM on September 7, 2002
One challenge is that there doesn't seem to be enough good information on how to handle common CSS issues. It can seem like the reference sites have tons of detailed information, which is difficult to dig through, while the tutorials are too general. It's hard to find an easy answer to the basic question: "What should I do to make sure my CSS site is compatible with older browsers?". The result: many people run away yelling and screaming when CSS is suggested.
posted by hlari at 9:47 PM on September 7, 2002
posted by hlari at 9:47 PM on September 7, 2002
i can't believe i missed this one... god damn it
posted by folktrash at 11:50 PM on September 7, 2002
posted by folktrash at 11:50 PM on September 7, 2002
What "many thousand-dollar budgets"?
On a recent interview with a software developer for EDI transactions, I quote his research on what companies worldwide break down to be:
"We also found that 99% of the registered companies in the industrialized world have less than 100 employees; more than 85% of them having less than 20 employees!"
It is evident that *big* web projects makes for a very small faction of clients. In view of this, the budget (time, resource, etc.) requires a high portion of client education and often times, is the very hindrance in implementing consistent standards and guidelines. I think, mostly, the *time* allocation will be absorbed by the dev team - not the client. Perhaps, this is indicative of the slow implementation.
posted by cgware at 5:46 AM on September 8, 2002
On a recent interview with a software developer for EDI transactions, I quote his research on what companies worldwide break down to be:
"We also found that 99% of the registered companies in the industrialized world have less than 100 employees; more than 85% of them having less than 20 employees!"
It is evident that *big* web projects makes for a very small faction of clients. In view of this, the budget (time, resource, etc.) requires a high portion of client education and often times, is the very hindrance in implementing consistent standards and guidelines. I think, mostly, the *time* allocation will be absorbed by the dev team - not the client. Perhaps, this is indicative of the slow implementation.
posted by cgware at 5:46 AM on September 8, 2002
for dealing with N4 issues, I'm rather fond of this CSS and Netscape 4.xx Issues site.
posted by epersonae at 8:40 AM on September 9, 2002
posted by epersonae at 8:40 AM on September 9, 2002
Could someone explain the following: if JZ is pushing for CSS + XHTML to replace table layouts, why does Zeldman.com's source code use tables? Does that mean HIS site is obsolete? and, as a result, does that mean that the 99.9% include the site he owns, and the site on which the article is posted?
posted by TNLNYC at 9:02 AM on September 9, 2002
posted by TNLNYC at 9:02 AM on September 9, 2002
Could someone explain the following: if JZ is pushing for CSS + XHTML to replace table layouts, why does Zeldman.com's source code use tables?
He talks about this in his FAQ.
Does that mean HIS site is obsolete? and, as a result, does that mean that the 99.9% include the site he owns, and the site on which the article is posted?
Yes, I think it does.
posted by timeistight at 11:58 AM on September 9, 2002
He talks about this in his FAQ.
Does that mean HIS site is obsolete? and, as a result, does that mean that the 99.9% include the site he owns, and the site on which the article is posted?
Yes, I think it does.
posted by timeistight at 11:58 AM on September 9, 2002
Zeldman, Nielsen. Jakob, Nielsen.
Frames are still a good choice for some sites. Thumbnail sites suit it too.
In older browsers CSS-P can cause poor usability and accessibility. For the NZ E-government homepage a CSS layout mockup was 5 times as long as a tables layout. In this case, CSS-P caused poor readability.
Tables can be as easy to maintain as CSS-P if your site uses includes. Due to browser bugs tables are certainly a more predictable method of layout. Again, just common sense, but when people don't list the exceptions it's not understanding. It's largely taken as fact.
The responses to viewing a CSS layout, with CSS, using an older browser have been learnt: It looks less pretty. It's understated, and it doesn't mention the accessibility or usability. It casts those who want a usable and accessible page in an older browser as a superficial. It worked.
Sound bite laws aren't understanding. They're not even close.
There's always an exception to the rule. Understanding is about that.
posted by holloway at 3:59 PM on September 10, 2002
Frames are still a good choice for some sites. Thumbnail sites suit it too.
In older browsers CSS-P can cause poor usability and accessibility. For the NZ E-government homepage a CSS layout mockup was 5 times as long as a tables layout. In this case, CSS-P caused poor readability.
Tables can be as easy to maintain as CSS-P if your site uses includes. Due to browser bugs tables are certainly a more predictable method of layout. Again, just common sense, but when people don't list the exceptions it's not understanding. It's largely taken as fact.
The responses to viewing a CSS layout, with CSS, using an older browser have been learnt: It looks less pretty. It's understated, and it doesn't mention the accessibility or usability. It casts those who want a usable and accessible page in an older browser as a superficial. It worked.
Sound bite laws aren't understanding. They're not even close.
There's always an exception to the rule. Understanding is about that.
posted by holloway at 3:59 PM on September 10, 2002
Frames are still a good choice for some sites. Thumbnail sites suit it too.
I think you mean tables, no?
In older browsers CSS-P can cause poor usability and accessibility.
Only because the older browsers can't handle it. CSS-P doesn't cause it, the browsers do.
For the NZ E-government homepage a CSS layout mockup was 5 times as long as a tables layout.
I'd like to see the mockup, because unless it was designed poorly, I find that hard to believe.
Tables can be as easy to maintain as CSS-P if your site uses includes.
Again I disagree. How easily can you change from a two column table layout to a three, or vice versa even if you're using includes, and do it sitewide? All a CSS designed site might need to change is the CSS file.
Due to browser bugs tables are certainly a more predictable method of layout.
I'll agree that there are fewer browser variances with tables, but 'certainly more predictable'? I'd say it's relative to what you are doing.
Common sense should tell you to use the right tool for the job. If a table is what's going to work, then use a table. If CSS can do something in one line of code that would otherwise be hardcoded to countless HTML elements on the page, then use CSS. Know your client, know your clients audience, and make an informed decision. As the designer/developer, your job is to have the expertise and experience to be able to make the right decisions for the client (unless of course they're browbeating you with their own ideas on how to create flash intros or something).
posted by mikhail at 2:55 PM on September 12, 2002
I think you mean tables, no?
In older browsers CSS-P can cause poor usability and accessibility.
Only because the older browsers can't handle it. CSS-P doesn't cause it, the browsers do.
For the NZ E-government homepage a CSS layout mockup was 5 times as long as a tables layout.
I'd like to see the mockup, because unless it was designed poorly, I find that hard to believe.
Tables can be as easy to maintain as CSS-P if your site uses includes.
Again I disagree. How easily can you change from a two column table layout to a three, or vice versa even if you're using includes, and do it sitewide? All a CSS designed site might need to change is the CSS file.
Due to browser bugs tables are certainly a more predictable method of layout.
I'll agree that there are fewer browser variances with tables, but 'certainly more predictable'? I'd say it's relative to what you are doing.
Common sense should tell you to use the right tool for the job. If a table is what's going to work, then use a table. If CSS can do something in one line of code that would otherwise be hardcoded to countless HTML elements on the page, then use CSS. Know your client, know your clients audience, and make an informed decision. As the designer/developer, your job is to have the expertise and experience to be able to make the right decisions for the client (unless of course they're browbeating you with their own ideas on how to create flash intros or something).
posted by mikhail at 2:55 PM on September 12, 2002
I think you mean tables, no?No... definately frames. Yep, link is clearly to an excellent use of frames on Google Groups :)
Only because the older browsers can't handle it. CSS-P doesn't cause it, the browsers do.The users experience the same degrade of usability and accessibility regardless of who's at fault. It's not an overwhelming concern for me, but it's something to consider.
I'll agree that there are fewer browser variances with tables, but 'certainly more predictable'? I'd say it's relative to what you are doing.fewer browser variances = more predictable = ... = profit!
I'd like to see the mockup, because unless it was designed poorly, I find that hard to believe.I don't have it on me right now but I'll post a link in a few days. As you can see from the homepage it's a multi-column layout with lots of options. I'd say it's pretty generic homepage, and a perfect case of what happens when a CSS-P layout falls to bits in an older non CSS-P browser.
All a CSS designed site might need to change is the CSS file.Er, baring the largely unsupported methods how on earth can you change from 2 to 3 columns using CSS? Do you have an example?
If the content is already separated into 3 distinct groups it's as easy to fill a table cell as it is to fill a DIV.
posted by holloway at 8:29 PM on September 12, 2002
here << was just an early mockup, probably has errors, but you get the idea. Imagine how something that really needs those multi-column layouts would pancake.
posted by holloway at 6:56 PM on September 13, 2002
posted by holloway at 6:56 PM on September 13, 2002
Bah.
You did forget to say that CSS could fly to the moon and back, though.
posted by holloway at 2:37 PM on September 16, 2002
You did forget to say that CSS could fly to the moon and back, though.
posted by holloway at 2:37 PM on September 16, 2002
« Older Netflix | Journey to Planet Prostate Newer »
This thread has been archived and is closed to new comments
posted by toothgnip at 6:58 AM on September 6, 2002