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/
Standards are for pussies
Don't you Microsoft people do anything but read slashdot all day?
Trolling is a art,
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...
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/
It seems to me that the larger problem with web standards' adoptions is that many managers would prefer to just have crap, so long as they can have it "right now", and forego the longterm financial savings that web standards coding can provide. I would like to see a book on how to implement a web standard or two that will really save a lot of time right from the beginning, versus the kinds of major changes that take weeks to months to implement -- weeks & months that no small-business manager wants to pay for.
stuff |
Forgive me if this sounds clueless, but most people who are given the
task of setting up a web site are going to be looking at ways to not
have to do it from scratch. There are a lot of CMS (Content
Management Systems) out there, some free, some not. What *I* really
need is an O'Reilly book about CMS that helps wade through all the
stuff that's out there right now so the reader (me) can make an
informed decision about which way to go.
I did a quick check of the O'Reilly web site and all their CMS info
revolves around XML and Java. This does not help me.
Just open up MS-Word and use File-->Save As
web page
Voila! You have now created the perfect web page in ten seconds!
Microsoft takes care of all of the standards stuff so you don't have to worry your pretty little head about that. No really...don't worry.
No...don't do "View Source"
NO! Don't! EVERYTHING IS OK!! STEP AWAY FROM THE KEYBOARD
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.
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;
First, a reminder that this is 2003, not 1998, which was the year IE4 and Netscape4 were introduced. Since then, Mozilla has come, and with it Netscape 6 and 7. Also, we've seen the arrival of Konqueror (and Safari) and Opera.
Netscape 4 is dead: don't worry about it beyond getting your sites to still be legible in it.
Gecko based browsers, Konq, and Opera all do very well with W3C standards.
IE, however, has not had a major rendering revamp since version 4. The biggest change was for IE6, which is actually less compliant than previous versions. Sure it fixed some things, but broke many more.
Among web designers I know, IE is quickly gaining the hatred that had previously been reserved for Netscape4, because they know that NN4 is irrelevant, and the hatred has to go somewhere: the least compliant browser out there... IE.
Now, why is IE the least compliant? Because MS doesn't see the need to make it compliant. They have their precious market share, which is all they care about... not the users, not the developers which must coddle to IE because it works the way MS sees fit, not the standards bodies which MS continually ignores while attempting to participate.
The only way to break IE and move to standards is to use them, and explain to users why sites don't work: it's not the site's fault, it's the browser's.
Given all this, most people who have a clue about W3C standards would say you're doing your development backwards. You'd probably save a lot of time if you coded to the standards first, then hacked up the code for IE.
Ladies and gentlemen, we now have proof of the existance of the Anti-Christ, here on Earth! First, the user name "illuminata" is too Luciferian to be denied. Next, note the Slash UID 668963 containing "the Number of the Beast". Finally, we have the demonic message itself!
Prepare for the Apocalypse, for it is surely at hand! Slashdot has spoken!
That is all.
If you want the largest audience possible, then using the latest web standards, such as promoted by Zeldman, is not what you want to do. The reason for this is because not all web browsers in current use work with these standards. And there are many reasons people won't or can't upgrade those browsers.
There is a way to make web pages so that they can use standards, and still work on older browsers. However, you might not like the end result. What you get on the older browsers is a very poor presentation. For example, if you define the look of your page in cascading stylesheets, when viewed on a browser with no support for CSS, you get crap.
Boundary conditions are even worse. If the browser is a version that tries to support something, and does it wrong, you can get even worse that crap. It might not work at all.
Mixing standards can cause problems as well. Here is an example. Lots of designers seem to like blue backgrounds for the side rail menus. But lots of web browsers default to blue for hyperlink text. If you specify the color of the text in a stylesheet, but specify the background color of a table cell (or worse, the whole page), in HTML, then you can end up with a situation where some of what you specify is acted on, and some is not. You'd end up with blue text on a blue background, and therefore unreadable.
It would be great if everyone could upgrade to the latest browser. But if you are trying to reach the widest audience possible, you do have to consider that many in that audience will be using older computers which have smaller drive space, smaller RAM space, slower CPUs, and can only run older versions of operating systems and browser software. While Linux might well be a great replacement for old versions of Windows on those machines, you still have the problem if shaving a recent version of some Linux distribution down to fit, and getting a huge obese browser to run on a tiny, slow, machine.
Here is an example of a real web site done in a way that displays terrible on some browsers. You can see what it looks like in Netscape 4 in PNG, or JPEG, or true color GIF (works on Netscape 2 and later) formats. If you scan very close in the blue area on the left (this does not work with the JPEG image), you can see that the colors are #5a61a9 for the background, and #5b61a9 for the text (specified by their HTML in the body tag, so they intentionally did this). By radically exaggerating the red plane (e.g. everything #5a and below is made #00, and everything #5b and above is made #ff), you can see (PNG, JPEG) the text was really there. And you'd think that a state government would be concerned enough about making their site available to all audiences, including the economically disadvantaged who can just barely even get a computer and internet access. But no, they don't actually care (I talked to these people, and they really don't care). Here is another crappy web site. By comparison, this site and this site look fine in this older browser.
now we need to go OSS in diesel cars