Slashdot Mirror
Designing With Web Standards
Jeffrey Zeldman is one of the best technical writers whose work I've had the pleasure of reading. He is obviously well-educated with regard to the subject, and his passion for the work really shows through. Still, he never comes across as a zealot -- his style is even-handed, thoughtful, and easy to comprehend.
The first part of the book ("Houston, We Have a Problem") is the reason I give a rating of "9" rather than "10." Zeldman spends a perfect length of time on background and history of Web standards (why they're here, and what designers did before they emerged). However, this section seems to suffer from what many technical books suffer from: a case of "We'll see this soon"-itis. While this is perhaps unavoidable in such a treatise, it is nonetheless apparent. Still, it's only marginally distracting.
The meat of the book comes with "Designing and Building." Zeldman first talks about modern markup, then explains the variations on XHTML (i.e. Strict, Transitional, Frameset) and how each ought apply to your design. Here we see more theory than practice, though, but this is welcome -- it lays the foundation for a more cerebral look at distinguishing markup from design. Once Zeldman explains the nuances of that topic, we moveon to the redesign of a Web page constructed with a hybrid table/CSS design complete with all the excellent effects we hope to see in modern pages.
After working through this redesign, Zeldman talks in more detail about the CSS box model (and the browsers that break it), typography, and some of the quirks that Web designers must deal with. Next he touches a bit on Web accessibility--a must-read for everyone, whether you think so or not.
While Zeldman isn't incredibly thorough here, he doesn't need to be--it's a book on Web standards, after all, and this chapter serves to show how accessibility can still be achieved within those standards. He also suggests a couple of other books for more information.
Finally, Zeldman walks the reader through a redesign of zeldman.com, basically as a hands-on summary of the book, and as a guide for future projects. Also included is a "Back End" (i.e., appendix) showing some excellent information about each major browser.
Too often, a book or Web site on XHTML/CSS will dwell only on the "how"--this book shows the "how" and still explains the "why": Here's how you set up an id'ed element; here's why we do that, rather than using a class. It's already opened my eyes to many things I thought I had a handle on, but now realize that I only knew in a cursory fashion.
So, ask yourself: Do you want to design a Web site that will work for everyone, regardless of their platform? Do you want to make sure your Web site is future-proof? If so, you need this book.
You can purchase Designing With Web Standards from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
You code. And code. And code. You build only to rebuild. You focus on making your site compatible with almost every browser or wireless device ever put out there. Then along comes a new device or a new browser, and you start all over again.
You can get off the merry-go-round.
It's time to stop living in the past and get away from the days of spaghetti code, insanely nested table layouts, tags, and other redundancies that double and triple the bandwidth of even the simplest sites. Instead, it's time for forward compatibility.
Isn't it high time you started designing with web standards?
Standards aren't about leaving users behind or adhering to inflexible rules. Standards are about building sophisticated, beautiful sites that will work as well tomorrow as they do today. You can't afford to design tomorrow's sites with yesterday's piecemeal methods.
Jeffrey teaches you to:
* Slash design, development, and quality assurance costs (or do great work in spite of constrained budgets)
* Deliver superb design and sophisticated functionality without worrying about browser incompatibilities
* Set up your site to work as well five years from now as it does today
* Redesign in hours instead of days or weeks
* Welcome new visitors and make your content more visible to search engines
* Stay on the right side of accessibility laws and guidelines
* Support wireless and PDA users without the hassle and expense of multiple versions
* Improve user experience with faster load times and fewer compatibility headaches
* Separate presentation from structure and behavior, facilitating advanced publishing workflows
I have over 70 freaks, do you?
He also has an excellent list of related resources and links on design and accessibility:
http://zeldman.com/externals/
Eric Meyer on CSS. I finished Zeldman's book about a week ago and am now going through Eric Meyer on CSS. Zeldman tells you what needs to be done, and gives some examples, Eric Meyer gives you a bunch of practical examples. Guess this is why can be purchased as a pair at Amazon...
I agree that he is an excellent tech writer. However, I thought his first book was much better than this one.
A Review Can Be Found Here
Although I am not very good at web design... what I have learned, I learned from this guy. He rocks.
Davak
The only standards you need to follow are the W3C Web Standards They even have a validator for your convience if you need to make sure that your code is valid. I did that at my summer internship and over the course of a summer was able to make our 1000+ page website 99% w3c complient. It might take you a few days to get in the rythym of doing things, but once we had our site up to html 4.01 standards, we never had a problem with any browser compatability issues, and we tested all the way back to Netscape 4.7.
I happened across this site the other day... it really shows off what CSS can do. No idea how it looks in IE, but in Firebird it's pretty amazing. Pick a design from the left and note that it's all style sheets...
http://www.csszengarden.com/
Bookpool is always cheaper!
Flash isnt a web standard (it has quite a large user base though). The W3C standards answer to flash is SVG which is pretty similar except it ties in with HTML/XML/CSS etc much better, flash is just a hole in the browser where a plug-in is put, while SVG (can also be a plugin) is much more integrated. SVG is also a 'text' based standard like HTML - ie its made up of tags and stuff so its in theory much easier to write generating software for it and link it with server-side scripts and even with client side java/vbs etc scripts (why re-invent the wheel with flash scripting and proprietory expensive server-side software when you can use existing layers like perl,PHP,java,asp, basically anything?). While flash is a more closed system designed by Macromedia to fill a gap in a business like manner, SVG is structually better - kindof like the way HTML tables were/are used to design sites, they are a work around where-as CSS (if the browser supports it properly) is a far better more structured way to do the job.
Flash probably runs faster and has more support, plug-ins and editors on most computers at the moment but SVG is catching up (also SVG supports compression which is cool so it can match flash in file-size).
So basically the book would talk about SVG if it talked about any vector/animation system.
(And without trying to sound like a troll:
Flash = Cheap Hack, SVG = Potentially Structured Nirvana)
This comment does not represent the views or opinions of the user.
It depends on what you need. CMS is a very, very broad term, and most people are looking for a WCMS (Web Content Management System) when they say it, even though their true needs may be different.
I would recommend getting the Content Management Bible, which you can learn more about here. It covers the various systems out there. One company I worked for realised they needed a Digital Asset Management system, like Artesia, and not something like Interwoven.
Good luck! And remember that O'Reilly isn't the only reasonable tech publisher out there.
Linux - because it doesn't leave that Steve Ballmer aftertaste.
Our faculty of the university at which I work has decided on a new layout for their web pages. This was done and delivered to us by a PR agency. I feared that it might be bad, but that fear didn't even come close to what I had to witness.
Imagine having to tell our users (many of which are using GNU/Linux or Macintosh) that our web site only works reliably in Windows with Internet Explorer 6.0 and above. Just because a PR agency can't develop web pages. It's impossible. I had to do something about it.
So when I implemented the layout for our department (scheduled to go live later this month), I scrapped everything they had done. I took a printout of their page (as it looked in Internet Explorer) and marked up what colors and fonts they had used.
Then I set down and wrote the same thing using XHTML/1.0 Strict and CSS1. This was about two days work, but the finished result now validates using w3c's validate tools, and it works reliably in all browsers I've managed to try, all the way back to Mosaic and Netscape 3, with or without images (yes, Lynx, Links, w3 and other text browsers work very well indeed too).
Not only did I get the pages to validate. By using CSS, I was able to get rid of several images they had been using with their design. The overall size of a page, including graphics and CSS, now weighs in at about 35 kbytes. This is compared to around 120 kbytes with the proposed code.
And even better, most things can be cached by the browser (CSS code and images). The only thing that needs reloading when you hit subsequent pages is the dynamic XHTML code, which weighs in at around 5 kbytes, compares to 40 kbytes in the proposed code.
Now, I think our students will like us. This result is even better than the pages that we have today. They render quickly and effortlessly even on old equipment or on extremely slow links.
I havn't been able to convince the faculty to make my code the "default" yet, but they might get the idea once people start noticing that our pages load much more quickly than the rest of the faculty pages.
So, using standards isn't always about making things render nicely in all browsers. It gives you a while heap of nice side effects that isn't worth sneezing at.
- CSS level 1: Not full support despite MS claiming so. E.g.background-attatchment: fixed; works only on the <body element.
- CSS level 2: Quite a mess, lots of things are broken, e.g. the infamous issues with the box model, and lots of things are not implemented, e.g. position: fixed;
- XML support is flaky at best, it tends to complain about DTDs even though they are valid.
- Other nasty quirks such as when having a <?xml
... ?> declaration, then it ignores the doctype and reverts to quirks mode with all the broken box models and such.
- Violation of the HTTP specification by ignoring the media type received from the server. Internet Explorer will most of the time second-guess the media type instead.
h tml#sec7.2.1
I design according to the standards and using Mozilla and Opera 7 as the design references, and then adjust the stylesheets for IE's buggy behavior, so that it renders fine there as well.http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.
while true; do eject; eject -t; done
Make your main stylesheet, then figure out which things don't work correctly in Netscape 4 (e.g. the width of a box incorrectly includes the padding, so for NS4 you should add the left and right padding when specifying a width). Where they differ, put the Netscape 4 code in the main stylesheet and the standards-compliant code in a second stylesheet. Comment the main stylesheet so you remember which code is specific to Netscape 4. Then load your stylesheets like this:
<link rel="stylesheet" href="/main.css" type="text/css">
<style type="text/css"><!--
@import url(/not-netscape4.css);
--></style>
Any browser except Netscape 4 will load both stylesheets, so the standards-compliant code in the second one will override the Netscape 4-specific code in the main one.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Now, depending on your audience, you may have to make sure the Netscape 4 version looks visually impressive, but don't think for one second that building your site using tables, bgcolor attributes, and font tags will be done without sacrifice. In web design there is ALWAYS sacrifice, it's just a question of what. If you build a web site using Zeldman's method you sacrifice:
- Complex layout in browsers v4 and under.
- Certain techniques that were refined during the era of the v3 and v4 browsers for pixel precise layouts.
Now if you resort to tables and font tags and the rest you are sacrificing:- Size - pages quickly become bloated with nested tables, redundant font tags and unnecessary images.
- Legibility - Everything is nested in table after table with no clear meaning to different tags.
- Forward-compatibility - You are betting on browser makers continuing to support non-standardized metrics that arose by coincidence.
- Accessibility - You don't need standards to support accessibility, but the two really go hand in hand. Using HTML tags as they were intended improves accessibility for non-standard user agents. Adding alt attributes, summaries, skip navigation links and more advanced techniques that are possible with standards make your site infinitely more usable for a blind person.
- Degradability - If your tag soup doesn't work in a browser you likely get something messy. If a browser doesn't support a standards-based page then maybe you lose the text formatting, but the information is still there.
- Development time - sure standards are hard to use if you've spent 10 years perfecting image slicing and table nesting, but table-based layouts are much more difficult to modify, update, output from server-side scripts, screen-scrape, or otherwise mess with in typical ways that web designers/developers are often asked to do.
Your excuses for dismissing standards are all red herrings. No matter how you develop, you are going to have to test your pages in all your target browsers anyway. However, using standards gives you a better chance with untested and future browser releases. Of course they are far from perfect, but resorting to outdated techniques doesn't improve the situation, regardless of how comfortable you might be with it.