Slashdot Mirror

mikejuk writes "Google and Opera split from WebKit to create Blink, their own HTML rendering engine, and everyone was worried about the effect on standards. Now we have the first big example of a split in the form of CSS Regions support. Essentially Regions are used to provide the web equivalent of text flow, a concept very familiar to anyone who has used a desktop publishing program. The basic idea is that you define containers for a text stream which is then flowed from one container to another to provide a complex multicolumn layout. The W3C standard for Regions has mostly been created by Adobe — a long time DTP company. Now the Blink team has proposed removing Regions support to save 10,000 lines of code in 350,000 in the name of efficiency. If Google does remove the Regions code, which looks highly likely, this would leave Safari and IE 10/11 as the only two major browsers to support Regions. Both Apple and Microsoft have an interest in ensuring that their hardware can be used to create high quality magazine style layouts — Google and Opera aren't so concerned. I thought standards were there to implement not argue with." Although mikejuk thinks this is a bad thing, a lot of people think CSS Regions are awful. Mozilla has never intended to implement them, instead offering the CSS Fragmentation proposal as an alternative. One major flaw of CSS Regions is its reliance upon markup that is used solely for layout, violating the separation of content and style that CSS is intended to enforce.

Michael J. Ross writes "With more people accessing the Internet using mobile devices than computers, web designers and developers are challenged to make sites that work well on both categories of hardware — or resign themselves to the greater costs and other disadvantages of maintaining two versions of each web site (a mobile-ready version as well as one for much larger screens). Fortunately, recent advances in web technologies are making it easier to build web pages whose contents and their positioning are automatically modified to match the available screen space of the individual user. These techniques are explored in detail in a recent book, Responsive Web Design, written by Ethan Marcotte, a veteran web designer and developer." Keep reading for the rest of Michael's review. Responsive Web Design author Ethan Marcotte pages 143 pages publisher A Book Apart rating 9/10 reviewer Michael J. Ross ISBN 978-0984442577 summary A pithy tutorial on responsive web design. This title was published on 7 June 2011, under the ISBN 978-0984442577, by A Book Apart, as the fourth in their series of "brief books for people who make web sites." On the publisher's page, visitors will find brief descriptions of the book and its author, links to purchase the print and e-book versions (or the two combined, at a substantial discount), and three promotional blurbs also used on the back cover of the print version. The e-book package consists of six files: the book in EPUB, MOBI, and PDF formats; an EPUB document on responsive design for video; a letter from Jeffrey Zeldman (the book's publisher), Jason Santa Maria (its designer), and Mandy Brown (its editor); and the previous five files zipped into an archive. This book is also available in French, perhaps reflecting the publisher's greater awareness of internationalization relative to mainstream technical publishing houses.

Readers of the print version will likely be first struck by its diminutive size — just 143 pages. In fact, the book is so slender that only half of the spine title actually fits on the spine. (It's either a bold design statement against conventional publishing practices, or an even bolder typographical error committed inexplicably by a well-regarded design firm.) Flipping through the glossy pages, readers will also notice the judicious use of text color to indicate HTML and CSS code, and highlighted fragments therein. Even more visually impressive are the full-color screen shots and other figures. The book begins with the previously mentioned letter, as well as a short yet delightful foreword by Jeremy Keith; it ends with the author's acknowledgments, suggested resources, references by chapter, and a suspiciously brief index, not much longer than the author bio that follows it.

The bulk of the information is organized into five chapters — the first of which, "Our Responsive Web," presents a high-level rationale for architecting web sites that can be maximally useful on a wide range of devices, with screen sizes ranging from the smallest found on smartphones, up to widescreen TVs attached to web-enabled game consoles. Throughout the book, to illustrate the principles of responsive design, the author utilizes a fictional example web site, "Robot or Not", designed to assist users in identifying robots masquerading as humans (which would have been helpful to the crew of the spaceship Nostromo!). This short chapter is essentially just an introduction.

The author gets down to business in the second chapter, titled "The Flexible Grid," which demonstrates how grid-based layouts can be used to more easily position page elements for greater visual consistency. He goes into detail in showing how such layouts can be made flexible, with font sizes specified in character widths and positioning specified in proportions of containing elements. Experienced designers will probably not encounter any new concepts in this material. These techniques are extended in the subsequent chapter, "Flexible Images," which explains how to use percentages when working with images (both markup and CSS) and other media types — including workarounds for the browser most despised by web designers, Internet Explorer.

Media queries, introduced to the world in CSS2, are now a key technology in responsive design, and are discussed in Chapter 4, which forms the core of the book. The author shows how to use them to cause the browser to apply CSS rules selectively based upon such factors as the width of the browser viewport. All of the narrative is clear, except for the statement on page 66 that the example web site's logo is "scaled down to a nearly microscopic size" in Figure 4.2, when in fact it appears unchanged. Readers may wonder why — after noting that mobile devices do not consistently use "handheld" or "screen" as their media types — the author does not explain why the recommended media queries use "@media screen," and not "@media all" to be more encompassing. Nonetheless, the discussion of media query techniques is instructive. It continues with a look at how to use them in older browsers, using JavaScript libraries, css3-mediaqueries-js and Respond.js. Lastly, the author shows how incorporating some fixed widths into a flexible design may be an optimal approach.

The fifth and final chapter, "Becoming Responsive," discusses real world implications of responsive design. The author counters an interesting contention: web sites on mobile devices should not simply be the desktop content scaled down to a smaller screen, but instead should offer different content, more appropriate for the individual on the go. He then touches on the topic of designing sites first for mobile, rather than the traditional approach of trying to shoehorn a full-size site onto a small screen. The bulk of the chapter is devoted to presenting a workflow employed by the author in creating actual client sites. It concludes with a demonstration of how to add a slideshow using a jQuery plug-in and some custom code, so it abides by the principles of progressive enhancement.

In terms of the physical book, the quality is top-notch, and the full-color images are quite compelling. Sadly, each figure tends to bleed through to the other side of its page, but fortunately not enough to inhibit reading the text on the other side, or appreciating any of the images. The e-books are also quite readable — probably more so compared to the electronic versions of other programming books, given the smaller line lengths.

In terms of the narrative, Ethan Marcotte has a somewhat goofy writing style, replete with nerdy side comments and jokes, which some readers may regard as padding, particularly in those sections where they are quite numerous. The same may be said for the hyperbole in some spots, such as "Marvelous. Wonderful. Stupendous, even." (page 33). On the other hand, many readers may enjoy the lighthearted style, especially those jokes that work well. More importantly, the explanations are generally comprehensible and thorough. I was able to find only one erratum ("or a maybe an animation," on page 119), and the only grammatical error was the frequent use of the term "that" to refer to people, instead of "who." Otherwise, there were no glitches in the writing, and most techies will find this book a fairly quick read.

From a higher-level perspective, one sometimes hears an objection raised against web design/development books such as this one — namely: all of the book's information is freely available in articles, blog posts, forums, IRC channels, and other resources for programmers. So why purchase a static book whose author probably started writing it months if not years in the past? Such technical information is scattered among numerous websites, thereby forcing us to spend time searching around, and in many cases skipping over redundant material. Also, the advice tends to vary in quality, and hence we must distinguish what information is out of date or simply invalid. Likely every experienced developer has been tempted by an article titled such that it sounded as though it would contain the exact solution to the problem at hand — only to discover that the title was quite misleading, or the people contributing to the comments were equally befuddled (and frustrated). Technical books geared toward the working professional can obviate these problems, because they bring together most of the information known by the industry, into a cohesive whole, that is then vetted by technical reviewers and editors. In the case of this monograph, Ethan Marcotte's well-regarded seminal article, in conjunction with the other most popular articles on responsive web design, would still not be a sufficient substitute for this resource.

For web designers and developers alike, Ethan Marcotte's book is a neatly-crafted and authoritative single-source tutorial on how to build responsive web sites that will likely prove robust on a wide range of platforms.

Michael J. Ross is a freelance web developer and writer.

You can purchase Responsive Web Design from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

dotne writes "Microsoft has submitted Embedded OpenType (EOT) to W3C and a slimy campaign for EOT has been launched. EOT is a DRM layer on top of normal TrueType/Opentype files; EOT ties a font file to a certain web page or site and prevents reuse by other pages/sites. Microsoft's IE has supported EOT for years, but it has largely been ignored due to the clumsiness of having to regenerate font files when a page changes. Now that other browsers are moving to support normal TrueType and OpenType on the web (Safari, Opera, Mozilla, Prince), W3C is faced with a question: should they bless Microsoft's EOT for use on the web? Or, should they encourage normal font files on the web and help break Microsoft's forgotten monopoly?"

RyoShin writes "A List Apart, an excellent resource for web development and related aesthetics, has put together an article based on original research by Jessica Enders into 'zebra striping.' From the article: 'Zebra striping [coloring alternate rows] is used when data is presented in an essentially tabular form. The user of that table will be looking for one or more data points. Their aim is to get the right points and get them as quickly as possible. Therefore, if we set a task that uses a table, and zebra striping does make things easier, then we would expect to see improvements in two things: accuracy and speed.' The conclusion of the peer reviewed paper? It's a wash. Striped tables offered only a slight increase in accuracy and speed overall. The article notes a few other benefits to using Zebra striping, so it's all up to the individual."

RyoShin writes "A List Apart, an excellent resource for web development and related aesthetics, has put together an article based on original research by Jessica Enders into 'zebra striping.' From the article: 'Zebra striping [coloring alternate rows] is used when data is presented in an essentially tabular form. The user of that table will be looking for one or more data points. Their aim is to get the right points and get them as quickly as possible. Therefore, if we set a task that uses a table, and zebra striping does make things easier, then we would expect to see improvements in two things: accuracy and speed.' The conclusion of the peer reviewed paper? It's a wash. Striped tables offered only a slight increase in accuracy and speed overall. The article notes a few other benefits to using Zebra striping, so it's all up to the individual."

RyoShin writes "A List Apart, an excellent resource for web development and related aesthetics, has put together an article based on original research by Jessica Enders into 'zebra striping.' From the article: 'Zebra striping [coloring alternate rows] is used when data is presented in an essentially tabular form. The user of that table will be looking for one or more data points. Their aim is to get the right points and get them as quickly as possible. Therefore, if we set a task that uses a table, and zebra striping does make things easier, then we would expect to see improvements in two things: accuracy and speed.' The conclusion of the peer reviewed paper? It's a wash. Striped tables offered only a slight increase in accuracy and speed overall. The article notes a few other benefits to using Zebra striping, so it's all up to the individual."

dotne writes "CNET has published an article called Acid2, Acid3 and the power of default. The article predicts that IE8 will not pass the Acid2 test after all: '[Another] scenario could be that Microsoft requires Web pages to change the default settings by flagging that they really, really want to be rendered correctly. Web pages already have a way to say this (called doctype switching, which is supported by all browsers), but Microsoft has all but announced that IE8 will support yet another scheme. If the company decides to implement the new scheme, the Acid2 test — and all the other pages that use doctype switching — will not be rendered correctly.' Microsoft's IE8 render modes have been discussed here previously, and they've caused an uproar in the web development community. According to the scheme, authors must put Microsoft-specific <meta> tags into their pages in order for them to be rendered correctly. I doubt Acid2, nor Acid3 will have Microsoft extensions in them."

dotne writes "CNET has published an article called Acid2, Acid3 and the power of default. The article predicts that IE8 will not pass the Acid2 test after all: '[Another] scenario could be that Microsoft requires Web pages to change the default settings by flagging that they really, really want to be rendered correctly. Web pages already have a way to say this (called doctype switching, which is supported by all browsers), but Microsoft has all but announced that IE8 will support yet another scheme. If the company decides to implement the new scheme, the Acid2 test — and all the other pages that use doctype switching — will not be rendered correctly.' Microsoft's IE8 render modes have been discussed here previously, and they've caused an uproar in the web development community. According to the scheme, authors must put Microsoft-specific <meta> tags into their pages in order for them to be rendered correctly. I doubt Acid2, nor Acid3 will have Microsoft extensions in them."

Dak RIT writes "In a blog post this week, Microsoft's IE Platform Architect, Chris Wilson, confirmed that IE8 will use three distinct modes to render web pages. The first two modes will render pages the same as IE7, depending on whether or not a DOCTYPE is provided ('Quirks Mode' and 'Standards Mode'). However, in order to take advantage of the improved standards compliance in IE8, Web developers will have to opt-in by adding an additional meta tag to their web pages. This improved standards mode is the same that was recently reported to pass the Acid 2 test, as was discussed here."

rainhill writes "In April 2007, A List Apart and An Event Apart conducted a survey of people who make websites. Close to 33,000 web professionals answered the survey's 37 questions, providing the first data ever collected on the business of web design and development (PDF) as practiced in the US and worldwide. Among the findings: over 70% of people in this field earn less than $60K per year. There is little gender bias in salary. And over 70% of Web workers post to a blog; this number shows very little dropoff with age."

rainhill writes "In April 2007, A List Apart and An Event Apart conducted a survey of people who make websites. Close to 33,000 web professionals answered the survey's 37 questions, providing the first data ever collected on the business of web design and development (PDF) as practiced in the US and worldwide. Among the findings: over 70% of people in this field earn less than $60K per year. There is little gender bias in salary. And over 70% of Web workers post to a blog; this number shows very little dropoff with age."

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

SpunOne writes "Apparently Jeffrey Zeldman is as sick of Web 2.0 as many of us have become. In his latest article, titled "Web 3.0," he really sticks it to the Web 2.0 fan boys, and dispels a lot of the hype generated by our young new friends. It's easy to grow apathetic when a new idea gains so much traction so quickly, but his points are clear and accurate, and deserve consideration."

William Nichols writes "With a couple of projects coming up that are going to require complete W3C CSS and XHTML validation (with 1 client requiring just a pure CSS layout) I thought it was time to brush up on some CSS knowledge, and maybe learn a new thing or two. I have spent the past week with a newly released book (and one of the smaller CSS books out there), the Web Standards Solutions The Markup and Style Handbook. The author, Dan Cederholm, has now become my right hand man, so to speak." Read on for the rest of Nichols' review. Web Standards Solutions: The Markup and Style Handbook author Dan Vederholm pages 253 publisher Friends of Ed rating 8.5 of 10 reviewer William Nichols ISBN 1590593812 summary A clear reference on designing with XHTML and CSS through a standards based approach

With the title Web Standard Solutions (which we will refer to as WSS from here on), you might expect this to be a book that is going to solve your problems, and without disappointment that is exactly what is does.

WSS takes a problem based approach instead of the commonly used project based approach to teaching you the value of designing to strict standards. I found this approach very refreshing, WSS kept my attention by presenting a problem, and then presenting 3-5 solutions on how to accomplish the task at hand. With each example Dan takes you through several ways to achieve the required result. Each of the methods shown are common patterns that different developers/designers would use, and the pros and cons of each are well articulated.

A lot of you may know Dan from his Simplebits. website. If you frequent Simplebits you will immediately recognize his style in the writing of WSS. Much like the mini quizzes that are used on his blog, this book is really a compilation of the hurdles that you are likely to face when trying to design to strict standards, and the solutions presented will get you over them.

WSS will also help the budding developer realize the business value of designing to standards. Once you start designing with standards, search engine rankings can jump, continued maintenance becomes a breeze, and the accessibility to screen readers (or other requirements) can be elegantly met.

One of my favorite parts of the book is the in-depth techniques used to style lists. WSS shows you how to take a regular non-formatted list and, using CSS, style it in several ways: as a vertical shopping list; without bullets and indenting; with custom bullets; and eventually as a horizontal navigation bar with changing bullets.

This book really stands out when covering the most basic foundations of layout such as paragraphs, lists, headers, titles and the like. The first half of the book really gets into the proper use of the most basic CSS techniques and proper selection of tags for headings, quotations, etc. While the second half of the book requires you to use what you have learned along the way to start building CSS based layouts.

If you are a regular at some of the advanced sites like CSS ZenGarden or A List Apart this book may be a little basic for you. Even still you will probably be able to take some techniques from it that you can use, this book is really more for the designer that is capable but not quite deadly with their CSS knowledge.

Overall I would give Web Standards Solutions the Markup and Style Handbook an 8.5 out of 10. I really think it does a fantastic job at keeping the reader interested in the subject (something that is often very hard to do in technical books) and will definitely be a great business tool for you. A quick read it is, but a valuable reference that has earned a spot next to my keyboard, my 3 bars of caffeinated soap, and the trusty case of bawls.

You can purchase Web Standards Solutions: The Markup and Style Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Joe Clark writes "Nearly a year after an interview with this correspondent highlighted a few problems with Slashdot's HTML, Daniel M. Frommelt and his posse have recoded a prototype of Slashdot that uses valid, semantic HTML and stylesheets. Frommelt projects four-figure bandwidth savings in the candidate redesign, were it adopted, not to mention better appearance in a wide range of browsers and improved accessibility. Next he needs volunteers to retool the Slashdot engine. And yes, he did it all with CmdrTaco's blessing." Slashdot has kept its HTML 3.2 design for a long time ("because it works"), but perhaps this effort will be a catalyst for change...

Qbertino writes "Jeffrey Zeldmans Alistapart ("ALA"), a very educative website for everything concerning webdesign, that also heavily promotes web standards, has come back online in it's third incarnation. As you might expect from one of the world leading web designers it works good in all standards compliant browsers and - other than recent attempts at webdesign - doesn't make your eyes bleed ;-)."

We sent 10 of your questions to usability guy Joe Clark, and he took it upon himself to go a bit beyond simply answering them. In his reply he said, "Answers attached in a valid XHTML file. I would suggest at least retaining the id attributes. I copy-edited all the questions, but the words are all the same; they are now merely spelled and capitalized correctly. I think all the links work." Whatever. We left Joe's formatting intact. It's a little different from our usual style, but variety is the spice of Slashdot. Ask the Expert: Accessibility 1) How far should it go?

by newsdee

Macromedia Flash has integrated many accessibility features in an effort to promote development of content for special needs. However, can we realistically try to turn any multimedia feature into its accessible equivalent? Is it even feasible other than providing a text-only equivalent?

There seems to be a stereotyped understanding of Flash content at work here. Flashturbation is not the only usage of that authoring tool.

I believe the question really intends to ask Are artistic uses of Flash, like Josh Daviss Praystation, really amenable to accessibility? The answer is a qualified yes, and I say that because Praystation-like Flash experimentation is essentially a form of cinema that merely uses the Web as a delivery mechanism. Cinematic experiments of this sort are indisputably a different species from other forms of Flash development.

In that example, the solution is to treat the Flash objects as a movie and apply standard movie accessibility features, namely captioning and audio description. Im not one of those people who believes that abstract, experimental, or non-narrative cinema cannot be captioned and described lots of music videos fall into that category, and theyve been captioned for nearly 15 years. (Description of experimental audiovisual artworks has not really been attempted to my knowledge, but description of abstract art in museums and of non-narrative plays and dance performances in theatres have all been going on for years. Its perfectly possible.)

The challenges, then, are two: Infrastructure and interface. There isnt really a very good way of including captions or descriptions in a Flash file as yet (an infrastructure problem). Macromedia knows all about this (Ive discussed it with them at length, and also written about it), and it will eventually be fixed. (Even finding an example of Flash with captioning is difficult today. Youd think Id have a complete list at the tip of my fingers, but I dont. The Macromedia Contribute feature tour is one case.) I dont know of any Flash animation that was ever described.

The interface problem is: How does the viewer turn captions and descriptions on and off? This isnt like a TV set, where you can manipulate onscreen menus (and how do you manage that if youre blind?) to turn captions and/or descriptions on and off. Browsers are not smart enough to automatically turn access features on and off, though I think a future upgrade of one file format that shall remain nameless will be the first to include such a capacity. At any rate, this may be one of the rare cases where an overt visual change must be made to accommodate accessibility actual selectable buttons to turn CC and DX on and off. (The buttons themselves have to be accessible, i.e., part of the tabbing order and with alternate texts and so forth.)

Now, lets consider other examples of Flash.

Banner ads the really big skyscraper ads that bug your arse on so many sites The usual Flash accessibility features can be used, and you can be smart and include the Flash object inside, say, an iframe element, which provides vast options for accessibility. (You can add a long description to the iframe, though thats questionably useful, and include alternate content in case the main content cannot be loaded, which could be an ordinary animated GIF or still image with alt and title.) Comics Flash-based comics can be relatively straightforward to make accessible (Apocamon doesnt seem too tricky its essentially a panel-based comic strip with a wee bit of animation) or could require full-on cinematic techniques, as with Broken Saints. User interfaces Flash can be and is used as a tidier means of providing a user interface, as at FoxSports.com or in the Neuros audio-player demo. The temptation, as in that last example, is also to use motion graphics and audio, which may require the same CC and DX as before, but many user interface can be made adequately accessible with todays Flash accessibility tools (text equivalents, making objects visible or invisible in the document structure, etc.). Manipulable objects Games (including the Royal National Institute for the Blinds ill-advised consciousness-raising game, no longer online) and even some interfaces (like History of Health Care) may include objects youre intended to grab and manipulate with the mouse. The current Flash accessibility tools are not really up to the challenge of adding keyboard equivalents for such manipulable objects. You could hack it together yourself, but there are no built-in commands or primitives you could use in a standards-compliant way. Intros Skippable intros are just as awful today as the day they were invented. Unfortunately, we cant make value judgements about which information should and should not be made accessible. Even skippable intros have to be made accessible, either by treating them as cinema or simply giving them a few text equivalents. The skip-intro link has to be selectable by keyboard, of course. Tools These interfaces let you do something. One I like a lot, if only because I am a typography queen, is Jeremy Tankards font viewer, though it is admittedly overkill because other font-viewing miniprograms do not require Flash. It may be possible to make the inputs to such tools accessible (you can place the cursor in the right place, operate controls, and so forth), but the results might be intrinsically inaccessible. (Note that artists portfolio sites, font and clip-art vendors, stock-photo houses, and other sites that sell visual imagery using ordinary HTML can be made passably accessible even to a blind person. In the Tankard case, perhaps only the name of the font and the text entered would be rendered to a screen reader or other device.) E-commerce Perhaps the most credible Flash instance, E-commerce sites like Ted Baker (see its Footwear store) may include all the features of the other instances Ive listed here. Since E-commerce is a convenient way to shop for many disabled people, I would strongly emphasize the need for accessibility. But it might be stretching the limits of current Flash access tools, since you have to make an interface, product shots and other images, and text all accessible. Thats not difficult in HTML, but I dont have any examples to point to of accessible Flash-based E-commerce sites that we could use as a comparison; I dont know how hard it would be to make such sites accessible. Aside: The most sophisticated Flash site Ive ever seen is DirtyBastards.com. (No direct hyperlink; consider this the strongest possible warning of adult content. Be very sure you want to look at it.) The usability could use an update, but in general its astounding. Should we ever be in the same city, Ill take anyone who can update that site for accessibility to dinner at the restaurant of their choice.

I would add a proviso here. Accessibility does not relate solely to blind people. As mentioned above, any quasi-cinematic work with audio requires captioning; deaf people need accessibility, too. There is much more attention being paid now to the Web-accessibility needs of people with learning disabilities (the most famous of which is dyslexia), which well get to later.

Learning-disabled people are by far the hardest to accommodate online, and for many HTML pages, they are probably impossible to accommodate in any really helpful way. Flash animations could be a good solution for that group because you can build in many levels of information, use audio and graphics, and provide really good controls for pacing (because having too much information coming at you all at once is a barrier for many people). Inevitably, accessible Flash in that context would limit itself to custom-engineered animations specifically made for that audience; I doubt that general uses of Flash will be upgraded for that kind of accessibility.

Text-only sites are not the alternative to accessible sites. Text-only is not accessible. Well discuss graphic sophistication later.

Biggest problem

by robbo

What, in your opinion, is the most common complaint concerning accessibility and Web sites? In other words, if in the interests of accessibility you could encourage site owners to change only one thing about how they operate, what would it be?

Images. Seriously, if youve got an ordinary HTML Web page and you make absolutely all your images accessible including, crucially, adding alt="" to every spacer GIF and every other meaningless graphic youre four-fifths of the way to being an accessible Web site for the group with the greatest single need, the blind and visually-impaired.

I emphasize coding to standards. Unless you have an airtight reason (like youre stuck using an old content-management system you cannot afford to replace), I really dont want to have anything to do with you unless youreproducing valid HTML. Now, tiny invalidities are just that, tiny: <hr> and <hr/> really are the same thing. And Im sure that ultra-purist geeks will now launch a hypocrisy hunt and comb through my entire Web presence to locate pages with non-valid markup. (Knock yourselves out. I make small mistakes, and have not updated scores of very old pages. Im also a vegan with some shoes and accessories made of leather. Complete purity is sometimes unattainable.) In one of the many ironies of Web development, it is indie developers like me who have a higher success rate in achieving valid, accessible sites even though larger commercial operations are the ones where valid HTML and accessibility are more urgently needed.

In any event, if youre producing tag soup, as far as Im concerned youre demonstrably not all that interested in responsible Web development.

The upside? If you do write valid pages, you have to include at least an alt text for every graphic. For no extra effort (you have to do it anyway), you get basic accessibility.

Number two on the list is navigation. Left-hand and top navbars stacked with link after link are a nightmare to wade through if you have a mobility impairment that reduces your ability to use a mouse or keyboard. (Screen-reader users are not so heavily affected; they can skip entire table cells, for example. I suppose all-CSS layouts are harder to skip through. But thats not the page authors problem; its incumbent on the adaptive technology and browser to clean up their act.)

If youre able to use a mouse, you can just avoid the entire navbar. But a mobility-impaired person may be stuck tabbing from one link to another and thats the best-case scenario. Quite possibly, a mobility-impaired visitor may be using software that cycles through a set of input choices for example, the mouse; then the alphabet keys of keyboard; then the number keys; then the function keys. You may have to wait until the keyboard option cycles back again in order to type repeated keystrokes. (You may have a mental image of a sip-and-puff switch or Christopher Reeve using speech-input software. The principles are the same and so is the inconvenience.)

If you, the page designer, stack 20 or even a hundred links in a left-hand navbar and assume that people can simply tab through them, well, (a) tabbing 20 or a hundred times is something youd never expect a nondisabled person to put up with, and (b) some people will have to wait 20 or a hundred cycles of their software in order to do the equivalent of pressing the Tab key.

The solution? Put skip-navigation links on top of every navbar with, say, ten or more links. (Or fewer. Use your judgement. Section 508 regulations technically require a skip link in every navbar, even for a page footer.)

Note that skip-navigation links have to be visible; a lot of people use hyperlinked single-pixel GIFs with alt texts, but those are invisible to mobility-impaired people, most of whom have normal vision. The links dont have to be ugly or intrusive, but they have to be plainly visible and selectable. (If you want to be thorough, you can give them accesskey and tabindex values.)

Do those two things and your site becomes vastly more accessible to two large disability groups right then and there.

Accessible Slashdot?

by ictatha

How does Slashdot stack up? What about blog-type sites in general? What can be done on these types of sites to make them more accessible?

Mark Pilgrim has fully strip-mined this topic. (He also tech-edited my book and is generally formidable.)

The issue here is random vs. serial access. A nondisabled site visitor can jump around the page. If you can see, its very easy to skim the page, and it is also very easy to zip to what interests you if you can operate a mouse or keyboard well. Nondisabled people have random access to the contents of a page. Many disabled people the blind and the mobility-impaired in specific experience a Web site serially, with one item after another articulated (as in speech or Braille) or selected. The page author can make skipping around easier, and so can relevant software like screen readers, but its still going to be harder to navigate than for a nondisabled person.

Slashdot is dominated by words. The page introducing this interview carried about 6,900 words even with minimal comment expansion. The issue, then, becomes navigation, which I discussed in the previous answer. Adding hyperlinks to skip various navbars would be a good first step.

Slashdot could certainly use better semantic markup. Valid code is a must; I want Slashdot to eat my own dog food. Subject lines of postings could and should be marked up as headings (h1 through h6); font elements could be eliminated; Im not wild about table markup to achieve indention, though making structural hierarchies apparent is not easy at all (perhaps unordered lists with a style declaration of list-style-type: none might suffice). It would then be possible to navigate from heading to heading.

If youre running a more limited Weblog with just a couple of screenfuls of text at a time, then my advice is simple: Write valid code, provide a text equivalent for every image, work on navigation a bit, and youve made a big dent in the problem.

Photoblogs or those containing multimedia are, of course, more complicated, but as long as every photo has an alt text and your multimedia is captioned and described, youre doing well. It is certainly easy to add alt texts to your photos, but captioning and description are hard to do well and are technically difficult to implement. Im mentioning the multimedia case merely for completeness; I dont read any blogs that regularly post video and audio. (I suppose The Ben Brown Show was an example.)

Accessibility

by acehole

Do you think that where companies are being sued or forced into updating their Web pages at great expense to include accessibility for the blind in their Web pages when the blind could easily find another similar service offline is reasonable?

You have inadvertently stumbled across an extensive issue in disability law the question of providing equivalent or comparable access, or access that is equal in dignity to that afforded a nondisabled person.

You can draw parallels with the physical world. Think of barrier-free entrances to buildings. If the main entrance is at the centre of the buildings face but uses a staircase you cant remove, then providing a barrier-free entrance at the left side of that building would probably be considered comparable or equivalent access. But if you force a mobility-impaired person to walk through an alleyway and take a rear service elevator that is otherwise used for garbage, your accessibility probably is not comparable or equivalent. (Thats in the case of a relatively new building. A historic building or another exceptional case might permit different treatment of that sort.)

If we consider information media, theres a distinction to be drawn between old and new media, or non-electronic and electronic forms. Books are the canonical example: They cannot be made intrinsically accessible to a blind person because a book embodies a single immutable form. You have to provide accessibility elsewhere, as through a large-print edition (its a separate form), a Braille edition (also separate), or a talking book (separate yet again).

Electronic (or audiovisual) media can carry accessibility along with themselves:

• You can add closed captions and closed descriptions to a television program, DVD, online video segment, or first-run movie. (Im skipping some technical details in the movie example.)
• You can add closed captions to a videotape.
• You can add accessibility features to a Web site.

(In the first two cases, you could instead add open captions or descriptions that everyone sees or hears, but thats a very unusual practice, and by doing so you essentially create a separate work, just like publishing a large-print, Braille, or talking-book edition of a printed book.)

In all the examples above, you the viewer can activate the accessibility if you need it or ignore it if you dont. Because Web sites are electronic and can carry hidden access features, the answer to aceholes question is no, it is not reasonable to expect disabled people to go somewhere else to get the same information or enjoy the same experience.

Accordingly, yes, Southwest Airlines reservation Web site should be accessible, and no, it is not OK to expect blind people to call a telephone number when nondisabled people do not have to do so. (Read various other reasons why.)

Thats unequal treatment right there. It is not comparable or equivalent treatment, and, I argue, it impugns the dignity of a visually-impaired person who has already made a commitment to independence by using the Web with adaptive technology.

I also reject, in the strongest possible terms, the offensive and offhand claim that accessibility can be achieved at great expense. I believe the colloquial term for a claim like this is bullshit. Updating or retrofitting a site for accessibility does cost more than designing it properly in the first place, but thats true everywhere: Have you costed out adding barrier-free access to an old building vs. including it in the original designs? Retrofitting may cost more, but I deny that the expense is great. Even very extensive sites with huge swaths of multimedia can be made accessible, and it is doubtful that, given the budgets of such sites, the expense would be great.

In any event, developers always find a justification for what they like to do, whether it be Flashturbation or coding custom JavaScript features or whatever else. Its a bit late in the day, in Web-development terms, to claim that accessibility is not one of the arrows in the quiver of the competent practitioner.

Now, another of the subtexts in this question really, it is a spiders web of half-truths, barely-suppressed resentments, and ignorance suggests that the only way to achieve Web accessibility is by being sued or forced. I have consistently argued that lawsuits are the worst way to achieve accessibility, particularly in the U.S., with its poisonous atmosphere. Lawsuits merely get peoples backs up and sour the defendant on the entire concept. Defendants are forced to belittle and invalidate the concerns of people with disabilities merely in order to provide an adequate defense in the case. This is no way to run a railroad.

But lawsuits (and human-rights complaints and other actions) are still necessary from time to time. Disability law is old and tends not to expressly include the Web. (Sometimes it doesnt even include established accessibility techniques for old media, like audio description on TV.)

Its unrealistic to wait around forever for clueless lawmakers, who can barely use a cellphone let alone surf the Web, to update the legislation. To get some kind of jurisprudence on the books, lawsuits and complaints have to be filed from time to time. Sometimes it works, sometimes it doesnt, but the law is a tool that must be available to everyone, including people with disabilities, whose rights have legal standing.

A competent Web developer builds accessible Web sites and does not wait to be asked to do so, let alone sued or forced.

Market for Web developers

by ragnar

Im considering a starting up a Web development firm with a focus on accessibility. I have good relations with the principals of an accessibility testing firm and believe the businesses can complement each other well. Im a part owner of a Web development firm at the moment that isnt interested in pursuing this market, but I believe there is a significant market.

Can you elaborate on the market for Web development firms that focus on accessibility? Aside from the normal perils of launching a new business (which Im fairly acquainted with), can you expound on the market need for firms that endeavor to deliver accessible content?

Deliver[ing] accessible content and starting up a Web development firm with a focus on accessibility are two different things, so lets focus on the latter.

I would say that the market for accessibility-specific Web consultancies is rather small and will have a short lifespan. I can say this with some confidence as I am an authority on accessibility, with a published book to prove it, and I hardly get any business. Even taking other factors into account, I think its the nature of the work. I have various reliable indications that other consultants arent flush with activity, either.

Why?

• Accessibility is neglected. People cant hire you to do what they never knew needed to be done anyway. Nor will they hire you to do what they resent having to do in the first place and will resist doing until their dying breath.
• Contracts are small. Even very large sites tend to be run by CMSs or templates. Once you clean those up, boom, tens of thousands of pages become accessible. There is often not a lot of billable work involved, as I know myself all too well.
• Attainable expertise. If, as I contend, accessibility is merely one of the skills a competent developer must have, eventually all the competent developers will gain that expertise. They wont need outside experts. Even if in-house access knowledge is demonstrably worse than outside consultants, there are all sorts of precedents for companies making do with barely-passable accessibility because its cheaper. There is a preference for meeting the letter of any requirements (whether self- or externally-imposed) rather than doing accessibility well.

Now, what may work massively better is, in fact, accessibility testing (and certification). It is extremely difficult and time-consuming to test site accessibility with actual disabled persons using actual adaptive technology. A firm that updates Web sites to accessibility standards, advises on how to write new sites that conform, and tests them to prove it may be a winning combination.

The issue of then certifying a site as being accessible (or meeting certain requirements) becomes a bit trickier, but Id really like to see someone give it a go. Note that any venture like this will require thoroughgoing knowledge of the Web Content Accessibility Guidelines, the Section 508 regs, adaptive technology, and multimedia accessibility, and that knowledge definitely includes an understanding of exceptions to the rules. I deal with too many people who literally read and literally apply whatever guideline theyve decided is gospel. Accessibility requires human judgement based on knowledge and experience. Dont set up shop without it.

What of dynamic images (charts and graphs)?

by kuwan

I see that Chapter 6 addresses the image problem which you state is a core concern in accessibility. My question is, what is your solution to data-intensive sites that display their information using graphs? For sites that have constantly changing data (stock charts, for example), what solutions/tools are there to make their graphics accessible?

The answer is that such information, in certain cases, cannot be made meaningfully accessible to a blind or visually-impaired person, or probably to a learning-disabled person. Other disability groups should be unaffected.

This, of course, leads me to my perennial complaint about the Web Accessibility Initiative and accessibility advocates generally: Theyve got no style. They have no understanding of graphic design and typography, and they project this ignorance onto the rest of the world.

To use one of my maxims, accessibility opponents think accessibility means a text-only Web site and hate the idea, while accessibility advocates also think it means a text-only site and love the idea. Theyre both wrong.

One consequence of this ignorance of visual design? The implicit claim that every illustration can be epitomized in words. You could only make this claim if you were so visually unsophisticated that you couldnt differentiate one kind of illustration from another. Of course, this is hogwash: The reason why we use illustrations is because words (or numbers) are sometimes too hard to understand by themselves.

A graph of stock performance, radar weather maps, ultrasound images any picture that is worth much more than a thousand words presents a quandary. The goal here is accessibility a disabled visitor must have equivalent access to the information conveyed by the graphic. If the underlying data is numeric, in theory you could provide the underlying data (as through the longdesc attribute of the img element just set up an HTML file, or, theoretically, a spreadsheet or a PDF, that could be loaded to describe the illustration at length).

But remember, all that numeric data was so hard to understand for nondisabled people that it was turned into a chart; now youre expecting screen-reader users to wade through those numbers one at a time? Like packing, unpacking, and repacking a suitcase, converting data to graphics and back again tends to leave something behind in the transformation.

You may have provided a text equivalent in such a case, but you have not provided accessibility.

I am not giving a carte-blanche exemption here. Many charts and graphs have one or two key points that could, in fact, be added to something as simple as an alt text: alt="Graph shows 12.2% increase in HIV seroconversion in gay males 18 to 24, 1996 to 2001". Even severely complex illustrations require at least a structural placeholder, like alt="Hubble photograph of Jupiter, its rings, and its satellites".

Its true that genuinely equal access to the information embodied in complex illustrations can be unattainable. These are exceptional cases, but they do come up.

Useful links:

• National Braille Associations recommended practices for converting illustrations into accessible forms
• PopChart by Corda attempts to automatically write long descriptions of (numerical) graphs

Deaf-blind

by gmhowell (26755)

Text-to-speech works fine for blind people (mostly). Deaf people can see most Web content. What the heck are deaf-blind people supposed to do?

One of the joys of Delphi, GEnie, Compuserve, etc. is that the discussion boards worked fine with simple telnet access, and Braille TTYs. The various Web boards that have supplanted them dont seem like they would work as well (sorry, havent tried any yet; those Braille TTYs aint cheap).

Yes, this is a personal question (see .sig).

I need help with tech solutions for the deaf-blind. Please contact me via E-mail if you have any experience in this.

Well, deaf-blind people are difficult to accommodate. Theyre also rare: Though adequate population numbers are hard to find, perhaps 11,000 deaf-blind people live in the U.S. But in some contexts, the fact that theyre deaf has no bearing on accessibility. Blindness is the issue.

Screen readers (manufacturer list) not only can turn Web sites and computer software into voice, they can also typically output text to Braille displays. (I wouldnt call them Braille TTYs, since those are used to communicate by telephone.) Braille displays are fascinating, rarefied, and costly devices. Tieman, Freedom Scientific, and ALVA are notable manufacturers. Not all that many people use them, in part because not all that many people read Braille (maybe 10% of blind people), though essentially all deaf-blind people read Braille.

Anyway, for a Web site that does not include multimedia, the fact that youre also deaf has no influence on accessibility if youre already blind. For a deaf-blind person using a screen reader with a Braille display, ordinary Web accessibility becomes the issue, though Id say that navigation help becomes much more important there. Experienced speech-output users run speech at superhuman speeds (300 words a minute is not uncommon), meaning you can burn through a page, albeit in serial fashion, pretty quickly. Given that Braille displays provide one or a couple of lines of Braille at a time, its a more time-consuming procedure.

Now, for sites that do contain multimedia, there is no viable option. An obvious course of action (requested by one activist group) would be to combine caption transcripts and audio-description scripts so that one could essentially read a text rendering of a videoclip, but there is no technology that can actually do that yet. (Yet. I have plans.) Combined script-transcripts of this sort have been attempted manually a couple of times (and I mentioned the idea back in 1999), but I dont know of any research on how well it all worked.

Alternative (non-computer) devices

by superflippy

Increasingly, people are using non-computer devices (cell phones, PDAs) to browse Web sites. What alternative devices are disabled people using, and how are they using them in ways Web developers might not have considered (e.g. voice browser in cell phone)?

Im not really up on that topic. The PAC Mate is one such device; its essentially a screen reader without a screen or free-standing computer.

Accessible site, or accessible browser?

by vofka

I am a partially-sighted person, and I have to admit that I do frequently have difficulty with accessibility issues, particularly with large corporate Web sites which all seem to be full-flow multimedia blitzes which require 1600x1200 resolution or higher, and usually override the default browser fonts to make them smaller.

However, there are a number of browsers, such as Mozilla (just one example, Im sure there are others!) which allow the user to zoom the text on a page, to override colour settings etc.

Though it is undoubtedly important for Webmasters to pay great thought to the design of their sites in terms of colour, font size and multimedia content, how much relative importance should be placed on browser design, and the browsers ability to override the design decisions of the creator of a site?

Its important and overlooked. It would be nice if we had a browser that actually supported all of HTML; we dont (no, not even Mozilla). Then it would be nice if CSS1 and CSS2 were fully supported admittedly an onerous task what with the myriad interactions and the various ambiguities in the spec.

At that point, yes, the user customizability in CSS and the many options available in HTML would presumably be up to the user to control. I think its ridiculous that the only really effective way to override a page authors CSS is for you, the harried, humble Web-surfer, to write your own CSS declarations (dont forget !important!) and activate the file in your browser, if thats even possible. This is the sort of thing that should be built into browser preferences, available for easy use. The first time you start up a browser, it should explicitly ask you if you have any accessibility requirements; a lot of people dont even know about what few customization features browsers currently offer.

Ill make another of my analogies. Remember the lack of visual sophistication of accessibility advocates? They want designers to work at their level by providing accessibility, but they never seem to understand that the converse is also true accessibility activists must learn to work at designers level by providing good site design. By the same token, if page authors are expected to use every practical accessibility feature, then browser makers must be expected to support all of them and support them well.

In the immortal words of Comedy Central, Weve upped our standards. Up yours!

See also: User Agent Accessibility Guidelines.

Physical vs. cognitive political clout

by Aquitaine

Dear Mr. Clark,

I am a Web developer for the Program on Employment and Disability at the School of Industrial Labor Relations at Cornell University. Web accessibility is a serious issue for us, and we try to keep abreast of innovative approaches to design so we can find that elusive place where universal accessibility meets intelligent and aesthetically pleasing layout. We recently spoke with Cynthia Waddell (one of 8 authors of Constructing Accessible Web Sites, also out fairly recently) on this subject, but I found her unwilling to commit to anything other than suggestions rather than real technical solutions.

There are two sticky issues that I have encountered. The first is the notion of universal access. Mrs. Waddell indicated that, working with the W3C, she was coming up with a list of Web sites that met Priorities 13 of the W3C WAI and were still aesthetically impressive (she did not have a list ready). As you are no doubt aware, many sites that tout universal access are themselves victims of poor design -- the problem of Yes, its W3C/WAI compliant across the board, but its ugly as sin. Do you believe that a site can have a single interface that is truly universally accessible, or do you believe that sites should have alternate interfaces? (The Web equivalent of Do we have a ramp and stairs or just a ramp?)

Along those lines, it is apparent to me that the accessibility guidelines are designed to be useful in a manner proportional to the lobbying power of disability rights groups. That is to say, blind people and deaf people, although they comprise extraordinarily small percentages of people with disabilities, have an enormous amount of political clout when compared to people with cognitive disorders -- ADD, ADHD, dyslexia, autism, schizo-affective disorder, schizophrenia, et cetera. Because these disability groups lack the considerable power of a strong advocacy group, do you feel that they have been left by the wayside when it comes to Section 508 or WAI? (And do you personally believe that total-WAI compliance is necessary, or just Section 508?)

My apologies for several questions at once, but we take this issue very seriously here and your answers will go a long way to helping us do what we do to better suit the community that ILR serves.

Thanks so much, Samuel W. Knowlton

To answer your first question: A single interface works for most Web sites. You can simply make the site itself intrinsically accessible to most disability groups.

The only alternative the question seems to envisage is specifically custom-designing an alternative interface for disabled users. In other words, a site would exist in two or more predesigned forms. Thats not the only way.

Some work is being done to permit people and the devices they use to specify formats and capabilities they may possess or require. Have a look at Composite Capabilities/Preferences Profiles. It all boils down to semantic markup again. A single HTML page, if marked up properly, could be visited by a plain-Jane browser and displayed in a way thats familiar to nondisabled users; nothing special would happen.

But if you had a CC/PP-compliant browser or other device, and if the page were coded correctly, and if the server understood CC/PP protocols, then the page would automatically reconfigure itself to your needs without the original page authors having to do anything special. In fact, authors could not predict what kind of transformations would occur, nor would they care.

So a few things could happen. If youre totally blind, your page could be rearranged so the search box and content are at the top, with sidebars, navbars, and anything else uninteresting at the end and no images loaded at all. A low-vision person could ask for larger type on content sections and normal-sized type everywhere else, unless a command were issued to blow up, say, a navbar. (There could be continuous interaction between the user and the server.)

XHTML 2.0 might push this concept along a little, what with its section element, but its all still a pipe dream, really.

Now, as to the second question, putting blind and deaf people together in a group claimed to have an enormous amount of political clout is not really applicable to Web accessibility. Deaf people face very few accessibility barriers in using the Web multimedia is pretty much it. Blind people face very large barriers because the Web is a visual medium. Theres a qualitative difference.

Its true that people with cognitive disabilities have been neglected in Web accessibility. Why? Few people in the wider accessibility field have expertise on the topic. The Web Content Accessibility Guidelines 2.0, when its finished, will contain many more provisions for this group.

The qualitative difference remains. It is arguably difficult or impossible to make Web sites most of which are dominated by text genuinely accessible even to certain specific groups with cognitive disabilities. Remedies proposed in the Web Content Accessibility Guidelines 2.0 drafts would not guarantee access for learning-disabled people. Some of those remedies involve adding illustrations (non-text content) to every single page (yes, the Web Accessibility Initiative may issue that requirement) or rewriting the page according to some kind of half-arsed, doctrinaire editing scheme.

There wouldnt be the same jump in accessibility between a noncompliant site and one that meets those guidelines as you would find with, say, visual impairment. Sites would end up being merely less confusing as opposed to not confusing. You might have met the spec, but you could not be sure you had achieved accessibility.

Certain cognitive disabilities do not even require accommodation online.

Moreover, while accessibility for many other disability groups almost never alters the visual appearance of a page (visible skip-navigation links are a counterexample), it could be argued that a page thats truly accessible to people with learning or cognitive disabilities would have to be custom-created by experts. Thats the stark truth involved in achieving high accessibility for this group. You have to alter content as opposed to metadata or presentation. To accommodate other disabilities, you add information, like alt texts; to accommodate certain learning disabilities, you must remove or alter information.

I am in favour of improved accessibility for cognitively-disabled persons, but Ill only support proposals that can be shown to actually make sites accessible to that group. Im also not willing to destroy the Web as we know it ostensibly in order to save it for a disability group whose needs might not even be met in the process.

Nobody has presented credible evidence that current proposals actually will work, and certainly the evidence supporting the current WCAG 2.0 proposals is weak. In other words, if we want to fix this problem, its going to take a lot more work.

And to answer the final question, Section 508 regulations backhandedly incorporate almost all of the Web Content Accessibility Guidelines 1.0, but go beyond the latter in certain respects. Both guideline sets have all sorts of problems, but complying with either of them will assure reasonable accessibility for large numbers of people.

danox writes "Macromedia has finally incorporated some accessibility features into flash, with their latest version flash MX (note that you pretty much need a flash viewer to see this site). Accessibility nazi Joe Clark on A List Apart has written a pretty good critique of the new features and doesn't give macromedia too much praise. Apart from the fact that macromedia has to do this in order to keep the US government as a customer, its a step forward for flash. Just think, it's now possible to write a plugin that will render flash animations as text."

danox writes "Macromedia has finally incorporated some accessibility features into flash, with their latest version flash MX (note that you pretty much need a flash viewer to see this site). Accessibility nazi Joe Clark on A List Apart has written a pretty good critique of the new features and doesn't give macromedia too much praise. Apart from the fact that macromedia has to do this in order to keep the US government as a customer, its a step forward for flash. Just think, it's now possible to write a plugin that will render flash animations as text."

We got a lot of (shall we say) slightly impertinent questions for Web Standards Project co-founder Jeffrey Zeldman, but that's okay. He reads Slashdot and knows the nature of the beast, and he's hard-core enough to give as good as he gets. So set your humor module to high, then sit back and enjoy Mr. Zeldman's (appropriately impertinent) answers to the 12 questions we forwarded to him.

1) Here's my question:
(Score:5, Insightful)
by FascDot Killed My Pr

If you're such a hotshot web designer, why have you committed one of the cardinal sins of web design: Putting an "entry page" that does nothing but suck bandwidth and make it difficult to "back" out of a site?

Jeffrey:

I'll answer this one piece by piece.

"If you're such a hotshot web designer."

Never claimed to be. Roblimo wrote that glowing description. It's not surprising that some of you, who have no idea what I do, were pissed off when those words of high praise took you to a very simple, low-bandwidth, personal site.

I wish Rob had said "Zeldman is a co-founder of The Web Standards Project" (WaSP), and had explained what the WaSP does, maybe even mentioning the role we played in getting Netscape to throw out its old rendering engine and begin building Mozilla around the standards-compliant Gecko core. I'm guessing people would have overlooked my supposed "design sins" or their distaste for the color orange on my personal site if they had a better idea about what I actually do.

For those who don't know, the WaSP organized a petition drive to persuade Netscape to throw out its old rendering engine and build its new browser around Gecko. Then-group-leader George Olsen of WaSP, along with ThunderLizard's Jim Heid, got 2,000 developers to sign the petition. Netscape is a company that listens - at least, for the last two years, it has been listening - and you all know the result: an upcoming browser that is designed to fully comply with HTML 4, CSS-1, the W3C DOM, XML, and EcmaScript.

No disrespect to Roblimo either. I dig the guy. And what he said is true in a sense. I *am* a web designer and writer, and a lot of the work I've done over the past five years *has* gotten imitated, for better or worse. For instance, oddly enough, the original Mozilla.org (http://www.mozilla.org) was copied from the simple HTML-and-CSS layout I did The Web Standards Project (http://www.webstandards.org/): from the technique, to the color palette, to the crude four-pixel black outlines around content areas. Don't bother checking; the new Mozilla layout has evolved away from that original look, though it still bears trace elements of the original design. A lot of you probably do remember the original Mozilla layout. I'm sure when Roblimo saw it, he realized it was copied from http://www.webstandards.org and I think that's the kind of thing he was referring to in his overly kind introduction to my work.

By the way, I wasn't upset by what Mozilla did; I was flattered by it. You may think it is ugly design, though I'm sure that none of you said so to Mozilla because you believe in the project. It's weird to me that the same people who dig Mozilla would be rude in their comments to someone who, at least in a small way, helped influence the direction of that browser, and who also influenced the initial DESIGN of that project, but whatever. I also talk with Microsoft, because the goal of WaSP is to get standards in *all* browsers, and the fact that I talk to engineers at that company may make me evil incarnate in your book. I can deal with that. If we get better browsers, I'll be satisfied.

I do get copied a lot and often those copies are better than the original. In that sense "VIEW SOURCE" functions like "OPEN SOURCE." ;) I am happy when someone takes an idea of mine and makes it better (and their own).

"why have you committed one of the cardinal sins of web design"

I've been designing websites for five years. I don't claim to be a genius and I'm far from the best designer on the planet, but your take on cardinal sins of a profession you do not participate in is about as meaningful as my comments on your programming decisions would be.

You are parroting Jakob Nielsen or some other expert whose work you've read. You haven't read my work on the same subject (no problem) and you don't know my work as a designer (no problem). Just as in programming, design is about decisions. A designer never sins. He/she makes informed decisions. If you get to know the work, you may understand why those decisions were made. If you never bother to engage with the work - if you merely believe that all design must conform with a small set of rules written by one or two people - you don't understand the nature of the thing you are criticizing. Especially if you spend all of five seconds looking at it, and then rush to be the first to post a rant. There are rules of grammar, too, and James Joyce threw them all out. True, I ain't him. But I am me. All designers make decisions, and if the entire web looked like http://www.useit.com I don't think that would be such a great thing. Anything that departs from the look of http://www.useit.com is violating at least a few of Jakob's "rules," and that's the nature of the beast.

"Putting [up] an 'entry page' that does nothing but suck bandwidth and make it difficult to "back" out of a site?"

The bandwidth sucked is exactly 4K. I think you can handle it.

The "entry page" is a temporary placeholder while I rethink the front end of my personal site. Notice the words "temporary," "placeholder," and "personal." The previous front page was navigational in nature, and it is archived at http://www.zeldman.com/mozillatest.html . The name refers to the fact that the page revealed a bug in recent builds of Mozilla. I have left it online so the Mozilla folks can use it to track down and fix that bug, which they are doing now.

Recently, I've been focused on WaSP and A List Apart (http://www.alistapart.com/), a web design magazine and mailing list I co-founded with Brian Platz. The content on my personal site (275+ pages) has not been my most recent focus, so I determined a while back that it was silly to stop the visitor with a primarily navigational page. I should explain that some people visit zeldman.com for entertainment like The Ad Graveyard; a completely different audience visits for web design info, such as the Ask Dr Web tutorial; and so on. To accommodate those very different visitors, I initially had a core page that was navigational. I didn't put real content on page one, because I was accommodating maybe six completely different audiences, and there was nothing in all that content that would appeal to ALL of them. On http://www.alistapart.com/ I start with content on page one, because the audience is more unified.

Even that old navigational page (http://www.zeldman.com/mozillatest.html), with all its rollovers etc., was very low-bandwidth. I recently got to look at it while stuck at an airport in Stockholm. The airport had five Windows boxes sharing one 56K modem. I looked at some of my favorite sites, and they were all crawling onto the screen. I was pleased that my own front page loaded instantly. I design for low bandwidth, which explains why my work rarely looks like that of "such a hot shit designer." Back to the point. I haven't yet figured out how to restructure the front end of my site, so I put up a 4K placeholder with a bone-simple rollover and a 6 second refresh to the single page at my site that I have been focusing on lately.

Now you know why I have a temporary entry page; now you know why it does "nothing" (it is temporary, and what it does is redirect you); and now you know that it does not suck bandwidth.

How it "makes it difficult to 'back' out of the site" is a mystery to me, so I can't comment on that clause in your question. Personally I find database driven pages much harder to navigate and back out of than 4K html pages. And with browsers that suck, frames-based pages can also be tough to navigate. My 4K page is frameless HTML.

2) I have a question:
(Score:4, Insightful)
by Skinka

What's with that small font www.zeldman.com, haven't you read any (web) usability guides?

Jeffrey:

Yes, I've read them, yes I've written on the subject, yes yes yes.

Along with another WaSP member, I helped influence Microsoft to make ALL web text resizable by the user in IE5/Mac for reasons of accessibility and usability, and we are hoping to get the same from Mozilla. (At the moment, this feature is only available in IE5/Mac. It should be in every browser. It's not in the Windows version of IE and it's obviously not in the current version of Navigator.)

Why small fonts? Personal design decision on a personal site. You can enlarge the type in some browsers, not all. That day is coming.

There are methods of CSS that allow you to resize type in *all* browsers.

Why do I often avoid those methods?

Because they are not supported in most "CSS-capable" browsers.

Absolute font-size keywords are broken in Navigator 4 (all platforms) and IE5/Windows.

Percentages and ems are broken in Netscape 4.

Points are meaningless on computer screens, and the reliance on points in Style Sheets is a widespread authoring error.

Until all browsers support standards, designers will be stuck using pixels or FONT SIZE tags. Or simply making no effort at all to control the appearance and size of type on the web page. If this bothers you, join The Web Standards Project.

(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)

Unless you design web sites every day, you have no idea of the compatibility nightmares involved. But in your own work, I'm sure you have plenty of examples of brain-dead decisions by others that force you to use hacks and workarounds. It's the same in web design.

At the moment, the main text at http://www.zeldman.com/coming.html (the one page in all my work that most Slashdotters seem to have looked at) is laid out with ems. This is wonderful, scalable technology. You can easily enlarge or reduce the type in just about any browser.

Except, of course, that it doesn't work at all in most versions of Navigator 4. If you're using Navigator - and you know you are - you will see large ugly type, not the type treatment I intended. Until we have standards, that's just the way it will be.

3) Not to flame, but...
(Score:5, Insightful)
by mr.nobody

I find it hard to ask HTML questions to someone who has committed the cardinal sin of taking away the status bar with JavaScript.

Jeffrey:

Another cardinal sin.

Hmm. Let's see.

The status bar *does* reveal the url of the page it links to - just like an untreated status bar would do. It also provides ADDITIONAL INFORMATION AND COMMENTARY. I guess that's a bad thing. I can't see why, but I guess I'll take your word for it. URL = good, URL + additional information = bad. Because you say so.

The title tag also provides additional information, but Question #12 told me that that was okay, even good. Whew! That's a relief.

4) where's the interview
(Score:4, Interesting)
by geekpress

Jeff, I programmed for a web design company in which design issues totally trumped more practical concerns like download time. (In one case, I was forced to create absurdly complex html tables just so that the designer could get his one-pixel rounded corners on his notecard design.) What do you see as the appropriate balance between aesthetics and practical usability?

P.S. That company is now out of business, thank goodness!

Jeffrey:

I almost always design for low bandwidth.

I was creative director at a web firm and had designed a layout with thin black borders (yes I do this same thing over and over again) for a database driven site that would be creating tables on the fly. The design effect would not render in Navigator, but the page still looked fine in Navigator, even without those little black outlines.

It was possible to FORCE Navigator to display the effect by surrounding every table with an additional, empty table. That is sometimes okay, obviously - I've been doing it since we could begin applying rudimentary styling to tables - but on a large page full of data, it would unnecessarily increase the bandwidth per page, force all browsers to burn cycles as they calculated the appearance of complex table-in-table displays, possibly cause display errors, and completely yoke the content to the presentation, making it that much harder to fix later, when we have better browsers.

So I told the company president it was a usability nightmare and a waste of resources and bandwidth and therefore not worth doing.

He told me to do it anyway.

So I quit my job and started my own company.

Rounded edges, high bandwidth, all that stuff can be fine in the right situations, as long as alternatives are provided and rules of accessibility are respected. Usually I persuade my clients to go in the low-bandwidth direction, and I almost always go low-bandwidth on the noncommercial sites I do (zeldman.com, http://www.webstandards.org/ and http://www.alistapart.com/ ).

But high bandwidth is fine for the right audience. Consider http://www.praystation.com, which is a brilliantly designed site by Joshua Davis. It's amazing work. The audience for that site is primarily Joshua's fellow designers, and most of them have T1 or DSL access. Since the site's goal is to push design as far as it can go on the web, and since the audience is known to have fast connections and a desire to see great design, there is absolutely nothing wrong (and lot right) with the higher-bandwidth road taken by this project.

5) Optimism?
(Score:5, Funny)
by Chalst

How hopeful are you that Microsoft can be coaxed into making IE standards compliant? What exactly do you think Microsoft's motive was in not supporting HTML 4.0 completely?

Jeffrey:

It varies by the hour. Sometimes I think they are going to do this and simply have not committed to it because they're not sure they can pull it off. Sometimes I suspect that as the current market leader (guys with the most users) they think they don't have to bother with this. ("Our way *is* the standard." That kind of thinking.) And sometimes I reckon that they're doing this to fuck up Mozilla. ("You're going to support standards? Well, we have more users. You lose.") I don't *know* what they're thinking, but I suspect that different people there are thinking combinations of all the above.

I do know there are engineers there who are committed to supporting standards. Not only because I've met some of them through my work with WaSP, but also because - in the case of IE5/Mac - they've actually pulled it off. Remember, Microsoft (along with Netscape, Sun, invited experts, etc.) helped come up with these standards in the first place. Why would you design blueprints and then not follow them when you build the house? The engineers who participate in the standards process are committed to complying with standards. Some people in management may not be. Or they may be delaying, for short-sighted competitive reasons, or from fear of committing until they are sure they can do it right.

HTML 4 - the LAST HTML - includes dozens of accessibility improvements, and it is insane for any company not to fully support that. Without full support for HTML 4, millions of web users get hurt. That's morally wrong, and it's also just plain bad for business. I think that in time, all browser companies, including Microsoft, will come to see that. I also think the W3C's recent hiring of a conformance manager (http://xmlhack.com/read.php?item=517) signals that the W3C will soon take a more active role in "helping" companies get with the program, support standards, and stop screwing up developers and web users in a game where everybody - including the browser companies - eventually loses.

6) Balancing Technologies
(Score:5, Insightful)
by Proteus

As you are no doubt aware, the technology that drives web site design is advancing rapidly. However, there are still a lot of users who run older browsers, or prefer to use text-only browsers such as Lynx.

Obviously, one wants to reach as large an audience as possible, but not "lag behind" too far. How do you go about balancing the use of newer technology on a site without alienating users of older software, disabled users, and text-only browsers?

Jeffrey:

Using HTML 4, ALT tags, and the TITLE tag goes a long way toward achieving this goal.

So does using CSS for type, instead of FONT FACE and FONT SIZE tags that yoke content to presentation.

I do both these things, and all the other little things you have to do, for instance with framesets. I think there may be some really old (1996) framesets at zeldman.com where I left out full content inside the noframes tags. I'm cleaning that up as quickly as I can. At ALA http://www.alistapart.com/), wherever I used framesets, I included the full text inside the noframes tags, and I also included TEXT versions of all articles.

The next stage is full separation of content from structure, and that means using HTML 4 and CSS (and eventually, replacing HTML 4 with XHTML; and eventually, migrating to XML).

We can't safely do that yet. Gecko is still in development, Netscape 4 has appalling "support" for CSS, IE5/Windows has better but far from complete support, and the only released browser that gets it right - IE5/Mac - has a 6% market share.

SOON. Not soon enough, but SOON, we will look back on this era of stupidity and laugh. Oh, how we will laugh. This is the TRON era and we are striving to reach the MATRIX era.

7) Reverse scenario question...
(Score:5, Interesting)
by Jonny Royale

Have you ever seen anything come from a browser publisher "extending" a standard (Microsoft, Netscape, other), and thought "Gee, I wish that was in the standard"? Examples?

Jeffrey:

Yes.

LOW SRC was a funky old tag from Netscape (dating back to Netscape 1.1) that allowed you to slip a low-bandwidth image into place, and then have it replaced by the more bandwidth-intensive image when the latter finished downloading. For people with very slow connections, it was a useful hack. It also enabled creative web designers to add a certain amount of "SFX magic" (cough) to even the most primitive pages, viewed by the oldest browsers, under the most adverse conditions. That's gone. Too bad. I miss it.

Because of browser offsets in all released versions of Navigator and most versions of Explorer, I wish the "four horsemen of non-validation" (leftmargin, topmargin marginwidth and marginheight) had made it into HTML 4.0 transitional. We won't need them eventually, but until the browsers are smarter, we still do need them. The W3C is always ahead of what the browsers can deliver, of course; but by discouraging these dumb proprietary tags, the W3C has put us in the position where PAGES THAT WILL NOT WORK without these tags will fail at http://validator.w3.org. That kind of failure discourages developers from building standards-compliant pages. It is a small thing, and it is transitional, but DURING THE TRANSITION, I would have liked to see those four stupid tags get approval with a benevolent sigh.

On the other hand, designers who know what they are doing may include these tags and ignore those validation errors, but don't tell the W3C I said so.

Given the brain-dead way Navigator 4 and IE4/5/Windows handled absolute font size keywords in CSS, I *sometimes* wish font size tags were not discouraged YET. I hate them and hardly ever use them, but (for instance) there's no way to get small type in Linux that is actually READABLE without relying on these dumb old non-standard tags. What I really wish in this case, of course, is that Netscape and Microsoft hadn't fucked up this simple CSS technology. So I take the FONT SIZE tags thing back. Uh, never mind. I just wish Netscape and Microsoft had gotten CSS right the first time.

8) Banners
(Score:5, Interesting)
by TheTomcat

This is only vaguely related to design, but directly related to the web, and functionality.

We all know that banners don't work anymore. The only way a business can profit from banners is to show thousands per day. Most users don't even SEE banners anymore. We avoid them the same way we dig in the couch for the remote when commercials interrupt The Simpsons.

Do you have any suggestions to make future, content-based sites profitable?

Jeffrey:

There are several issues here. One is, a lot of the best work is done as a labor of love, and always will be. Those who need a revenue model before they are willing to even think about working will lose one of the golden opportunities of the web, which is free expression and the building of communities, regardless of financial issues. For instance, Slashdot was born as a community and still is one. Eventually, Slashdot got into a position where it could make money, but Slashdot is true to itself and was not corrupted or changed by any commercial considerations. So it is possible to make a good thing and not blow it when the cash register starts jingling. But a lot of other sites and communities have turned to dreck when money was involved.

We all agree that banners suck - Roblimo even wrote an article for ALA on that subject, back when ALA was just getting launched. With a big enough readership, banners *can* be profitable, as they are at Slashdot. But I agree that most of us just hate 'em.

Sponsorships are another possible means of revenue. "This issue of Webmonkey brought to you by Hewlett-Packard." With an entertaining HP minisite available at the click of a link, for those who care. Kaliber 10000 (http://www.k10k.net) has gotten Apple sponsorship, and all that means is, there's a tiny Apple link in the top right hand corner of the front page. If you click it, you get a popup window with text on why the site's designers like their Macs, and links to some current movies in Apple Quicktime format.

The Cluetrain guys have spoken about this model of corporate sponsorship as well.

I think about it sometimes. For instance, http://www.alistapart.com/ could be "brought to you by" Macromedia or Adobe. But to tell the truth, I don't really pursue this idea because I'm not motivated by money when it comes to creating web content. I simply want to create or choose the right content, and totally control it, and I'm not sanguine that I could do that if I *had* corporate sponsorship. Thinking about it some more is on my to-do list, but it's about 500 layers down in the list. I make enough money designing websites that I don't worry about "revenue models" for my content sites. It is a real issue, though. Just one I haven't bothered with personally, yet.

9) Jeff, your CSS suck
(Score:4, Insightful)
by Nicolas MONNET

I quote from your website:

H1 {font: bold 24px verdana, helvetica, arial, sans-serif; margin-top: 0xp;}
H4 {font: 12px verdana, helvetica, sans-serif; margin-top: 0px; margin-bottom: 10px;}

So why, tell me, WHY did you use PIXELS (px) instead of POINTS (pt), thereby overriding my painfully crafted DPI settings, rendering your all page unviewable on my Linux machine?

Jeffrey:

Refer to the answer to Question 2. Also refer to this Word from the WaSP column:

http://www.webstandards.org/wfw/ieah.html

The best way to style text - and the way the W3C recommends - is to use relative sizes or absolute size keywords.

Both these methods are completely broken in Navigator 4. Totally frickin' useless. Don't shoot the messenger. Netscape agrees, and that's why they threw out their old rendering engine and started from scratch.

And absolute size keywords are stupidly mis-supported in IE4/5 for Windows, where "medium" means large, and "small" means medium.

Faced with this maddening stupidity on the part of browser makers, designers/developers have two choices:

Do not style text at all. Have a nice day.

*OR* rely on pixels, which work in all "CSS-capable" browsers.

I sadly choose the latter until the browsers fully comply with W3C standards.

As to POINTS versus pixels, points are absolutely meaningless on the web, and the fact that they are used by thousands of developers who should know better proves only how little CSS is understood by the development community.

Certain point sizes may work on your platform in your style sheet. That proves that certain point sizes work on your platform in your style sheet. Cross-platform it is not transportable, and points are print-based units of measurement that have no meaningful relationship to the wonderful world of monitor resolution.

For a good discussion of CSS problems, see Todd Fahrner's "Beyond the Font Size Tag: Practical HTML Text and Styling" at http://style.metrius.com/font_size /livetext.html (Unfortunately, even some of *THESE* techniques do not work in more recent versions of Navigator 4.)

In a few months, there will be exactly two browsers that get CSS-1 right: Mozilla/Nav 6 for all platforms, and IE5/Mac which we have now. Since neither has dominant marketshare, developers will still face huge obstacles when trying to do something as SIMPLE and BASIC as size text on the web. Many will stick with pixels, which are the only CSS technique that actually WORKS across browsers and platforms.

In addition to all these nightmarish problems with our browsers, there are special challenges with Linux, because unless Linux users install additional scalable fonts, you can follow all the rules for good CSS, and avoid "problem" font sizes, and still create pages that look jaggy or are unreadable on a lot of people's machines. I worry about this all the time, but I don't have a solution for it. I have actually gone back to using the stupid The way to advance the medium is to get absolute font size keywords and relative font sizes right in CSS, finish implementing HTML 4, and give us the W3C DOM, XML, and EcmaScript. (And then wait two years for users to upgrade.)

10) Pixel based alignment and HTML
(Score:4, Insightful)
by mcelrath

One of the most disturbing trends that I see in web design these days is the trend toward trying to control layout at the pixel level. As HTML (Hypertext Markup) was not intended to be a graphics language, what is your comment on this?

Jeffrey:

Separation of style and content is the way forward.

The problem is the browsers.

When I revised my "Ask Dr Web" tutorial at http://www.zeldman.com/askdrweb/, along with other pages at http://www.zeldman.com/, to use CSS layouts instead of tables, certain versions of Navigator 4 began crashing.

Actually crashing from basic CSS-1.

I wrote about this at A List Apart, ("The Day the Browser Died") and because of this, Netscape invested some time and resources to fixing some of these bugs in Navigator 4. It didn't catch them all, and it didn't catch them in Linux. These bugs will never be fully fixed in Navigator 4, because Netscape is wisely spending its energy to finish the Mozilla browser. Unfortunately, this means that Netscape users will continue to face serious usability hazards throughout the web until Netscape 6 is released ... *OR* it means that developers will continue to use TABLES for layouts for the next two years (as Jakob Nielsen has predicted).

If you look at these pages - http://www.zeldman.com/steal.html or http://www.zeldman.com/icon.html are other examples - you will see that we are talking about extremely BASIC layouts. An expert from the CSS pointers group actually volunteered hours of her time trying alternate combinations of the very basic CSS on those pages to see if she could find ways to stop Netscape from crashing. She could not; neither could I. Netscape did what it could for its 4.0 users, but it can't do anything more until the next generation is released.

On my personal site I made the tough decision to leave these pages as-is. I don't have time to recode them all using tables.

You can agree or disagree with that decision.

Linux folks can either use the Mozilla or Opera betas to navigate those pages in safety and comfort.

It's worth noting that W3C pages also crashed Netscape 4, for the same reason.

What happens when Netscape's browser is this badly damaged? I get hate mail from people who don't understand the issues involved. I also got a letter of thanks from Netscape's Eric Krock, because good companies WANT us to help them find bugs in their software.

As an example of this, many sites (including yours) use font size=1 to acheive a font that is fairly uniform in pixel size across browsers. Anyone with a high-resolution screen will tell you that this is highly annoying, since it results in an almost unreadable font.

See above for the explanation as to why developers are stuck using 1994 technology to support late-1990s browsers. The same questions, the same answers.

The good thing - the ONLY good thing - about the font size tag is that it is user-resizable. The rest of this has been answered above.

Forcing netscape to use a larger font size often destroys the layout of the page. What's worse, some pages use dynamic fonts and other features to force this on the user.

Right, although in some cases it is justified.

As another example, many pages use the table , and layer to specify the exact size in pixels of portions of the page, and then put a little notice at the bottom ("This site best viewed at 800x600") or some such.

Yes, that is usually a bad design decision. Whenever possible, I use what Glenn Davis (WaSP and Project Cool co-founder) calls "liquid" design ... design that reflows to exactly fit the visitor's monitor. That's almost always a better way to go. Examples of my liquid designs include http://www.alistapart.com/, http://www.the-adstore.com, and most of zeldman.com. If you dig long enough in zeldman.com, you'll come upon pages older than the NYC subways, that simply use BAD design ... though at the time, it wasn't all that bad.

Liquid design is not always appropriate but it is generally best.

What are standards groups doing to fix this?

Nothing. The W3C can't make better or more intelligent designers out of people, and neither can the WaSP, whose sole purpose is to agitate for W3C standards in browsers (and eventually in web authoring tools).

We can try to lead by example. http://www.webstandards.org/ is liquid (aside from the front page, which is "semi-liquid" owing to the large low-rez graphic) and it validates.

MEMBERS of standards groups can write articles on the subject and hope that people read them. Of course, if people "can't get past" a 4k splash page, they will not learn about my articles on the subject.

Will I be looking at pages designed for 800x600 (or worse, 640x480) with my 1920x1440 screen forever? Will persons with laptops at 640x480 be unable to read the web soon? Will standards bodies ever require percentage-of-screen width and height specifiers, or even better, implement table width=30ch to specify sizes in relation to the current font size?

Standards bodies can recommend certain authoring practices, and they can develop standards that make such practices possible, but they cannot enforce good authoring.

11) Evaluate Slashdot
(Score:5, Interesting)
by Pseudonymus Bosch

What would you change, what would you add, what would you remove in Slashdot?

Jeffrey:

It's a community and it works. It has achieved visibility, notoriety, and even commercial success without giving an inch. Pretty awesome achievement. What would I change?

Sometimes the longer threads take a long time to load, due to back-end technology, platform and server issues. The technology works better on Linux than it does on my platform of choice (Mac OS) but, hey, that's okay.

I know you want me to comment on the design. Design is subjective. Black backgrounds and teal are not my favorite color scheme (though I used black backgrounds at the 1995 Ad Graveyard (http://www.zeldman.com/ad.html) and the January 1997 Furbo Filters so who am I to talk? The main thing I was trying to do at Furbo was get CSS to work - and to let people know about Craig Hockenberry's and my Furbo Filters, which were the only Photoshop plugins at the time that dealt with the web-safe color palette - at least to our knowledge.)

I might change the color scheme and some other things if Rob Malda went on a crack run and asked me to redesign Slashdot, but that ain't likely to happen. And I think the design of Slashdot is just fine. It focuses you on the breaking stories, allows you to read more (or not), and provides access to almost everything else on the site via small navigation units. In terms of usability it is damn good, and it has plenty of attitude.

Of course, it commits the "cardinal sin" of teal, but I can get past that.

12) Do you agree with Nielsen?
(Score:4, Interesting)
by Pseudonymus Bosch

I have no idea about you and your views, but I have read lots of the Alertbox columns by Jakob Nielsen.

Do you agree with him? Do you disagree? What about?

Jeffrey:

I agree with his comments on oral sex and wearing white after Labor Day.

And I like that he can get $25,000 to talk for an hour. I'll do the same for half that amount.

I also agree with Jakob that most websites should be usable by as many people as possible.

What I have done about that is help found The Web Standards Project, so we can actually achieve that goal instead of using duct tape and lasagna to build sites that work for "most" people. And I try to make my pages accessible in spite of the limitations of current browsers and some of the cross-platform issues discussed above.

If you are interested in my views, you can read them at http://www.alistapart.com/, Adobe.com (here, http://www.adobe.com/we b/columns/zeldman/20000320/main.html, for instance), http://www.webstandards.org/ and of course at http://www.zeldman.com/. If you can get past the 4k splash page.

At least you share the use of TITLE attributes in hyperlinks (a good feature that Slashdot shouldn't chomp away).

Thanks! The reason Slashdot chomps title tags is probably because they are not supported in Netscape yet. They are an important usability feature, and in some browsers they also offer nifty low-grade special effects - along with the opportunity for contextual ampliciation or ironic commentary.

jeffrey

Can't act. Can't sing. Can dance a little.

http://www.zeldman.com
http://www.alistapart.com
http://www.happycog.com
http://www.webstandards.org

We got a lot of (shall we say) slightly impertinent questions for Web Standards Project co-founder Jeffrey Zeldman, but that's okay. He reads Slashdot and knows the nature of the beast, and he's hard-core enough to give as good as he gets. So set your humor module to high, then sit back and enjoy Mr. Zeldman's (appropriately impertinent) answers to the 12 questions we forwarded to him.

1) Here's my question:
(Score:5, Insightful)
by FascDot Killed My Pr

If you're such a hotshot web designer, why have you committed one of the cardinal sins of web design: Putting an "entry page" that does nothing but suck bandwidth and make it difficult to "back" out of a site?

Jeffrey:

I'll answer this one piece by piece.

"If you're such a hotshot web designer."

Never claimed to be. Roblimo wrote that glowing description. It's not surprising that some of you, who have no idea what I do, were pissed off when those words of high praise took you to a very simple, low-bandwidth, personal site.

I wish Rob had said "Zeldman is a co-founder of The Web Standards Project" (WaSP), and had explained what the WaSP does, maybe even mentioning the role we played in getting Netscape to throw out its old rendering engine and begin building Mozilla around the standards-compliant Gecko core. I'm guessing people would have overlooked my supposed "design sins" or their distaste for the color orange on my personal site if they had a better idea about what I actually do.

For those who don't know, the WaSP organized a petition drive to persuade Netscape to throw out its old rendering engine and build its new browser around Gecko. Then-group-leader George Olsen of WaSP, along with ThunderLizard's Jim Heid, got 2,000 developers to sign the petition. Netscape is a company that listens - at least, for the last two years, it has been listening - and you all know the result: an upcoming browser that is designed to fully comply with HTML 4, CSS-1, the W3C DOM, XML, and EcmaScript.

No disrespect to Roblimo either. I dig the guy. And what he said is true in a sense. I *am* a web designer and writer, and a lot of the work I've done over the past five years *has* gotten imitated, for better or worse. For instance, oddly enough, the original Mozilla.org (http://www.mozilla.org) was copied from the simple HTML-and-CSS layout I did The Web Standards Project (http://www.webstandards.org/): from the technique, to the color palette, to the crude four-pixel black outlines around content areas. Don't bother checking; the new Mozilla layout has evolved away from that original look, though it still bears trace elements of the original design. A lot of you probably do remember the original Mozilla layout. I'm sure when Roblimo saw it, he realized it was copied from http://www.webstandards.org and I think that's the kind of thing he was referring to in his overly kind introduction to my work.

By the way, I wasn't upset by what Mozilla did; I was flattered by it. You may think it is ugly design, though I'm sure that none of you said so to Mozilla because you believe in the project. It's weird to me that the same people who dig Mozilla would be rude in their comments to someone who, at least in a small way, helped influence the direction of that browser, and who also influenced the initial DESIGN of that project, but whatever. I also talk with Microsoft, because the goal of WaSP is to get standards in *all* browsers, and the fact that I talk to engineers at that company may make me evil incarnate in your book. I can deal with that. If we get better browsers, I'll be satisfied.

I do get copied a lot and often those copies are better than the original. In that sense "VIEW SOURCE" functions like "OPEN SOURCE." ;) I am happy when someone takes an idea of mine and makes it better (and their own).

"why have you committed one of the cardinal sins of web design"

I've been designing websites for five years. I don't claim to be a genius and I'm far from the best designer on the planet, but your take on cardinal sins of a profession you do not participate in is about as meaningful as my comments on your programming decisions would be.

You are parroting Jakob Nielsen or some other expert whose work you've read. You haven't read my work on the same subject (no problem) and you don't know my work as a designer (no problem). Just as in programming, design is about decisions. A designer never sins. He/she makes informed decisions. If you get to know the work, you may understand why those decisions were made. If you never bother to engage with the work - if you merely believe that all design must conform with a small set of rules written by one or two people - you don't understand the nature of the thing you are criticizing. Especially if you spend all of five seconds looking at it, and then rush to be the first to post a rant. There are rules of grammar, too, and James Joyce threw them all out. True, I ain't him. But I am me. All designers make decisions, and if the entire web looked like http://www.useit.com I don't think that would be such a great thing. Anything that departs from the look of http://www.useit.com is violating at least a few of Jakob's "rules," and that's the nature of the beast.

"Putting [up] an 'entry page' that does nothing but suck bandwidth and make it difficult to "back" out of a site?"

The bandwidth sucked is exactly 4K. I think you can handle it.

The "entry page" is a temporary placeholder while I rethink the front end of my personal site. Notice the words "temporary," "placeholder," and "personal." The previous front page was navigational in nature, and it is archived at http://www.zeldman.com/mozillatest.html . The name refers to the fact that the page revealed a bug in recent builds of Mozilla. I have left it online so the Mozilla folks can use it to track down and fix that bug, which they are doing now.

Recently, I've been focused on WaSP and A List Apart (http://www.alistapart.com/), a web design magazine and mailing list I co-founded with Brian Platz. The content on my personal site (275+ pages) has not been my most recent focus, so I determined a while back that it was silly to stop the visitor with a primarily navigational page. I should explain that some people visit zeldman.com for entertainment like The Ad Graveyard; a completely different audience visits for web design info, such as the Ask Dr Web tutorial; and so on. To accommodate those very different visitors, I initially had a core page that was navigational. I didn't put real content on page one, because I was accommodating maybe six completely different audiences, and there was nothing in all that content that would appeal to ALL of them. On http://www.alistapart.com/ I start with content on page one, because the audience is more unified.

Even that old navigational page (http://www.zeldman.com/mozillatest.html), with all its rollovers etc., was very low-bandwidth. I recently got to look at it while stuck at an airport in Stockholm. The airport had five Windows boxes sharing one 56K modem. I looked at some of my favorite sites, and they were all crawling onto the screen. I was pleased that my own front page loaded instantly. I design for low bandwidth, which explains why my work rarely looks like that of "such a hot shit designer." Back to the point. I haven't yet figured out how to restructure the front end of my site, so I put up a 4K placeholder with a bone-simple rollover and a 6 second refresh to the single page at my site that I have been focusing on lately.

Now you know why I have a temporary entry page; now you know why it does "nothing" (it is temporary, and what it does is redirect you); and now you know that it does not suck bandwidth.

How it "makes it difficult to 'back' out of the site" is a mystery to me, so I can't comment on that clause in your question. Personally I find database driven pages much harder to navigate and back out of than 4K html pages. And with browsers that suck, frames-based pages can also be tough to navigate. My 4K page is frameless HTML.

2) I have a question:
(Score:4, Insightful)
by Skinka

What's with that small font www.zeldman.com, haven't you read any (web) usability guides?

Jeffrey:

Yes, I've read them, yes I've written on the subject, yes yes yes.

Along with another WaSP member, I helped influence Microsoft to make ALL web text resizable by the user in IE5/Mac for reasons of accessibility and usability, and we are hoping to get the same from Mozilla. (At the moment, this feature is only available in IE5/Mac. It should be in every browser. It's not in the Windows version of IE and it's obviously not in the current version of Navigator.)

Why small fonts? Personal design decision on a personal site. You can enlarge the type in some browsers, not all. That day is coming.

There are methods of CSS that allow you to resize type in *all* browsers.

Why do I often avoid those methods?

Because they are not supported in most "CSS-capable" browsers.

Absolute font-size keywords are broken in Navigator 4 (all platforms) and IE5/Windows.

Percentages and ems are broken in Netscape 4.

Points are meaningless on computer screens, and the reliance on points in Style Sheets is a widespread authoring error.

Until all browsers support standards, designers will be stuck using pixels or FONT SIZE tags. Or simply making no effort at all to control the appearance and size of type on the web page. If this bothers you, join The Web Standards Project.

(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)

Unless you design web sites every day, you have no idea of the compatibility nightmares involved. But in your own work, I'm sure you have plenty of examples of brain-dead decisions by others that force you to use hacks and workarounds. It's the same in web design.

At the moment, the main text at http://www.zeldman.com/coming.html (the one page in all my work that most Slashdotters seem to have looked at) is laid out with ems. This is wonderful, scalable technology. You can easily enlarge or reduce the type in just about any browser.

Except, of course, that it doesn't work at all in most versions of Navigator 4. If you're using Navigator - and you know you are - you will see large ugly type, not the type treatment I intended. Until we have standards, that's just the way it will be.

3) Not to flame, but...
(Score:5, Insightful)
by mr.nobody

I find it hard to ask HTML questions to someone who has committed the cardinal sin of taking away the status bar with JavaScript.

Jeffrey:

Another cardinal sin.

Hmm. Let's see.

The status bar *does* reveal the url of the page it links to - just like an untreated status bar would do. It also provides ADDITIONAL INFORMATION AND COMMENTARY. I guess that's a bad thing. I can't see why, but I guess I'll take your word for it. URL = good, URL + additional information = bad. Because you say so.

The title tag also provides additional information, but Question #12 told me that that was okay, even good. Whew! That's a relief.

4) where's the interview
(Score:4, Interesting)
by geekpress

Jeff, I programmed for a web design company in which design issues totally trumped more practical concerns like download time. (In one case, I was forced to create absurdly complex html tables just so that the designer could get his one-pixel rounded corners on his notecard design.) What do you see as the appropriate balance between aesthetics and practical usability?

P.S. That company is now out of business, thank goodness!

Jeffrey:

I almost always design for low bandwidth.

I was creative director at a web firm and had designed a layout with thin black borders (yes I do this same thing over and over again) for a database driven site that would be creating tables on the fly. The design effect would not render in Navigator, but the page still looked fine in Navigator, even without those little black outlines.

It was possible to FORCE Navigator to display the effect by surrounding every table with an additional, empty table. That is sometimes okay, obviously - I've been doing it since we could begin applying rudimentary styling to tables - but on a large page full of data, it would unnecessarily increase the bandwidth per page, force all browsers to burn cycles as they calculated the appearance of complex table-in-table displays, possibly cause display errors, and completely yoke the content to the presentation, making it that much harder to fix later, when we have better browsers.

So I told the company president it was a usability nightmare and a waste of resources and bandwidth and therefore not worth doing.

He told me to do it anyway.

So I quit my job and started my own company.

Rounded edges, high bandwidth, all that stuff can be fine in the right situations, as long as alternatives are provided and rules of accessibility are respected. Usually I persuade my clients to go in the low-bandwidth direction, and I almost always go low-bandwidth on the noncommercial sites I do (zeldman.com, http://www.webstandards.org/ and http://www.alistapart.com/ ).

But high bandwidth is fine for the right audience. Consider http://www.praystation.com, which is a brilliantly designed site by Joshua Davis. It's amazing work. The audience for that site is primarily Joshua's fellow designers, and most of them have T1 or DSL access. Since the site's goal is to push design as far as it can go on the web, and since the audience is known to have fast connections and a desire to see great design, there is absolutely nothing wrong (and lot right) with the higher-bandwidth road taken by this project.

5) Optimism?
(Score:5, Funny)
by Chalst

How hopeful are you that Microsoft can be coaxed into making IE standards compliant? What exactly do you think Microsoft's motive was in not supporting HTML 4.0 completely?

Jeffrey:

It varies by the hour. Sometimes I think they are going to do this and simply have not committed to it because they're not sure they can pull it off. Sometimes I suspect that as the current market leader (guys with the most users) they think they don't have to bother with this. ("Our way *is* the standard." That kind of thinking.) And sometimes I reckon that they're doing this to fuck up Mozilla. ("You're going to support standards? Well, we have more users. You lose.") I don't *know* what they're thinking, but I suspect that different people there are thinking combinations of all the above.

I do know there are engineers there who are committed to supporting standards. Not only because I've met some of them through my work with WaSP, but also because - in the case of IE5/Mac - they've actually pulled it off. Remember, Microsoft (along with Netscape, Sun, invited experts, etc.) helped come up with these standards in the first place. Why would you design blueprints and then not follow them when you build the house? The engineers who participate in the standards process are committed to complying with standards. Some people in management may not be. Or they may be delaying, for short-sighted competitive reasons, or from fear of committing until they are sure they can do it right.

HTML 4 - the LAST HTML - includes dozens of accessibility improvements, and it is insane for any company not to fully support that. Without full support for HTML 4, millions of web users get hurt. That's morally wrong, and it's also just plain bad for business. I think that in time, all browser companies, including Microsoft, will come to see that. I also think the W3C's recent hiring of a conformance manager (http://xmlhack.com/read.php?item=517) signals that the W3C will soon take a more active role in "helping" companies get with the program, support standards, and stop screwing up developers and web users in a game where everybody - including the browser companies - eventually loses.

6) Balancing Technologies
(Score:5, Insightful)
by Proteus

As you are no doubt aware, the technology that drives web site design is advancing rapidly. However, there are still a lot of users who run older browsers, or prefer to use text-only browsers such as Lynx.

Obviously, one wants to reach as large an audience as possible, but not "lag behind" too far. How do you go about balancing the use of newer technology on a site without alienating users of older software, disabled users, and text-only browsers?

Jeffrey:

Using HTML 4, ALT tags, and the TITLE tag goes a long way toward achieving this goal.

So does using CSS for type, instead of FONT FACE and FONT SIZE tags that yoke content to presentation.

I do both these things, and all the other little things you have to do, for instance with framesets. I think there may be some really old (1996) framesets at zeldman.com where I left out full content inside the noframes tags. I'm cleaning that up as quickly as I can. At ALA http://www.alistapart.com/), wherever I used framesets, I included the full text inside the noframes tags, and I also included TEXT versions of all articles.

The next stage is full separation of content from structure, and that means using HTML 4 and CSS (and eventually, replacing HTML 4 with XHTML; and eventually, migrating to XML).

We can't safely do that yet. Gecko is still in development, Netscape 4 has appalling "support" for CSS, IE5/Windows has better but far from complete support, and the only released browser that gets it right - IE5/Mac - has a 6% market share.

SOON. Not soon enough, but SOON, we will look back on this era of stupidity and laugh. Oh, how we will laugh. This is the TRON era and we are striving to reach the MATRIX era.

7) Reverse scenario question...
(Score:5, Interesting)
by Jonny Royale

Have you ever seen anything come from a browser publisher "extending" a standard (Microsoft, Netscape, other), and thought "Gee, I wish that was in the standard"? Examples?

Jeffrey:

Yes.

LOW SRC was a funky old tag from Netscape (dating back to Netscape 1.1) that allowed you to slip a low-bandwidth image into place, and then have it replaced by the more bandwidth-intensive image when the latter finished downloading. For people with very slow connections, it was a useful hack. It also enabled creative web designers to add a certain amount of "SFX magic" (cough) to even the most primitive pages, viewed by the oldest browsers, under the most adverse conditions. That's gone. Too bad. I miss it.

Because of browser offsets in all released versions of Navigator and most versions of Explorer, I wish the "four horsemen of non-validation" (leftmargin, topmargin marginwidth and marginheight) had made it into HTML 4.0 transitional. We won't need them eventually, but until the browsers are smarter, we still do need them. The W3C is always ahead of what the browsers can deliver, of course; but by discouraging these dumb proprietary tags, the W3C has put us in the position where PAGES THAT WILL NOT WORK without these tags will fail at http://validator.w3.org. That kind of failure discourages developers from building standards-compliant pages. It is a small thing, and it is transitional, but DURING THE TRANSITION, I would have liked to see those four stupid tags get approval with a benevolent sigh.

On the other hand, designers who know what they are doing may include these tags and ignore those validation errors, but don't tell the W3C I said so.

Given the brain-dead way Navigator 4 and IE4/5/Windows handled absolute font size keywords in CSS, I *sometimes* wish font size tags were not discouraged YET. I hate them and hardly ever use them, but (for instance) there's no way to get small type in Linux that is actually READABLE without relying on these dumb old non-standard tags. What I really wish in this case, of course, is that Netscape and Microsoft hadn't fucked up this simple CSS technology. So I take the FONT SIZE tags thing back. Uh, never mind. I just wish Netscape and Microsoft had gotten CSS right the first time.

8) Banners
(Score:5, Interesting)
by TheTomcat

This is only vaguely related to design, but directly related to the web, and functionality.

We all know that banners don't work anymore. The only way a business can profit from banners is to show thousands per day. Most users don't even SEE banners anymore. We avoid them the same way we dig in the couch for the remote when commercials interrupt The Simpsons.

Do you have any suggestions to make future, content-based sites profitable?

Jeffrey:

There are several issues here. One is, a lot of the best work is done as a labor of love, and always will be. Those who need a revenue model before they are willing to even think about working will lose one of the golden opportunities of the web, which is free expression and the building of communities, regardless of financial issues. For instance, Slashdot was born as a community and still is one. Eventually, Slashdot got into a position where it could make money, but Slashdot is true to itself and was not corrupted or changed by any commercial considerations. So it is possible to make a good thing and not blow it when the cash register starts jingling. But a lot of other sites and communities have turned to dreck when money was involved.

We all agree that banners suck - Roblimo even wrote an article for ALA on that subject, back when ALA was just getting launched. With a big enough readership, banners *can* be profitable, as they are at Slashdot. But I agree that most of us just hate 'em.

Sponsorships are another possible means of revenue. "This issue of Webmonkey brought to you by Hewlett-Packard." With an entertaining HP minisite available at the click of a link, for those who care. Kaliber 10000 (http://www.k10k.net) has gotten Apple sponsorship, and all that means is, there's a tiny Apple link in the top right hand corner of the front page. If you click it, you get a popup window with text on why the site's designers like their Macs, and links to some current movies in Apple Quicktime format.

The Cluetrain guys have spoken about this model of corporate sponsorship as well.

I think about it sometimes. For instance, http://www.alistapart.com/ could be "brought to you by" Macromedia or Adobe. But to tell the truth, I don't really pursue this idea because I'm not motivated by money when it comes to creating web content. I simply want to create or choose the right content, and totally control it, and I'm not sanguine that I could do that if I *had* corporate sponsorship. Thinking about it some more is on my to-do list, but it's about 500 layers down in the list. I make enough money designing websites that I don't worry about "revenue models" for my content sites. It is a real issue, though. Just one I haven't bothered with personally, yet.

9) Jeff, your CSS suck
(Score:4, Insightful)
by Nicolas MONNET

I quote from your website:

H1 {font: bold 24px verdana, helvetica, arial, sans-serif; margin-top: 0xp;}
H4 {font: 12px verdana, helvetica, sans-serif; margin-top: 0px; margin-bottom: 10px;}

So why, tell me, WHY did you use PIXELS (px) instead of POINTS (pt), thereby overriding my painfully crafted DPI settings, rendering your all page unviewable on my Linux machine?

Jeffrey:

Refer to the answer to Question 2. Also refer to this Word from the WaSP column:

http://www.webstandards.org/wfw/ieah.html

The best way to style text - and the way the W3C recommends - is to use relative sizes or absolute size keywords.

Both these methods are completely broken in Navigator 4. Totally frickin' useless. Don't shoot the messenger. Netscape agrees, and that's why they threw out their old rendering engine and started from scratch.

And absolute size keywords are stupidly mis-supported in IE4/5 for Windows, where "medium" means large, and "small" means medium.

Faced with this maddening stupidity on the part of browser makers, designers/developers have two choices:

Do not style text at all. Have a nice day.

*OR* rely on pixels, which work in all "CSS-capable" browsers.

I sadly choose the latter until the browsers fully comply with W3C standards.

As to POINTS versus pixels, points are absolutely meaningless on the web, and the fact that they are used by thousands of developers who should know better proves only how little CSS is understood by the development community.

Certain point sizes may work on your platform in your style sheet. That proves that certain point sizes work on your platform in your style sheet. Cross-platform it is not transportable, and points are print-based units of measurement that have no meaningful relationship to the wonderful world of monitor resolution.

For a good discussion of CSS problems, see Todd Fahrner's "Beyond the Font Size Tag: Practical HTML Text and Styling" at http://style.metrius.com/font_size /livetext.html (Unfortunately, even some of *THESE* techniques do not work in more recent versions of Navigator 4.)

In a few months, there will be exactly two browsers that get CSS-1 right: Mozilla/Nav 6 for all platforms, and IE5/Mac which we have now. Since neither has dominant marketshare, developers will still face huge obstacles when trying to do something as SIMPLE and BASIC as size text on the web. Many will stick with pixels, which are the only CSS technique that actually WORKS across browsers and platforms.

In addition to all these nightmarish problems with our browsers, there are special challenges with Linux, because unless Linux users install additional scalable fonts, you can follow all the rules for good CSS, and avoid "problem" font sizes, and still create pages that look jaggy or are unreadable on a lot of people's machines. I worry about this all the time, but I don't have a solution for it. I have actually gone back to using the stupid The way to advance the medium is to get absolute font size keywords and relative font sizes right in CSS, finish implementing HTML 4, and give us the W3C DOM, XML, and EcmaScript. (And then wait two years for users to upgrade.)

10) Pixel based alignment and HTML
(Score:4, Insightful)
by mcelrath

One of the most disturbing trends that I see in web design these days is the trend toward trying to control layout at the pixel level. As HTML (Hypertext Markup) was not intended to be a graphics language, what is your comment on this?

Jeffrey:

Separation of style and content is the way forward.

The problem is the browsers.

When I revised my "Ask Dr Web" tutorial at http://www.zeldman.com/askdrweb/, along with other pages at http://www.zeldman.com/, to use CSS layouts instead of tables, certain versions of Navigator 4 began crashing.

Actually crashing from basic CSS-1.

I wrote about this at A List Apart, ("The Day the Browser Died") and because of this, Netscape invested some time and resources to fixing some of these bugs in Navigator 4. It didn't catch them all, and it didn't catch them in Linux. These bugs will never be fully fixed in Navigator 4, because Netscape is wisely spending its energy to finish the Mozilla browser. Unfortunately, this means that Netscape users will continue to face serious usability hazards throughout the web until Netscape 6 is released ... *OR* it means that developers will continue to use TABLES for layouts for the next two years (as Jakob Nielsen has predicted).

If you look at these pages - http://www.zeldman.com/steal.html or http://www.zeldman.com/icon.html are other examples - you will see that we are talking about extremely BASIC layouts. An expert from the CSS pointers group actually volunteered hours of her time trying alternate combinations of the very basic CSS on those pages to see if she could find ways to stop Netscape from crashing. She could not; neither could I. Netscape did what it could for its 4.0 users, but it can't do anything more until the next generation is released.

On my personal site I made the tough decision to leave these pages as-is. I don't have time to recode them all using tables.

You can agree or disagree with that decision.

Linux folks can either use the Mozilla or Opera betas to navigate those pages in safety and comfort.

It's worth noting that W3C pages also crashed Netscape 4, for the same reason.

What happens when Netscape's browser is this badly damaged? I get hate mail from people who don't understand the issues involved. I also got a letter of thanks from Netscape's Eric Krock, because good companies WANT us to help them find bugs in their software.

As an example of this, many sites (including yours) use font size=1 to acheive a font that is fairly uniform in pixel size across browsers. Anyone with a high-resolution screen will tell you that this is highly annoying, since it results in an almost unreadable font.

See above for the explanation as to why developers are stuck using 1994 technology to support late-1990s browsers. The same questions, the same answers.

The good thing - the ONLY good thing - about the font size tag is that it is user-resizable. The rest of this has been answered above.

Forcing netscape to use a larger font size often destroys the layout of the page. What's worse, some pages use dynamic fonts and other features to force this on the user.

Right, although in some cases it is justified.

As another example, many pages use the table , and layer to specify the exact size in pixels of portions of the page, and then put a little notice at the bottom ("This site best viewed at 800x600") or some such.

Yes, that is usually a bad design decision. Whenever possible, I use what Glenn Davis (WaSP and Project Cool co-founder) calls "liquid" design ... design that reflows to exactly fit the visitor's monitor. That's almost always a better way to go. Examples of my liquid designs include http://www.alistapart.com/, http://www.the-adstore.com, and most of zeldman.com. If you dig long enough in zeldman.com, you'll come upon pages older than the NYC subways, that simply use BAD design ... though at the time, it wasn't all that bad.

Liquid design is not always appropriate but it is generally best.

What are standards groups doing to fix this?

Nothing. The W3C can't make better or more intelligent designers out of people, and neither can the WaSP, whose sole purpose is to agitate for W3C standards in browsers (and eventually in web authoring tools).

We can try to lead by example. http://www.webstandards.org/ is liquid (aside from the front page, which is "semi-liquid" owing to the large low-rez graphic) and it validates.

MEMBERS of standards groups can write articles on the subject and hope that people read them. Of course, if people "can't get past" a 4k splash page, they will not learn about my articles on the subject.

Will I be looking at pages designed for 800x600 (or worse, 640x480) with my 1920x1440 screen forever? Will persons with laptops at 640x480 be unable to read the web soon? Will standards bodies ever require percentage-of-screen width and height specifiers, or even better, implement table width=30ch to specify sizes in relation to the current font size?

Standards bodies can recommend certain authoring practices, and they can develop standards that make such practices possible, but they cannot enforce good authoring.

11) Evaluate Slashdot
(Score:5, Interesting)
by Pseudonymus Bosch

What would you change, what would you add, what would you remove in Slashdot?

Jeffrey:

It's a community and it works. It has achieved visibility, notoriety, and even commercial success without giving an inch. Pretty awesome achievement. What would I change?

Sometimes the longer threads take a long time to load, due to back-end technology, platform and server issues. The technology works better on Linux than it does on my platform of choice (Mac OS) but, hey, that's okay.

I know you want me to comment on the design. Design is subjective. Black backgrounds and teal are not my favorite color scheme (though I used black backgrounds at the 1995 Ad Graveyard (http://www.zeldman.com/ad.html) and the January 1997 Furbo Filters so who am I to talk? The main thing I was trying to do at Furbo was get CSS to work - and to let people know about Craig Hockenberry's and my Furbo Filters, which were the only Photoshop plugins at the time that dealt with the web-safe color palette - at least to our knowledge.)

I might change the color scheme and some other things if Rob Malda went on a crack run and asked me to redesign Slashdot, but that ain't likely to happen. And I think the design of Slashdot is just fine. It focuses you on the breaking stories, allows you to read more (or not), and provides access to almost everything else on the site via small navigation units. In terms of usability it is damn good, and it has plenty of attitude.

Of course, it commits the "cardinal sin" of teal, but I can get past that.

12) Do you agree with Nielsen?
(Score:4, Interesting)
by Pseudonymus Bosch

I have no idea about you and your views, but I have read lots of the Alertbox columns by Jakob Nielsen.

Do you agree with him? Do you disagree? What about?

Jeffrey:

I agree with his comments on oral sex and wearing white after Labor Day.

And I like that he can get $25,000 to talk for an hour. I'll do the same for half that amount.

I also agree with Jakob that most websites should be usable by as many people as possible.

What I have done about that is help found The Web Standards Project, so we can actually achieve that goal instead of using duct tape and lasagna to build sites that work for "most" people. And I try to make my pages accessible in spite of the limitations of current browsers and some of the cross-platform issues discussed above.

If you are interested in my views, you can read them at http://www.alistapart.com/, Adobe.com (here, http://www.adobe.com/we b/columns/zeldman/20000320/main.html, for instance), http://www.webstandards.org/ and of course at http://www.zeldman.com/. If you can get past the 4k splash page.

At least you share the use of TITLE attributes in hyperlinks (a good feature that Slashdot shouldn't chomp away).

Thanks! The reason Slashdot chomps title tags is probably because they are not supported in Netscape yet. They are an important usability feature, and in some browsers they also offer nifty low-grade special effects - along with the opportunity for contextual ampliciation or ironic commentary.

jeffrey

Can't act. Can't sing. Can dance a little.

http://www.zeldman.com
http://www.alistapart.com
http://www.happycog.com
http://www.webstandards.org

We got a lot of (shall we say) slightly impertinent questions for Web Standards Project co-founder Jeffrey Zeldman, but that's okay. He reads Slashdot and knows the nature of the beast, and he's hard-core enough to give as good as he gets. So set your humor module to high, then sit back and enjoy Mr. Zeldman's (appropriately impertinent) answers to the 12 questions we forwarded to him.

1) Here's my question:
(Score:5, Insightful)
by FascDot Killed My Pr

If you're such a hotshot web designer, why have you committed one of the cardinal sins of web design: Putting an "entry page" that does nothing but suck bandwidth and make it difficult to "back" out of a site?

Jeffrey:

I'll answer this one piece by piece.

"If you're such a hotshot web designer."

Never claimed to be. Roblimo wrote that glowing description. It's not surprising that some of you, who have no idea what I do, were pissed off when those words of high praise took you to a very simple, low-bandwidth, personal site.

I wish Rob had said "Zeldman is a co-founder of The Web Standards Project" (WaSP), and had explained what the WaSP does, maybe even mentioning the role we played in getting Netscape to throw out its old rendering engine and begin building Mozilla around the standards-compliant Gecko core. I'm guessing people would have overlooked my supposed "design sins" or their distaste for the color orange on my personal site if they had a better idea about what I actually do.

For those who don't know, the WaSP organized a petition drive to persuade Netscape to throw out its old rendering engine and build its new browser around Gecko. Then-group-leader George Olsen of WaSP, along with ThunderLizard's Jim Heid, got 2,000 developers to sign the petition. Netscape is a company that listens - at least, for the last two years, it has been listening - and you all know the result: an upcoming browser that is designed to fully comply with HTML 4, CSS-1, the W3C DOM, XML, and EcmaScript.

No disrespect to Roblimo either. I dig the guy. And what he said is true in a sense. I *am* a web designer and writer, and a lot of the work I've done over the past five years *has* gotten imitated, for better or worse. For instance, oddly enough, the original Mozilla.org (http://www.mozilla.org) was copied from the simple HTML-and-CSS layout I did The Web Standards Project (http://www.webstandards.org/): from the technique, to the color palette, to the crude four-pixel black outlines around content areas. Don't bother checking; the new Mozilla layout has evolved away from that original look, though it still bears trace elements of the original design. A lot of you probably do remember the original Mozilla layout. I'm sure when Roblimo saw it, he realized it was copied from http://www.webstandards.org and I think that's the kind of thing he was referring to in his overly kind introduction to my work.

By the way, I wasn't upset by what Mozilla did; I was flattered by it. You may think it is ugly design, though I'm sure that none of you said so to Mozilla because you believe in the project. It's weird to me that the same people who dig Mozilla would be rude in their comments to someone who, at least in a small way, helped influence the direction of that browser, and who also influenced the initial DESIGN of that project, but whatever. I also talk with Microsoft, because the goal of WaSP is to get standards in *all* browsers, and the fact that I talk to engineers at that company may make me evil incarnate in your book. I can deal with that. If we get better browsers, I'll be satisfied.

I do get copied a lot and often those copies are better than the original. In that sense "VIEW SOURCE" functions like "OPEN SOURCE." ;) I am happy when someone takes an idea of mine and makes it better (and their own).

"why have you committed one of the cardinal sins of web design"

I've been designing websites for five years. I don't claim to be a genius and I'm far from the best designer on the planet, but your take on cardinal sins of a profession you do not participate in is about as meaningful as my comments on your programming decisions would be.

You are parroting Jakob Nielsen or some other expert whose work you've read. You haven't read my work on the same subject (no problem) and you don't know my work as a designer (no problem). Just as in programming, design is about decisions. A designer never sins. He/she makes informed decisions. If you get to know the work, you may understand why those decisions were made. If you never bother to engage with the work - if you merely believe that all design must conform with a small set of rules written by one or two people - you don't understand the nature of the thing you are criticizing. Especially if you spend all of five seconds looking at it, and then rush to be the first to post a rant. There are rules of grammar, too, and James Joyce threw them all out. True, I ain't him. But I am me. All designers make decisions, and if the entire web looked like http://www.useit.com I don't think that would be such a great thing. Anything that departs from the look of http://www.useit.com is violating at least a few of Jakob's "rules," and that's the nature of the beast.

"Putting [up] an 'entry page' that does nothing but suck bandwidth and make it difficult to "back" out of a site?"

The bandwidth sucked is exactly 4K. I think you can handle it.

The "entry page" is a temporary placeholder while I rethink the front end of my personal site. Notice the words "temporary," "placeholder," and "personal." The previous front page was navigational in nature, and it is archived at http://www.zeldman.com/mozillatest.html . The name refers to the fact that the page revealed a bug in recent builds of Mozilla. I have left it online so the Mozilla folks can use it to track down and fix that bug, which they are doing now.

Recently, I've been focused on WaSP and A List Apart (http://www.alistapart.com/), a web design magazine and mailing list I co-founded with Brian Platz. The content on my personal site (275+ pages) has not been my most recent focus, so I determined a while back that it was silly to stop the visitor with a primarily navigational page. I should explain that some people visit zeldman.com for entertainment like The Ad Graveyard; a completely different audience visits for web design info, such as the Ask Dr Web tutorial; and so on. To accommodate those very different visitors, I initially had a core page that was navigational. I didn't put real content on page one, because I was accommodating maybe six completely different audiences, and there was nothing in all that content that would appeal to ALL of them. On http://www.alistapart.com/ I start with content on page one, because the audience is more unified.

Even that old navigational page (http://www.zeldman.com/mozillatest.html), with all its rollovers etc., was very low-bandwidth. I recently got to look at it while stuck at an airport in Stockholm. The airport had five Windows boxes sharing one 56K modem. I looked at some of my favorite sites, and they were all crawling onto the screen. I was pleased that my own front page loaded instantly. I design for low bandwidth, which explains why my work rarely looks like that of "such a hot shit designer." Back to the point. I haven't yet figured out how to restructure the front end of my site, so I put up a 4K placeholder with a bone-simple rollover and a 6 second refresh to the single page at my site that I have been focusing on lately.

Now you know why I have a temporary entry page; now you know why it does "nothing" (it is temporary, and what it does is redirect you); and now you know that it does not suck bandwidth.

How it "makes it difficult to 'back' out of the site" is a mystery to me, so I can't comment on that clause in your question. Personally I find database driven pages much harder to navigate and back out of than 4K html pages. And with browsers that suck, frames-based pages can also be tough to navigate. My 4K page is frameless HTML.

2) I have a question:
(Score:4, Insightful)
by Skinka

What's with that small font www.zeldman.com, haven't you read any (web) usability guides?

Jeffrey:

Yes, I've read them, yes I've written on the subject, yes yes yes.

Along with another WaSP member, I helped influence Microsoft to make ALL web text resizable by the user in IE5/Mac for reasons of accessibility and usability, and we are hoping to get the same from Mozilla. (At the moment, this feature is only available in IE5/Mac. It should be in every browser. It's not in the Windows version of IE and it's obviously not in the current version of Navigator.)

Why small fonts? Personal design decision on a personal site. You can enlarge the type in some browsers, not all. That day is coming.

There are methods of CSS that allow you to resize type in *all* browsers.

Why do I often avoid those methods?

Because they are not supported in most "CSS-capable" browsers.

Absolute font-size keywords are broken in Navigator 4 (all platforms) and IE5/Windows.

Percentages and ems are broken in Netscape 4.

Points are meaningless on computer screens, and the reliance on points in Style Sheets is a widespread authoring error.

Until all browsers support standards, designers will be stuck using pixels or FONT SIZE tags. Or simply making no effort at all to control the appearance and size of type on the web page. If this bothers you, join The Web Standards Project.

(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)

Unless you design web sites every day, you have no idea of the compatibility nightmares involved. But in your own work, I'm sure you have plenty of examples of brain-dead decisions by others that force you to use hacks and workarounds. It's the same in web design.

At the moment, the main text at http://www.zeldman.com/coming.html (the one page in all my work that most Slashdotters seem to have looked at) is laid out with ems. This is wonderful, scalable technology. You can easily enlarge or reduce the type in just about any browser.

Except, of course, that it doesn't work at all in most versions of Navigator 4. If you're using Navigator - and you know you are - you will see large ugly type, not the type treatment I intended. Until we have standards, that's just the way it will be.

3) Not to flame, but...
(Score:5, Insightful)
by mr.nobody

I find it hard to ask HTML questions to someone who has committed the cardinal sin of taking away the status bar with JavaScript.

Jeffrey:

Another cardinal sin.

Hmm. Let's see.

The status bar *does* reveal the url of the page it links to - just like an untreated status bar would do. It also provides ADDITIONAL INFORMATION AND COMMENTARY. I guess that's a bad thing. I can't see why, but I guess I'll take your word for it. URL = good, URL + additional information = bad. Because you say so.

The title tag also provides additional information, but Question #12 told me that that was okay, even good. Whew! That's a relief.

4) where's the interview
(Score:4, Interesting)
by geekpress

Jeff, I programmed for a web design company in which design issues totally trumped more practical concerns like download time. (In one case, I was forced to create absurdly complex html tables just so that the designer could get his one-pixel rounded corners on his notecard design.) What do you see as the appropriate balance between aesthetics and practical usability?

P.S. That company is now out of business, thank goodness!

Jeffrey:

I almost always design for low bandwidth.

I was creative director at a web firm and had designed a layout with thin black borders (yes I do this same thing over and over again) for a database driven site that would be creating tables on the fly. The design effect would not render in Navigator, but the page still looked fine in Navigator, even without those little black outlines.

It was possible to FORCE Navigator to display the effect by surrounding every table with an additional, empty table. That is sometimes okay, obviously - I've been doing it since we could begin applying rudimentary styling to tables - but on a large page full of data, it would unnecessarily increase the bandwidth per page, force all browsers to burn cycles as they calculated the appearance of complex table-in-table displays, possibly cause display errors, and completely yoke the content to the presentation, making it that much harder to fix later, when we have better browsers.

So I told the company president it was a usability nightmare and a waste of resources and bandwidth and therefore not worth doing.

He told me to do it anyway.

So I quit my job and started my own company.

Rounded edges, high bandwidth, all that stuff can be fine in the right situations, as long as alternatives are provided and rules of accessibility are respected. Usually I persuade my clients to go in the low-bandwidth direction, and I almost always go low-bandwidth on the noncommercial sites I do (zeldman.com, http://www.webstandards.org/ and http://www.alistapart.com/ ).

But high bandwidth is fine for the right audience. Consider http://www.praystation.com, which is a brilliantly designed site by Joshua Davis. It's amazing work. The audience for that site is primarily Joshua's fellow designers, and most of them have T1 or DSL access. Since the site's goal is to push design as far as it can go on the web, and since the audience is known to have fast connections and a desire to see great design, there is absolutely nothing wrong (and lot right) with the higher-bandwidth road taken by this project.

5) Optimism?
(Score:5, Funny)
by Chalst

How hopeful are you that Microsoft can be coaxed into making IE standards compliant? What exactly do you think Microsoft's motive was in not supporting HTML 4.0 completely?

Jeffrey:

It varies by the hour. Sometimes I think they are going to do this and simply have not committed to it because they're not sure they can pull it off. Sometimes I suspect that as the current market leader (guys with the most users) they think they don't have to bother with this. ("Our way *is* the standard." That kind of thinking.) And sometimes I reckon that they're doing this to fuck up Mozilla. ("You're going to support standards? Well, we have more users. You lose.") I don't *know* what they're thinking, but I suspect that different people there are thinking combinations of all the above.

I do know there are engineers there who are committed to supporting standards. Not only because I've met some of them through my work with WaSP, but also because - in the case of IE5/Mac - they've actually pulled it off. Remember, Microsoft (along with Netscape, Sun, invited experts, etc.) helped come up with these standards in the first place. Why would you design blueprints and then not follow them when you build the house? The engineers who participate in the standards process are committed to complying with standards. Some people in management may not be. Or they may be delaying, for short-sighted competitive reasons, or from fear of committing until they are sure they can do it right.

HTML 4 - the LAST HTML - includes dozens of accessibility improvements, and it is insane for any company not to fully support that. Without full support for HTML 4, millions of web users get hurt. That's morally wrong, and it's also just plain bad for business. I think that in time, all browser companies, including Microsoft, will come to see that. I also think the W3C's recent hiring of a conformance manager (http://xmlhack.com/read.php?item=517) signals that the W3C will soon take a more active role in "helping" companies get with the program, support standards, and stop screwing up developers and web users in a game where everybody - including the browser companies - eventually loses.

6) Balancing Technologies
(Score:5, Insightful)
by Proteus

As you are no doubt aware, the technology that drives web site design is advancing rapidly. However, there are still a lot of users who run older browsers, or prefer to use text-only browsers such as Lynx.

Obviously, one wants to reach as large an audience as possible, but not "lag behind" too far. How do you go about balancing the use of newer technology on a site without alienating users of older software, disabled users, and text-only browsers?

Jeffrey:

Using HTML 4, ALT tags, and the TITLE tag goes a long way toward achieving this goal.

So does using CSS for type, instead of FONT FACE and FONT SIZE tags that yoke content to presentation.

I do both these things, and all the other little things you have to do, for instance with framesets. I think there may be some really old (1996) framesets at zeldman.com where I left out full content inside the noframes tags. I'm cleaning that up as quickly as I can. At ALA http://www.alistapart.com/), wherever I used framesets, I included the full text inside the noframes tags, and I also included TEXT versions of all articles.

The next stage is full separation of content from structure, and that means using HTML 4 and CSS (and eventually, replacing HTML 4 with XHTML; and eventually, migrating to XML).

We can't safely do that yet. Gecko is still in development, Netscape 4 has appalling "support" for CSS, IE5/Windows has better but far from complete support, and the only released browser that gets it right - IE5/Mac - has a 6% market share.

SOON. Not soon enough, but SOON, we will look back on this era of stupidity and laugh. Oh, how we will laugh. This is the TRON era and we are striving to reach the MATRIX era.

7) Reverse scenario question...
(Score:5, Interesting)
by Jonny Royale

Have you ever seen anything come from a browser publisher "extending" a standard (Microsoft, Netscape, other), and thought "Gee, I wish that was in the standard"? Examples?

Jeffrey:

Yes.

LOW SRC was a funky old tag from Netscape (dating back to Netscape 1.1) that allowed you to slip a low-bandwidth image into place, and then have it replaced by the more bandwidth-intensive image when the latter finished downloading. For people with very slow connections, it was a useful hack. It also enabled creative web designers to add a certain amount of "SFX magic" (cough) to even the most primitive pages, viewed by the oldest browsers, under the most adverse conditions. That's gone. Too bad. I miss it.

Because of browser offsets in all released versions of Navigator and most versions of Explorer, I wish the "four horsemen of non-validation" (leftmargin, topmargin marginwidth and marginheight) had made it into HTML 4.0 transitional. We won't need them eventually, but until the browsers are smarter, we still do need them. The W3C is always ahead of what the browsers can deliver, of course; but by discouraging these dumb proprietary tags, the W3C has put us in the position where PAGES THAT WILL NOT WORK without these tags will fail at http://validator.w3.org. That kind of failure discourages developers from building standards-compliant pages. It is a small thing, and it is transitional, but DURING THE TRANSITION, I would have liked to see those four stupid tags get approval with a benevolent sigh.

On the other hand, designers who know what they are doing may include these tags and ignore those validation errors, but don't tell the W3C I said so.

Given the brain-dead way Navigator 4 and IE4/5/Windows handled absolute font size keywords in CSS, I *sometimes* wish font size tags were not discouraged YET. I hate them and hardly ever use them, but (for instance) there's no way to get small type in Linux that is actually READABLE without relying on these dumb old non-standard tags. What I really wish in this case, of course, is that Netscape and Microsoft hadn't fucked up this simple CSS technology. So I take the FONT SIZE tags thing back. Uh, never mind. I just wish Netscape and Microsoft had gotten CSS right the first time.

8) Banners
(Score:5, Interesting)
by TheTomcat

This is only vaguely related to design, but directly related to the web, and functionality.

We all know that banners don't work anymore. The only way a business can profit from banners is to show thousands per day. Most users don't even SEE banners anymore. We avoid them the same way we dig in the couch for the remote when commercials interrupt The Simpsons.

Do you have any suggestions to make future, content-based sites profitable?

Jeffrey:

There are several issues here. One is, a lot of the best work is done as a labor of love, and always will be. Those who need a revenue model before they are willing to even think about working will lose one of the golden opportunities of the web, which is free expression and the building of communities, regardless of financial issues. For instance, Slashdot was born as a community and still is one. Eventually, Slashdot got into a position where it could make money, but Slashdot is true to itself and was not corrupted or changed by any commercial considerations. So it is possible to make a good thing and not blow it when the cash register starts jingling. But a lot of other sites and communities have turned to dreck when money was involved.

We all agree that banners suck - Roblimo even wrote an article for ALA on that subject, back when ALA was just getting launched. With a big enough readership, banners *can* be profitable, as they are at Slashdot. But I agree that most of us just hate 'em.

Sponsorships are another possible means of revenue. "This issue of Webmonkey brought to you by Hewlett-Packard." With an entertaining HP minisite available at the click of a link, for those who care. Kaliber 10000 (http://www.k10k.net) has gotten Apple sponsorship, and all that means is, there's a tiny Apple link in the top right hand corner of the front page. If you click it, you get a popup window with text on why the site's designers like their Macs, and links to some current movies in Apple Quicktime format.

The Cluetrain guys have spoken about this model of corporate sponsorship as well.

I think about it sometimes. For instance, http://www.alistapart.com/ could be "brought to you by" Macromedia or Adobe. But to tell the truth, I don't really pursue this idea because I'm not motivated by money when it comes to creating web content. I simply want to create or choose the right content, and totally control it, and I'm not sanguine that I could do that if I *had* corporate sponsorship. Thinking about it some more is on my to-do list, but it's about 500 layers down in the list. I make enough money designing websites that I don't worry about "revenue models" for my content sites. It is a real issue, though. Just one I haven't bothered with personally, yet.

9) Jeff, your CSS suck
(Score:4, Insightful)
by Nicolas MONNET

I quote from your website:

H1 {font: bold 24px verdana, helvetica, arial, sans-serif; margin-top: 0xp;}
H4 {font: 12px verdana, helvetica, sans-serif; margin-top: 0px; margin-bottom: 10px;}

So why, tell me, WHY did you use PIXELS (px) instead of POINTS (pt), thereby overriding my painfully crafted DPI settings, rendering your all page unviewable on my Linux machine?

Jeffrey:

Refer to the answer to Question 2. Also refer to this Word from the WaSP column:

http://www.webstandards.org/wfw/ieah.html

The best way to style text - and the way the W3C recommends - is to use relative sizes or absolute size keywords.

Both these methods are completely broken in Navigator 4. Totally frickin' useless. Don't shoot the messenger. Netscape agrees, and that's why they threw out their old rendering engine and started from scratch.

And absolute size keywords are stupidly mis-supported in IE4/5 for Windows, where "medium" means large, and "small" means medium.

Faced with this maddening stupidity on the part of browser makers, designers/developers have two choices:

Do not style text at all. Have a nice day.

*OR* rely on pixels, which work in all "CSS-capable" browsers.

I sadly choose the latter until the browsers fully comply with W3C standards.

As to POINTS versus pixels, points are absolutely meaningless on the web, and the fact that they are used by thousands of developers who should know better proves only how little CSS is understood by the development community.

Certain point sizes may work on your platform in your style sheet. That proves that certain point sizes work on your platform in your style sheet. Cross-platform it is not transportable, and points are print-based units of measurement that have no meaningful relationship to the wonderful world of monitor resolution.

For a good discussion of CSS problems, see Todd Fahrner's "Beyond the Font Size Tag: Practical HTML Text and Styling" at http://style.metrius.com/font_size /livetext.html (Unfortunately, even some of *THESE* techniques do not work in more recent versions of Navigator 4.)

In a few months, there will be exactly two browsers that get CSS-1 right: Mozilla/Nav 6 for all platforms, and IE5/Mac which we have now. Since neither has dominant marketshare, developers will still face huge obstacles when trying to do something as SIMPLE and BASIC as size text on the web. Many will stick with pixels, which are the only CSS technique that actually WORKS across browsers and platforms.

In addition to all these nightmarish problems with our browsers, there are special challenges with Linux, because unless Linux users install additional scalable fonts, you can follow all the rules for good CSS, and avoid "problem" font sizes, and still create pages that look jaggy or are unreadable on a lot of people's machines. I worry about this all the time, but I don't have a solution for it. I have actually gone back to using the stupid The way to advance the medium is to get absolute font size keywords and relative font sizes right in CSS, finish implementing HTML 4, and give us the W3C DOM, XML, and EcmaScript. (And then wait two years for users to upgrade.)

10) Pixel based alignment and HTML
(Score:4, Insightful)
by mcelrath

One of the most disturbing trends that I see in web design these days is the trend toward trying to control layout at the pixel level. As HTML (Hypertext Markup) was not intended to be a graphics language, what is your comment on this?

Jeffrey:

Separation of style and content is the way forward.

The problem is the browsers.

When I revised my "Ask Dr Web" tutorial at http://www.zeldman.com/askdrweb/, along with other pages at http://www.zeldman.com/, to use CSS layouts instead of tables, certain versions of Navigator 4 began crashing.

Actually crashing from basic CSS-1.

I wrote about this at A List Apart, ("The Day the Browser Died") and because of this, Netscape invested some time and resources to fixing some of these bugs in Navigator 4. It didn't catch them all, and it didn't catch them in Linux. These bugs will never be fully fixed in Navigator 4, because Netscape is wisely spending its energy to finish the Mozilla browser. Unfortunately, this means that Netscape users will continue to face serious usability hazards throughout the web until Netscape 6 is released ... *OR* it means that developers will continue to use TABLES for layouts for the next two years (as Jakob Nielsen has predicted).

If you look at these pages - http://www.zeldman.com/steal.html or http://www.zeldman.com/icon.html are other examples - you will see that we are talking about extremely BASIC layouts. An expert from the CSS pointers group actually volunteered hours of her time trying alternate combinations of the very basic CSS on those pages to see if she could find ways to stop Netscape from crashing. She could not; neither could I. Netscape did what it could for its 4.0 users, but it can't do anything more until the next generation is released.

On my personal site I made the tough decision to leave these pages as-is. I don't have time to recode them all using tables.

You can agree or disagree with that decision.

Linux folks can either use the Mozilla or Opera betas to navigate those pages in safety and comfort.

It's worth noting that W3C pages also crashed Netscape 4, for the same reason.

What happens when Netscape's browser is this badly damaged? I get hate mail from people who don't understand the issues involved. I also got a letter of thanks from Netscape's Eric Krock, because good companies WANT us to help them find bugs in their software.

As an example of this, many sites (including yours) use font size=1 to acheive a font that is fairly uniform in pixel size across browsers. Anyone with a high-resolution screen will tell you that this is highly annoying, since it results in an almost unreadable font.

See above for the explanation as to why developers are stuck using 1994 technology to support late-1990s browsers. The same questions, the same answers.

The good thing - the ONLY good thing - about the font size tag is that it is user-resizable. The rest of this has been answered above.

Forcing netscape to use a larger font size often destroys the layout of the page. What's worse, some pages use dynamic fonts and other features to force this on the user.

Right, although in some cases it is justified.

As another example, many pages use the table , and layer to specify the exact size in pixels of portions of the page, and then put a little notice at the bottom ("This site best viewed at 800x600") or some such.

Yes, that is usually a bad design decision. Whenever possible, I use what Glenn Davis (WaSP and Project Cool co-founder) calls "liquid" design ... design that reflows to exactly fit the visitor's monitor. That's almost always a better way to go. Examples of my liquid designs include http://www.alistapart.com/, http://www.the-adstore.com, and most of zeldman.com. If you dig long enough in zeldman.com, you'll come upon pages older than the NYC subways, that simply use BAD design ... though at the time, it wasn't all that bad.

Liquid design is not always appropriate but it is generally best.

What are standards groups doing to fix this?

Nothing. The W3C can't make better or more intelligent designers out of people, and neither can the WaSP, whose sole purpose is to agitate for W3C standards in browsers (and eventually in web authoring tools).

We can try to lead by example. http://www.webstandards.org/ is liquid (aside from the front page, which is "semi-liquid" owing to the large low-rez graphic) and it validates.

MEMBERS of standards groups can write articles on the subject and hope that people read them. Of course, if people "can't get past" a 4k splash page, they will not learn about my articles on the subject.

Will I be looking at pages designed for 800x600 (or worse, 640x480) with my 1920x1440 screen forever? Will persons with laptops at 640x480 be unable to read the web soon? Will standards bodies ever require percentage-of-screen width and height specifiers, or even better, implement table width=30ch to specify sizes in relation to the current font size?

Standards bodies can recommend certain authoring practices, and they can develop standards that make such practices possible, but they cannot enforce good authoring.

11) Evaluate Slashdot
(Score:5, Interesting)
by Pseudonymus Bosch

What would you change, what would you add, what would you remove in Slashdot?

Jeffrey:

It's a community and it works. It has achieved visibility, notoriety, and even commercial success without giving an inch. Pretty awesome achievement. What would I change?

Sometimes the longer threads take a long time to load, due to back-end technology, platform and server issues. The technology works better on Linux than it does on my platform of choice (Mac OS) but, hey, that's okay.

I know you want me to comment on the design. Design is subjective. Black backgrounds and teal are not my favorite color scheme (though I used black backgrounds at the 1995 Ad Graveyard (http://www.zeldman.com/ad.html) and the January 1997 Furbo Filters so who am I to talk? The main thing I was trying to do at Furbo was get CSS to work - and to let people know about Craig Hockenberry's and my Furbo Filters, which were the only Photoshop plugins at the time that dealt with the web-safe color palette - at least to our knowledge.)

I might change the color scheme and some other things if Rob Malda went on a crack run and asked me to redesign Slashdot, but that ain't likely to happen. And I think the design of Slashdot is just fine. It focuses you on the breaking stories, allows you to read more (or not), and provides access to almost everything else on the site via small navigation units. In terms of usability it is damn good, and it has plenty of attitude.

Of course, it commits the "cardinal sin" of teal, but I can get past that.

12) Do you agree with Nielsen?
(Score:4, Interesting)
by Pseudonymus Bosch

I have no idea about you and your views, but I have read lots of the Alertbox columns by Jakob Nielsen.

Do you agree with him? Do you disagree? What about?

Jeffrey:

I agree with his comments on oral sex and wearing white after Labor Day.

And I like that he can get $25,000 to talk for an hour. I'll do the same for half that amount.

I also agree with Jakob that most websites should be usable by as many people as possible.

What I have done about that is help found The Web Standards Project, so we can actually achieve that goal instead of using duct tape and lasagna to build sites that work for "most" people. And I try to make my pages accessible in spite of the limitations of current browsers and some of the cross-platform issues discussed above.

If you are interested in my views, you can read them at http://www.alistapart.com/, Adobe.com (here, http://www.adobe.com/we b/columns/zeldman/20000320/main.html, for instance), http://www.webstandards.org/ and of course at http://www.zeldman.com/. If you can get past the 4k splash page.

At least you share the use of TITLE attributes in hyperlinks (a good feature that Slashdot shouldn't chomp away).

Thanks! The reason Slashdot chomps title tags is probably because they are not supported in Netscape yet. They are an important usability feature, and in some browsers they also offer nifty low-grade special effects - along with the opportunity for contextual ampliciation or ironic commentary.

jeffrey

Can't act. Can't sing. Can dance a little.

http://www.zeldman.com
http://www.alistapart.com
http://www.happycog.com
http://www.webstandards.org

We got a lot of (shall we say) slightly impertinent questions for Web Standards Project co-founder Jeffrey Zeldman, but that's okay. He reads Slashdot and knows the nature of the beast, and he's hard-core enough to give as good as he gets. So set your humor module to high, then sit back and enjoy Mr. Zeldman's (appropriately impertinent) answers to the 12 questions we forwarded to him.

1) Here's my question:
(Score:5, Insightful)
by FascDot Killed My Pr

If you're such a hotshot web designer, why have you committed one of the cardinal sins of web design: Putting an "entry page" that does nothing but suck bandwidth and make it difficult to "back" out of a site?

Jeffrey:

I'll answer this one piece by piece.

"If you're such a hotshot web designer."

Never claimed to be. Roblimo wrote that glowing description. It's not surprising that some of you, who have no idea what I do, were pissed off when those words of high praise took you to a very simple, low-bandwidth, personal site.

I wish Rob had said "Zeldman is a co-founder of The Web Standards Project" (WaSP), and had explained what the WaSP does, maybe even mentioning the role we played in getting Netscape to throw out its old rendering engine and begin building Mozilla around the standards-compliant Gecko core. I'm guessing people would have overlooked my supposed "design sins" or their distaste for the color orange on my personal site if they had a better idea about what I actually do.

For those who don't know, the WaSP organized a petition drive to persuade Netscape to throw out its old rendering engine and build its new browser around Gecko. Then-group-leader George Olsen of WaSP, along with ThunderLizard's Jim Heid, got 2,000 developers to sign the petition. Netscape is a company that listens - at least, for the last two years, it has been listening - and you all know the result: an upcoming browser that is designed to fully comply with HTML 4, CSS-1, the W3C DOM, XML, and EcmaScript.

No disrespect to Roblimo either. I dig the guy. And what he said is true in a sense. I *am* a web designer and writer, and a lot of the work I've done over the past five years *has* gotten imitated, for better or worse. For instance, oddly enough, the original Mozilla.org (http://www.mozilla.org) was copied from the simple HTML-and-CSS layout I did The Web Standards Project (http://www.webstandards.org/): from the technique, to the color palette, to the crude four-pixel black outlines around content areas. Don't bother checking; the new Mozilla layout has evolved away from that original look, though it still bears trace elements of the original design. A lot of you probably do remember the original Mozilla layout. I'm sure when Roblimo saw it, he realized it was copied from http://www.webstandards.org and I think that's the kind of thing he was referring to in his overly kind introduction to my work.

By the way, I wasn't upset by what Mozilla did; I was flattered by it. You may think it is ugly design, though I'm sure that none of you said so to Mozilla because you believe in the project. It's weird to me that the same people who dig Mozilla would be rude in their comments to someone who, at least in a small way, helped influence the direction of that browser, and who also influenced the initial DESIGN of that project, but whatever. I also talk with Microsoft, because the goal of WaSP is to get standards in *all* browsers, and the fact that I talk to engineers at that company may make me evil incarnate in your book. I can deal with that. If we get better browsers, I'll be satisfied.

I do get copied a lot and often those copies are better than the original. In that sense "VIEW SOURCE" functions like "OPEN SOURCE." ;) I am happy when someone takes an idea of mine and makes it better (and their own).

"why have you committed one of the cardinal sins of web design"

I've been designing websites for five years. I don't claim to be a genius and I'm far from the best designer on the planet, but your take on cardinal sins of a profession you do not participate in is about as meaningful as my comments on your programming decisions would be.

You are parroting Jakob Nielsen or some other expert whose work you've read. You haven't read my work on the same subject (no problem) and you don't know my work as a designer (no problem). Just as in programming, design is about decisions. A designer never sins. He/she makes informed decisions. If you get to know the work, you may understand why those decisions were made. If you never bother to engage with the work - if you merely believe that all design must conform with a small set of rules written by one or two people - you don't understand the nature of the thing you are criticizing. Especially if you spend all of five seconds looking at it, and then rush to be the first to post a rant. There are rules of grammar, too, and James Joyce threw them all out. True, I ain't him. But I am me. All designers make decisions, and if the entire web looked like http://www.useit.com I don't think that would be such a great thing. Anything that departs from the look of http://www.useit.com is violating at least a few of Jakob's "rules," and that's the nature of the beast.

"Putting [up] an 'entry page' that does nothing but suck bandwidth and make it difficult to "back" out of a site?"

The bandwidth sucked is exactly 4K. I think you can handle it.

The "entry page" is a temporary placeholder while I rethink the front end of my personal site. Notice the words "temporary," "placeholder," and "personal." The previous front page was navigational in nature, and it is archived at http://www.zeldman.com/mozillatest.html . The name refers to the fact that the page revealed a bug in recent builds of Mozilla. I have left it online so the Mozilla folks can use it to track down and fix that bug, which they are doing now.

Recently, I've been focused on WaSP and A List Apart (http://www.alistapart.com/), a web design magazine and mailing list I co-founded with Brian Platz. The content on my personal site (275+ pages) has not been my most recent focus, so I determined a while back that it was silly to stop the visitor with a primarily navigational page. I should explain that some people visit zeldman.com for entertainment like The Ad Graveyard; a completely different audience visits for web design info, such as the Ask Dr Web tutorial; and so on. To accommodate those very different visitors, I initially had a core page that was navigational. I didn't put real content on page one, because I was accommodating maybe six completely different audiences, and there was nothing in all that content that would appeal to ALL of them. On http://www.alistapart.com/ I start with content on page one, because the audience is more unified.

Even that old navigational page (http://www.zeldman.com/mozillatest.html), with all its rollovers etc., was very low-bandwidth. I recently got to look at it while stuck at an airport in Stockholm. The airport had five Windows boxes sharing one 56K modem. I looked at some of my favorite sites, and they were all crawling onto the screen. I was pleased that my own front page loaded instantly. I design for low bandwidth, which explains why my work rarely looks like that of "such a hot shit designer." Back to the point. I haven't yet figured out how to restructure the front end of my site, so I put up a 4K placeholder with a bone-simple rollover and a 6 second refresh to the single page at my site that I have been focusing on lately.

Now you know why I have a temporary entry page; now you know why it does "nothing" (it is temporary, and what it does is redirect you); and now you know that it does not suck bandwidth.

How it "makes it difficult to 'back' out of the site" is a mystery to me, so I can't comment on that clause in your question. Personally I find database driven pages much harder to navigate and back out of than 4K html pages. And with browsers that suck, frames-based pages can also be tough to navigate. My 4K page is frameless HTML.

2) I have a question:
(Score:4, Insightful)
by Skinka

What's with that small font www.zeldman.com, haven't you read any (web) usability guides?

Jeffrey:

Yes, I've read them, yes I've written on the subject, yes yes yes.

Along with another WaSP member, I helped influence Microsoft to make ALL web text resizable by the user in IE5/Mac for reasons of accessibility and usability, and we are hoping to get the same from Mozilla. (At the moment, this feature is only available in IE5/Mac. It should be in every browser. It's not in the Windows version of IE and it's obviously not in the current version of Navigator.)

Why small fonts? Personal design decision on a personal site. You can enlarge the type in some browsers, not all. That day is coming.

There are methods of CSS that allow you to resize type in *all* browsers.

Why do I often avoid those methods?

Because they are not supported in most "CSS-capable" browsers.

Absolute font-size keywords are broken in Navigator 4 (all platforms) and IE5/Windows.

Percentages and ems are broken in Netscape 4.

Points are meaningless on computer screens, and the reliance on points in Style Sheets is a widespread authoring error.

Until all browsers support standards, designers will be stuck using pixels or FONT SIZE tags. Or simply making no effort at all to control the appearance and size of type on the web page. If this bothers you, join The Web Standards Project.

(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)

Unless you design web sites every day, you have no idea of the compatibility nightmares involved. But in your own work, I'm sure you have plenty of examples of brain-dead decisions by others that force you to use hacks and workarounds. It's the same in web design.

At the moment, the main text at http://www.zeldman.com/coming.html (the one page in all my work that most Slashdotters seem to have looked at) is laid out with ems. This is wonderful, scalable technology. You can easily enlarge or reduce the type in just about any browser.

Except, of course, that it doesn't work at all in most versions of Navigator 4. If you're using Navigator - and you know you are - you will see large ugly type, not the type treatment I intended. Until we have standards, that's just the way it will be.

3) Not to flame, but...
(Score:5, Insightful)
by mr.nobody

I find it hard to ask HTML questions to someone who has committed the cardinal sin of taking away the status bar with JavaScript.

Jeffrey:

Another cardinal sin.

Hmm. Let's see.

The status bar *does* reveal the url of the page it links to - just like an untreated status bar would do. It also provides ADDITIONAL INFORMATION AND COMMENTARY. I guess that's a bad thing. I can't see why, but I guess I'll take your word for it. URL = good, URL + additional information = bad. Because you say so.

The title tag also provides additional information, but Question #12 told me that that was okay, even good. Whew! That's a relief.

4) where's the interview
(Score:4, Interesting)
by geekpress

Jeff, I programmed for a web design company in which design issues totally trumped more practical concerns like download time. (In one case, I was forced to create absurdly complex html tables just so that the designer could get his one-pixel rounded corners on his notecard design.) What do you see as the appropriate balance between aesthetics and practical usability?

P.S. That company is now out of business, thank goodness!

Jeffrey:

I almost always design for low bandwidth.

I was creative director at a web firm and had designed a layout with thin black borders (yes I do this same thing over and over again) for a database driven site that would be creating tables on the fly. The design effect would not render in Navigator, but the page still looked fine in Navigator, even without those little black outlines.

It was possible to FORCE Navigator to display the effect by surrounding every table with an additional, empty table. That is sometimes okay, obviously - I've been doing it since we could begin applying rudimentary styling to tables - but on a large page full of data, it would unnecessarily increase the bandwidth per page, force all browsers to burn cycles as they calculated the appearance of complex table-in-table displays, possibly cause display errors, and completely yoke the content to the presentation, making it that much harder to fix later, when we have better browsers.

So I told the company president it was a usability nightmare and a waste of resources and bandwidth and therefore not worth doing.

He told me to do it anyway.

So I quit my job and started my own company.

Rounded edges, high bandwidth, all that stuff can be fine in the right situations, as long as alternatives are provided and rules of accessibility are respected. Usually I persuade my clients to go in the low-bandwidth direction, and I almost always go low-bandwidth on the noncommercial sites I do (zeldman.com, http://www.webstandards.org/ and http://www.alistapart.com/ ).

But high bandwidth is fine for the right audience. Consider http://www.praystation.com, which is a brilliantly designed site by Joshua Davis. It's amazing work. The audience for that site is primarily Joshua's fellow designers, and most of them have T1 or DSL access. Since the site's goal is to push design as far as it can go on the web, and since the audience is known to have fast connections and a desire to see great design, there is absolutely nothing wrong (and lot right) with the higher-bandwidth road taken by this project.

5) Optimism?
(Score:5, Funny)
by Chalst

How hopeful are you that Microsoft can be coaxed into making IE standards compliant? What exactly do you think Microsoft's motive was in not supporting HTML 4.0 completely?

Jeffrey:

It varies by the hour. Sometimes I think they are going to do this and simply have not committed to it because they're not sure they can pull it off. Sometimes I suspect that as the current market leader (guys with the most users) they think they don't have to bother with this. ("Our way *is* the standard." That kind of thinking.) And sometimes I reckon that they're doing this to fuck up Mozilla. ("You're going to support standards? Well, we have more users. You lose.") I don't *know* what they're thinking, but I suspect that different people there are thinking combinations of all the above.

I do know there are engineers there who are committed to supporting standards. Not only because I've met some of them through my work with WaSP, but also because - in the case of IE5/Mac - they've actually pulled it off. Remember, Microsoft (along with Netscape, Sun, invited experts, etc.) helped come up with these standards in the first place. Why would you design blueprints and then not follow them when you build the house? The engineers who participate in the standards process are committed to complying with standards. Some people in management may not be. Or they may be delaying, for short-sighted competitive reasons, or from fear of committing until they are sure they can do it right.

HTML 4 - the LAST HTML - includes dozens of accessibility improvements, and it is insane for any company not to fully support that. Without full support for HTML 4, millions of web users get hurt. That's morally wrong, and it's also just plain bad for business. I think that in time, all browser companies, including Microsoft, will come to see that. I also think the W3C's recent hiring of a conformance manager (http://xmlhack.com/read.php?item=517) signals that the W3C will soon take a more active role in "helping" companies get with the program, support standards, and stop screwing up developers and web users in a game where everybody - including the browser companies - eventually loses.

6) Balancing Technologies
(Score:5, Insightful)
by Proteus

As you are no doubt aware, the technology that drives web site design is advancing rapidly. However, there are still a lot of users who run older browsers, or prefer to use text-only browsers such as Lynx.

Obviously, one wants to reach as large an audience as possible, but not "lag behind" too far. How do you go about balancing the use of newer technology on a site without alienating users of older software, disabled users, and text-only browsers?

Jeffrey:

Using HTML 4, ALT tags, and the TITLE tag goes a long way toward achieving this goal.

So does using CSS for type, instead of FONT FACE and FONT SIZE tags that yoke content to presentation.

I do both these things, and all the other little things you have to do, for instance with framesets. I think there may be some really old (1996) framesets at zeldman.com where I left out full content inside the noframes tags. I'm cleaning that up as quickly as I can. At ALA http://www.alistapart.com/), wherever I used framesets, I included the full text inside the noframes tags, and I also included TEXT versions of all articles.

The next stage is full separation of content from structure, and that means using HTML 4 and CSS (and eventually, replacing HTML 4 with XHTML; and eventually, migrating to XML).

We can't safely do that yet. Gecko is still in development, Netscape 4 has appalling "support" for CSS, IE5/Windows has better but far from complete support, and the only released browser that gets it right - IE5/Mac - has a 6% market share.

SOON. Not soon enough, but SOON, we will look back on this era of stupidity and laugh. Oh, how we will laugh. This is the TRON era and we are striving to reach the MATRIX era.

7) Reverse scenario question...
(Score:5, Interesting)
by Jonny Royale

Have you ever seen anything come from a browser publisher "extending" a standard (Microsoft, Netscape, other), and thought "Gee, I wish that was in the standard"? Examples?

Jeffrey:

Yes.

LOW SRC was a funky old tag from Netscape (dating back to Netscape 1.1) that allowed you to slip a low-bandwidth image into place, and then have it replaced by the more bandwidth-intensive image when the latter finished downloading. For people with very slow connections, it was a useful hack. It also enabled creative web designers to add a certain amount of "SFX magic" (cough) to even the most primitive pages, viewed by the oldest browsers, under the most adverse conditions. That's gone. Too bad. I miss it.

Because of browser offsets in all released versions of Navigator and most versions of Explorer, I wish the "four horsemen of non-validation" (leftmargin, topmargin marginwidth and marginheight) had made it into HTML 4.0 transitional. We won't need them eventually, but until the browsers are smarter, we still do need them. The W3C is always ahead of what the browsers can deliver, of course; but by discouraging these dumb proprietary tags, the W3C has put us in the position where PAGES THAT WILL NOT WORK without these tags will fail at http://validator.w3.org. That kind of failure discourages developers from building standards-compliant pages. It is a small thing, and it is transitional, but DURING THE TRANSITION, I would have liked to see those four stupid tags get approval with a benevolent sigh.

On the other hand, designers who know what they are doing may include these tags and ignore those validation errors, but don't tell the W3C I said so.

Given the brain-dead way Navigator 4 and IE4/5/Windows handled absolute font size keywords in CSS, I *sometimes* wish font size tags were not discouraged YET. I hate them and hardly ever use them, but (for instance) there's no way to get small type in Linux that is actually READABLE without relying on these dumb old non-standard tags. What I really wish in this case, of course, is that Netscape and Microsoft hadn't fucked up this simple CSS technology. So I take the FONT SIZE tags thing back. Uh, never mind. I just wish Netscape and Microsoft had gotten CSS right the first time.

8) Banners
(Score:5, Interesting)
by TheTomcat

This is only vaguely related to design, but directly related to the web, and functionality.

We all know that banners don't work anymore. The only way a business can profit from banners is to show thousands per day. Most users don't even SEE banners anymore. We avoid them the same way we dig in the couch for the remote when commercials interrupt The Simpsons.

Do you have any suggestions to make future, content-based sites profitable?

Jeffrey:

There are several issues here. One is, a lot of the best work is done as a labor of love, and always will be. Those who need a revenue model before they are willing to even think about working will lose one of the golden opportunities of the web, which is free expression and the building of communities, regardless of financial issues. For instance, Slashdot was born as a community and still is one. Eventually, Slashdot got into a position where it could make money, but Slashdot is true to itself and was not corrupted or changed by any commercial considerations. So it is possible to make a good thing and not blow it when the cash register starts jingling. But a lot of other sites and communities have turned to dreck when money was involved.

We all agree that banners suck - Roblimo even wrote an article for ALA on that subject, back when ALA was just getting launched. With a big enough readership, banners *can* be profitable, as they are at Slashdot. But I agree that most of us just hate 'em.

Sponsorships are another possible means of revenue. "This issue of Webmonkey brought to you by Hewlett-Packard." With an entertaining HP minisite available at the click of a link, for those who care. Kaliber 10000 (http://www.k10k.net) has gotten Apple sponsorship, and all that means is, there's a tiny Apple link in the top right hand corner of the front page. If you click it, you get a popup window with text on why the site's designers like their Macs, and links to some current movies in Apple Quicktime format.

The Cluetrain guys have spoken about this model of corporate sponsorship as well.

I think about it sometimes. For instance, http://www.alistapart.com/ could be "brought to you by" Macromedia or Adobe. But to tell the truth, I don't really pursue this idea because I'm not motivated by money when it comes to creating web content. I simply want to create or choose the right content, and totally control it, and I'm not sanguine that I could do that if I *had* corporate sponsorship. Thinking about it some more is on my to-do list, but it's about 500 layers down in the list. I make enough money designing websites that I don't worry about "revenue models" for my content sites. It is a real issue, though. Just one I haven't bothered with personally, yet.

9) Jeff, your CSS suck
(Score:4, Insightful)
by Nicolas MONNET

I quote from your website:

H1 {font: bold 24px verdana, helvetica, arial, sans-serif; margin-top: 0xp;}
H4 {font: 12px verdana, helvetica, sans-serif; margin-top: 0px; margin-bottom: 10px;}

So why, tell me, WHY did you use PIXELS (px) instead of POINTS (pt), thereby overriding my painfully crafted DPI settings, rendering your all page unviewable on my Linux machine?

Jeffrey:

Refer to the answer to Question 2. Also refer to this Word from the WaSP column:

http://www.webstandards.org/wfw/ieah.html

The best way to style text - and the way the W3C recommends - is to use relative sizes or absolute size keywords.

Both these methods are completely broken in Navigator 4. Totally frickin' useless. Don't shoot the messenger. Netscape agrees, and that's why they threw out their old rendering engine and started from scratch.

And absolute size keywords are stupidly mis-supported in IE4/5 for Windows, where "medium" means large, and "small" means medium.

Faced with this maddening stupidity on the part of browser makers, designers/developers have two choices:

Do not style text at all. Have a nice day.

*OR* rely on pixels, which work in all "CSS-capable" browsers.

I sadly choose the latter until the browsers fully comply with W3C standards.

As to POINTS versus pixels, points are absolutely meaningless on the web, and the fact that they are used by thousands of developers who should know better proves only how little CSS is understood by the development community.

Certain point sizes may work on your platform in your style sheet. That proves that certain point sizes work on your platform in your style sheet. Cross-platform it is not transportable, and points are print-based units of measurement that have no meaningful relationship to the wonderful world of monitor resolution.

For a good discussion of CSS problems, see Todd Fahrner's "Beyond the Font Size Tag: Practical HTML Text and Styling" at http://style.metrius.com/font_size /livetext.html (Unfortunately, even some of *THESE* techniques do not work in more recent versions of Navigator 4.)

In a few months, there will be exactly two browsers that get CSS-1 right: Mozilla/Nav 6 for all platforms, and IE5/Mac which we have now. Since neither has dominant marketshare, developers will still face huge obstacles when trying to do something as SIMPLE and BASIC as size text on the web. Many will stick with pixels, which are the only CSS technique that actually WORKS across browsers and platforms.

In addition to all these nightmarish problems with our browsers, there are special challenges with Linux, because unless Linux users install additional scalable fonts, you can follow all the rules for good CSS, and avoid "problem" font sizes, and still create pages that look jaggy or are unreadable on a lot of people's machines. I worry about this all the time, but I don't have a solution for it. I have actually gone back to using the stupid The way to advance the medium is to get absolute font size keywords and relative font sizes right in CSS, finish implementing HTML 4, and give us the W3C DOM, XML, and EcmaScript. (And then wait two years for users to upgrade.)

10) Pixel based alignment and HTML
(Score:4, Insightful)
by mcelrath

One of the most disturbing trends that I see in web design these days is the trend toward trying to control layout at the pixel level. As HTML (Hypertext Markup) was not intended to be a graphics language, what is your comment on this?

Jeffrey:

Separation of style and content is the way forward.

The problem is the browsers.

When I revised my "Ask Dr Web" tutorial at http://www.zeldman.com/askdrweb/, along with other pages at http://www.zeldman.com/, to use CSS layouts instead of tables, certain versions of Navigator 4 began crashing.

Actually crashing from basic CSS-1.

I wrote about this at A List Apart, ("The Day the Browser Died") and because of this, Netscape invested some time and resources to fixing some of these bugs in Navigator 4. It didn't catch them all, and it didn't catch them in Linux. These bugs will never be fully fixed in Navigator 4, because Netscape is wisely spending its energy to finish the Mozilla browser. Unfortunately, this means that Netscape users will continue to face serious usability hazards throughout the web until Netscape 6 is released ... *OR* it means that developers will continue to use TABLES for layouts for the next two years (as Jakob Nielsen has predicted).

If you look at these pages - http://www.zeldman.com/steal.html or http://www.zeldman.com/icon.html are other examples - you will see that we are talking about extremely BASIC layouts. An expert from the CSS pointers group actually volunteered hours of her time trying alternate combinations of the very basic CSS on those pages to see if she could find ways to stop Netscape from crashing. She could not; neither could I. Netscape did what it could for its 4.0 users, but it can't do anything more until the next generation is released.

On my personal site I made the tough decision to leave these pages as-is. I don't have time to recode them all using tables.

You can agree or disagree with that decision.

Linux folks can either use the Mozilla or Opera betas to navigate those pages in safety and comfort.

It's worth noting that W3C pages also crashed Netscape 4, for the same reason.

What happens when Netscape's browser is this badly damaged? I get hate mail from people who don't understand the issues involved. I also got a letter of thanks from Netscape's Eric Krock, because good companies WANT us to help them find bugs in their software.

As an example of this, many sites (including yours) use font size=1 to acheive a font that is fairly uniform in pixel size across browsers. Anyone with a high-resolution screen will tell you that this is highly annoying, since it results in an almost unreadable font.

See above for the explanation as to why developers are stuck using 1994 technology to support late-1990s browsers. The same questions, the same answers.

The good thing - the ONLY good thing - about the font size tag is that it is user-resizable. The rest of this has been answered above.

Forcing netscape to use a larger font size often destroys the layout of the page. What's worse, some pages use dynamic fonts and other features to force this on the user.

Right, although in some cases it is justified.

As another example, many pages use the table , and layer to specify the exact size in pixels of portions of the page, and then put a little notice at the bottom ("This site best viewed at 800x600") or some such.

Yes, that is usually a bad design decision. Whenever possible, I use what Glenn Davis (WaSP and Project Cool co-founder) calls "liquid" design ... design that reflows to exactly fit the visitor's monitor. That's almost always a better way to go. Examples of my liquid designs include http://www.alistapart.com/, http://www.the-adstore.com, and most of zeldman.com. If you dig long enough in zeldman.com, you'll come upon pages older than the NYC subways, that simply use BAD design ... though at the time, it wasn't all that bad.

Liquid design is not always appropriate but it is generally best.

What are standards groups doing to fix this?

Nothing. The W3C can't make better or more intelligent designers out of people, and neither can the WaSP, whose sole purpose is to agitate for W3C standards in browsers (and eventually in web authoring tools).

We can try to lead by example. http://www.webstandards.org/ is liquid (aside from the front page, which is "semi-liquid" owing to the large low-rez graphic) and it validates.

MEMBERS of standards groups can write articles on the subject and hope that people read them. Of course, if people "can't get past" a 4k splash page, they will not learn about my articles on the subject.

Will I be looking at pages designed for 800x600 (or worse, 640x480) with my 1920x1440 screen forever? Will persons with laptops at 640x480 be unable to read the web soon? Will standards bodies ever require percentage-of-screen width and height specifiers, or even better, implement table width=30ch to specify sizes in relation to the current font size?

Standards bodies can recommend certain authoring practices, and they can develop standards that make such practices possible, but they cannot enforce good authoring.

11) Evaluate Slashdot
(Score:5, Interesting)
by Pseudonymus Bosch

What would you change, what would you add, what would you remove in Slashdot?

Jeffrey:

It's a community and it works. It has achieved visibility, notoriety, and even commercial success without giving an inch. Pretty awesome achievement. What would I change?

Sometimes the longer threads take a long time to load, due to back-end technology, platform and server issues. The technology works better on Linux than it does on my platform of choice (Mac OS) but, hey, that's okay.

I know you want me to comment on the design. Design is subjective. Black backgrounds and teal are not my favorite color scheme (though I used black backgrounds at the 1995 Ad Graveyard (http://www.zeldman.com/ad.html) and the January 1997 Furbo Filters so who am I to talk? The main thing I was trying to do at Furbo was get CSS to work - and to let people know about Craig Hockenberry's and my Furbo Filters, which were the only Photoshop plugins at the time that dealt with the web-safe color palette - at least to our knowledge.)

I might change the color scheme and some other things if Rob Malda went on a crack run and asked me to redesign Slashdot, but that ain't likely to happen. And I think the design of Slashdot is just fine. It focuses you on the breaking stories, allows you to read more (or not), and provides access to almost everything else on the site via small navigation units. In terms of usability it is damn good, and it has plenty of attitude.

Of course, it commits the "cardinal sin" of teal, but I can get past that.

12) Do you agree with Nielsen?
(Score:4, Interesting)
by Pseudonymus Bosch

I have no idea about you and your views, but I have read lots of the Alertbox columns by Jakob Nielsen.

Do you agree with him? Do you disagree? What about?

Jeffrey:

I agree with his comments on oral sex and wearing white after Labor Day.

And I like that he can get $25,000 to talk for an hour. I'll do the same for half that amount.

I also agree with Jakob that most websites should be usable by as many people as possible.

What I have done about that is help found The Web Standards Project, so we can actually achieve that goal instead of using duct tape and lasagna to build sites that work for "most" people. And I try to make my pages accessible in spite of the limitations of current browsers and some of the cross-platform issues discussed above.

If you are interested in my views, you can read them at http://www.alistapart.com/, Adobe.com (here, http://www.adobe.com/we b/columns/zeldman/20000320/main.html, for instance), http://www.webstandards.org/ and of course at http://www.zeldman.com/. If you can get past the 4k splash page.

At least you share the use of TITLE attributes in hyperlinks (a good feature that Slashdot shouldn't chomp away).

Thanks! The reason Slashdot chomps title tags is probably because they are not supported in Netscape yet. They are an important usability feature, and in some browsers they also offer nifty low-grade special effects - along with the opportunity for contextual ampliciation or ironic commentary.

jeffrey

Can't act. Can't sing. Can dance a little.

http://www.zeldman.com
http://www.alistapart.com
http://www.happycog.com
http://www.webstandards.org

We got a lot of (shall we say) slightly impertinent questions for Web Standards Project co-founder Jeffrey Zeldman, but that's okay. He reads Slashdot and knows the nature of the beast, and he's hard-core enough to give as good as he gets. So set your humor module to high, then sit back and enjoy Mr. Zeldman's (appropriately impertinent) answers to the 12 questions we forwarded to him.

1) Here's my question:
(Score:5, Insightful)
by FascDot Killed My Pr

If you're such a hotshot web designer, why have you committed one of the cardinal sins of web design: Putting an "entry page" that does nothing but suck bandwidth and make it difficult to "back" out of a site?

Jeffrey:

I'll answer this one piece by piece.

"If you're such a hotshot web designer."

Never claimed to be. Roblimo wrote that glowing description. It's not surprising that some of you, who have no idea what I do, were pissed off when those words of high praise took you to a very simple, low-bandwidth, personal site.

I wish Rob had said "Zeldman is a co-founder of The Web Standards Project" (WaSP), and had explained what the WaSP does, maybe even mentioning the role we played in getting Netscape to throw out its old rendering engine and begin building Mozilla around the standards-compliant Gecko core. I'm guessing people would have overlooked my supposed "design sins" or their distaste for the color orange on my personal site if they had a better idea about what I actually do.

For those who don't know, the WaSP organized a petition drive to persuade Netscape to throw out its old rendering engine and build its new browser around Gecko. Then-group-leader George Olsen of WaSP, along with ThunderLizard's Jim Heid, got 2,000 developers to sign the petition. Netscape is a company that listens - at least, for the last two years, it has been listening - and you all know the result: an upcoming browser that is designed to fully comply with HTML 4, CSS-1, the W3C DOM, XML, and EcmaScript.

No disrespect to Roblimo either. I dig the guy. And what he said is true in a sense. I *am* a web designer and writer, and a lot of the work I've done over the past five years *has* gotten imitated, for better or worse. For instance, oddly enough, the original Mozilla.org (http://www.mozilla.org) was copied from the simple HTML-and-CSS layout I did The Web Standards Project (http://www.webstandards.org/): from the technique, to the color palette, to the crude four-pixel black outlines around content areas. Don't bother checking; the new Mozilla layout has evolved away from that original look, though it still bears trace elements of the original design. A lot of you probably do remember the original Mozilla layout. I'm sure when Roblimo saw it, he realized it was copied from http://www.webstandards.org and I think that's the kind of thing he was referring to in his overly kind introduction to my work.

By the way, I wasn't upset by what Mozilla did; I was flattered by it. You may think it is ugly design, though I'm sure that none of you said so to Mozilla because you believe in the project. It's weird to me that the same people who dig Mozilla would be rude in their comments to someone who, at least in a small way, helped influence the direction of that browser, and who also influenced the initial DESIGN of that project, but whatever. I also talk with Microsoft, because the goal of WaSP is to get standards in *all* browsers, and the fact that I talk to engineers at that company may make me evil incarnate in your book. I can deal with that. If we get better browsers, I'll be satisfied.

I do get copied a lot and often those copies are better than the original. In that sense "VIEW SOURCE" functions like "OPEN SOURCE." ;) I am happy when someone takes an idea of mine and makes it better (and their own).

"why have you committed one of the cardinal sins of web design"

I've been designing websites for five years. I don't claim to be a genius and I'm far from the best designer on the planet, but your take on cardinal sins of a profession you do not participate in is about as meaningful as my comments on your programming decisions would be.

You are parroting Jakob Nielsen or some other expert whose work you've read. You haven't read my work on the same subject (no problem) and you don't know my work as a designer (no problem). Just as in programming, design is about decisions. A designer never sins. He/she makes informed decisions. If you get to know the work, you may understand why those decisions were made. If you never bother to engage with the work - if you merely believe that all design must conform with a small set of rules written by one or two people - you don't understand the nature of the thing you are criticizing. Especially if you spend all of five seconds looking at it, and then rush to be the first to post a rant. There are rules of grammar, too, and James Joyce threw them all out. True, I ain't him. But I am me. All designers make decisions, and if the entire web looked like http://www.useit.com I don't think that would be such a great thing. Anything that departs from the look of http://www.useit.com is violating at least a few of Jakob's "rules," and that's the nature of the beast.

"Putting [up] an 'entry page' that does nothing but suck bandwidth and make it difficult to "back" out of a site?"

The bandwidth sucked is exactly 4K. I think you can handle it.

The "entry page" is a temporary placeholder while I rethink the front end of my personal site. Notice the words "temporary," "placeholder," and "personal." The previous front page was navigational in nature, and it is archived at http://www.zeldman.com/mozillatest.html . The name refers to the fact that the page revealed a bug in recent builds of Mozilla. I have left it online so the Mozilla folks can use it to track down and fix that bug, which they are doing now.

Recently, I've been focused on WaSP and A List Apart (http://www.alistapart.com/), a web design magazine and mailing list I co-founded with Brian Platz. The content on my personal site (275+ pages) has not been my most recent focus, so I determined a while back that it was silly to stop the visitor with a primarily navigational page. I should explain that some people visit zeldman.com for entertainment like The Ad Graveyard; a completely different audience visits for web design info, such as the Ask Dr Web tutorial; and so on. To accommodate those very different visitors, I initially had a core page that was navigational. I didn't put real content on page one, because I was accommodating maybe six completely different audiences, and there was nothing in all that content that would appeal to ALL of them. On http://www.alistapart.com/ I start with content on page one, because the audience is more unified.

Even that old navigational page (http://www.zeldman.com/mozillatest.html), with all its rollovers etc., was very low-bandwidth. I recently got to look at it while stuck at an airport in Stockholm. The airport had five Windows boxes sharing one 56K modem. I looked at some of my favorite sites, and they were all crawling onto the screen. I was pleased that my own front page loaded instantly. I design for low bandwidth, which explains why my work rarely looks like that of "such a hot shit designer." Back to the point. I haven't yet figured out how to restructure the front end of my site, so I put up a 4K placeholder with a bone-simple rollover and a 6 second refresh to the single page at my site that I have been focusing on lately.

Now you know why I have a temporary entry page; now you know why it does "nothing" (it is temporary, and what it does is redirect you); and now you know that it does not suck bandwidth.

How it "makes it difficult to 'back' out of the site" is a mystery to me, so I can't comment on that clause in your question. Personally I find database driven pages much harder to navigate and back out of than 4K html pages. And with browsers that suck, frames-based pages can also be tough to navigate. My 4K page is frameless HTML.

2) I have a question:
(Score:4, Insightful)
by Skinka

What's with that small font www.zeldman.com, haven't you read any (web) usability guides?

Jeffrey:

Yes, I've read them, yes I've written on the subject, yes yes yes.

Along with another WaSP member, I helped influence Microsoft to make ALL web text resizable by the user in IE5/Mac for reasons of accessibility and usability, and we are hoping to get the same from Mozilla. (At the moment, this feature is only available in IE5/Mac. It should be in every browser. It's not in the Windows version of IE and it's obviously not in the current version of Navigator.)

Why small fonts? Personal design decision on a personal site. You can enlarge the type in some browsers, not all. That day is coming.

There are methods of CSS that allow you to resize type in *all* browsers.

Why do I often avoid those methods?

Because they are not supported in most "CSS-capable" browsers.

Absolute font-size keywords are broken in Navigator 4 (all platforms) and IE5/Windows.

Percentages and ems are broken in Netscape 4.

Points are meaningless on computer screens, and the reliance on points in Style Sheets is a widespread authoring error.

Until all browsers support standards, designers will be stuck using pixels or FONT SIZE tags. Or simply making no effort at all to control the appearance and size of type on the web page. If this bothers you, join The Web Standards Project.

(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)

Unless you design web sites every day, you have no idea of the compatibility nightmares involved. But in your own work, I'm sure you have plenty of examples of brain-dead decisions by others that force you to use hacks and workarounds. It's the same in web design.

At the moment, the main text at http://www.zeldman.com/coming.html (the one page in all my work that most Slashdotters seem to have looked at) is laid out with ems. This is wonderful, scalable technology. You can easily enlarge or reduce the type in just about any browser.

Except, of course, that it doesn't work at all in most versions of Navigator 4. If you're using Navigator - and you know you are - you will see large ugly type, not the type treatment I intended. Until we have standards, that's just the way it will be.

3) Not to flame, but...
(Score:5, Insightful)
by mr.nobody

I find it hard to ask HTML questions to someone who has committed the cardinal sin of taking away the status bar with JavaScript.

Jeffrey:

Another cardinal sin.

Hmm. Let's see.

The status bar *does* reveal the url of the page it links to - just like an untreated status bar would do. It also provides ADDITIONAL INFORMATION AND COMMENTARY. I guess that's a bad thing. I can't see why, but I guess I'll take your word for it. URL = good, URL + additional information = bad. Because you say so.

The title tag also provides additional information, but Question #12 told me that that was okay, even good. Whew! That's a relief.

4) where's the interview
(Score:4, Interesting)
by geekpress

Jeff, I programmed for a web design company in which design issues totally trumped more practical concerns like download time. (In one case, I was forced to create absurdly complex html tables just so that the designer could get his one-pixel rounded corners on his notecard design.) What do you see as the appropriate balance between aesthetics and practical usability?

P.S. That company is now out of business, thank goodness!

Jeffrey:

I almost always design for low bandwidth.

I was creative director at a web firm and had designed a layout with thin black borders (yes I do this same thing over and over again) for a database driven site that would be creating tables on the fly. The design effect would not render in Navigator, but the page still looked fine in Navigator, even without those little black outlines.

It was possible to FORCE Navigator to display the effect by surrounding every table with an additional, empty table. That is sometimes okay, obviously - I've been doing it since we could begin applying rudimentary styling to tables - but on a large page full of data, it would unnecessarily increase the bandwidth per page, force all browsers to burn cycles as they calculated the appearance of complex table-in-table displays, possibly cause display errors, and completely yoke the content to the presentation, making it that much harder to fix later, when we have better browsers.

So I told the company president it was a usability nightmare and a waste of resources and bandwidth and therefore not worth doing.

He told me to do it anyway.

So I quit my job and started my own company.

Rounded edges, high bandwidth, all that stuff can be fine in the right situations, as long as alternatives are provided and rules of accessibility are respected. Usually I persuade my clients to go in the low-bandwidth direction, and I almost always go low-bandwidth on the noncommercial sites I do (zeldman.com, http://www.webstandards.org/ and http://www.alistapart.com/ ).

But high bandwidth is fine for the right audience. Consider http://www.praystation.com, which is a brilliantly designed site by Joshua Davis. It's amazing work. The audience for that site is primarily Joshua's fellow designers, and most of them have T1 or DSL access. Since the site's goal is to push design as far as it can go on the web, and since the audience is known to have fast connections and a desire to see great design, there is absolutely nothing wrong (and lot right) with the higher-bandwidth road taken by this project.

5) Optimism?
(Score:5, Funny)
by Chalst

How hopeful are you that Microsoft can be coaxed into making IE standards compliant? What exactly do you think Microsoft's motive was in not supporting HTML 4.0 completely?

Jeffrey:

It varies by the hour. Sometimes I think they are going to do this and simply have not committed to it because they're not sure they can pull it off. Sometimes I suspect that as the current market leader (guys with the most users) they think they don't have to bother with this. ("Our way *is* the standard." That kind of thinking.) And sometimes I reckon that they're doing this to fuck up Mozilla. ("You're going to support standards? Well, we have more users. You lose.") I don't *know* what they're thinking, but I suspect that different people there are thinking combinations of all the above.

I do know there are engineers there who are committed to supporting standards. Not only because I've met some of them through my work with WaSP, but also because - in the case of IE5/Mac - they've actually pulled it off. Remember, Microsoft (along with Netscape, Sun, invited experts, etc.) helped come up with these standards in the first place. Why would you design blueprints and then not follow them when you build the house? The engineers who participate in the standards process are committed to complying with standards. Some people in management may not be. Or they may be delaying, for short-sighted competitive reasons, or from fear of committing until they are sure they can do it right.

HTML 4 - the LAST HTML - includes dozens of accessibility improvements, and it is insane for any company not to fully support that. Without full support for HTML 4, millions of web users get hurt. That's morally wrong, and it's also just plain bad for business. I think that in time, all browser companies, including Microsoft, will come to see that. I also think the W3C's recent hiring of a conformance manager (http://xmlhack.com/read.php?item=517) signals that the W3C will soon take a more active role in "helping" companies get with the program, support standards, and stop screwing up developers and web users in a game where everybody - including the browser companies - eventually loses.

6) Balancing Technologies
(Score:5, Insightful)
by Proteus

As you are no doubt aware, the technology that drives web site design is advancing rapidly. However, there are still a lot of users who run older browsers, or prefer to use text-only browsers such as Lynx.

Obviously, one wants to reach as large an audience as possible, but not "lag behind" too far. How do you go about balancing the use of newer technology on a site without alienating users of older software, disabled users, and text-only browsers?

Jeffrey:

Using HTML 4, ALT tags, and the TITLE tag goes a long way toward achieving this goal.

So does using CSS for type, instead of FONT FACE and FONT SIZE tags that yoke content to presentation.

I do both these things, and all the other little things you have to do, for instance with framesets. I think there may be some really old (1996) framesets at zeldman.com where I left out full content inside the noframes tags. I'm cleaning that up as quickly as I can. At ALA http://www.alistapart.com/), wherever I used framesets, I included the full text inside the noframes tags, and I also included TEXT versions of all articles.

The next stage is full separation of content from structure, and that means using HTML 4 and CSS (and eventually, replacing HTML 4 with XHTML; and eventually, migrating to XML).

We can't safely do that yet. Gecko is still in development, Netscape 4 has appalling "support" for CSS, IE5/Windows has better but far from complete support, and the only released browser that gets it right - IE5/Mac - has a 6% market share.

SOON. Not soon enough, but SOON, we will look back on this era of stupidity and laugh. Oh, how we will laugh. This is the TRON era and we are striving to reach the MATRIX era.

7) Reverse scenario question...
(Score:5, Interesting)
by Jonny Royale

Have you ever seen anything come from a browser publisher "extending" a standard (Microsoft, Netscape, other), and thought "Gee, I wish that was in the standard"? Examples?

Jeffrey:

Yes.

LOW SRC was a funky old tag from Netscape (dating back to Netscape 1.1) that allowed you to slip a low-bandwidth image into place, and then have it replaced by the more bandwidth-intensive image when the latter finished downloading. For people with very slow connections, it was a useful hack. It also enabled creative web designers to add a certain amount of "SFX magic" (cough) to even the most primitive pages, viewed by the oldest browsers, under the most adverse conditions. That's gone. Too bad. I miss it.

Because of browser offsets in all released versions of Navigator and most versions of Explorer, I wish the "four horsemen of non-validation" (leftmargin, topmargin marginwidth and marginheight) had made it into HTML 4.0 transitional. We won't need them eventually, but until the browsers are smarter, we still do need them. The W3C is always ahead of what the browsers can deliver, of course; but by discouraging these dumb proprietary tags, the W3C has put us in the position where PAGES THAT WILL NOT WORK without these tags will fail at http://validator.w3.org. That kind of failure discourages developers from building standards-compliant pages. It is a small thing, and it is transitional, but DURING THE TRANSITION, I would have liked to see those four stupid tags get approval with a benevolent sigh.

On the other hand, designers who know what they are doing may include these tags and ignore those validation errors, but don't tell the W3C I said so.

Given the brain-dead way Navigator 4 and IE4/5/Windows handled absolute font size keywords in CSS, I *sometimes* wish font size tags were not discouraged YET. I hate them and hardly ever use them, but (for instance) there's no way to get small type in Linux that is actually READABLE without relying on these dumb old non-standard tags. What I really wish in this case, of course, is that Netscape and Microsoft hadn't fucked up this simple CSS technology. So I take the FONT SIZE tags thing back. Uh, never mind. I just wish Netscape and Microsoft had gotten CSS right the first time.

8) Banners
(Score:5, Interesting)
by TheTomcat

This is only vaguely related to design, but directly related to the web, and functionality.

We all know that banners don't work anymore. The only way a business can profit from banners is to show thousands per day. Most users don't even SEE banners anymore. We avoid them the same way we dig in the couch for the remote when commercials interrupt The Simpsons.

Do you have any suggestions to make future, content-based sites profitable?

Jeffrey:

There are several issues here. One is, a lot of the best work is done as a labor of love, and always will be. Those who need a revenue model before they are willing to even think about working will lose one of the golden opportunities of the web, which is free expression and the building of communities, regardless of financial issues. For instance, Slashdot was born as a community and still is one. Eventually, Slashdot got into a position where it could make money, but Slashdot is true to itself and was not corrupted or changed by any commercial considerations. So it is possible to make a good thing and not blow it when the cash register starts jingling. But a lot of other sites and communities have turned to dreck when money was involved.

We all agree that banners suck - Roblimo even wrote an article for ALA on that subject, back when ALA was just getting launched. With a big enough readership, banners *can* be profitable, as they are at Slashdot. But I agree that most of us just hate 'em.

Sponsorships are another possible means of revenue. "This issue of Webmonkey brought to you by Hewlett-Packard." With an entertaining HP minisite available at the click of a link, for those who care. Kaliber 10000 (http://www.k10k.net) has gotten Apple sponsorship, and all that means is, there's a tiny Apple link in the top right hand corner of the front page. If you click it, you get a popup window with text on why the site's designers like their Macs, and links to some current movies in Apple Quicktime format.

The Cluetrain guys have spoken about this model of corporate sponsorship as well.

I think about it sometimes. For instance, http://www.alistapart.com/ could be "brought to you by" Macromedia or Adobe. But to tell the truth, I don't really pursue this idea because I'm not motivated by money when it comes to creating web content. I simply want to create or choose the right content, and totally control it, and I'm not sanguine that I could do that if I *had* corporate sponsorship. Thinking about it some more is on my to-do list, but it's about 500 layers down in the list. I make enough money designing websites that I don't worry about "revenue models" for my content sites. It is a real issue, though. Just one I haven't bothered with personally, yet.

9) Jeff, your CSS suck
(Score:4, Insightful)
by Nicolas MONNET

I quote from your website:

H1 {font: bold 24px verdana, helvetica, arial, sans-serif; margin-top: 0xp;}
H4 {font: 12px verdana, helvetica, sans-serif; margin-top: 0px; margin-bottom: 10px;}

So why, tell me, WHY did you use PIXELS (px) instead of POINTS (pt), thereby overriding my painfully crafted DPI settings, rendering your all page unviewable on my Linux machine?

Jeffrey:

Refer to the answer to Question 2. Also refer to this Word from the WaSP column:

http://www.webstandards.org/wfw/ieah.html

The best way to style text - and the way the W3C recommends - is to use relative sizes or absolute size keywords.

Both these methods are completely broken in Navigator 4. Totally frickin' useless. Don't shoot the messenger. Netscape agrees, and that's why they threw out their old rendering engine and started from scratch.

And absolute size keywords are stupidly mis-supported in IE4/5 for Windows, where "medium" means large, and "small" means medium.

Faced with this maddening stupidity on the part of browser makers, designers/developers have two choices:

Do not style text at all. Have a nice day.

*OR* rely on pixels, which work in all "CSS-capable" browsers.

I sadly choose the latter until the browsers fully comply with W3C standards.

As to POINTS versus pixels, points are absolutely meaningless on the web, and the fact that they are used by thousands of developers who should know better proves only how little CSS is understood by the development community.

Certain point sizes may work on your platform in your style sheet. That proves that certain point sizes work on your platform in your style sheet. Cross-platform it is not transportable, and points are print-based units of measurement that have no meaningful relationship to the wonderful world of monitor resolution.

For a good discussion of CSS problems, see Todd Fahrner's "Beyond the Font Size Tag: Practical HTML Text and Styling" at http://style.metrius.com/font_size /livetext.html (Unfortunately, even some of *THESE* techniques do not work in more recent versions of Navigator 4.)

In a few months, there will be exactly two browsers that get CSS-1 right: Mozilla/Nav 6 for all platforms, and IE5/Mac which we have now. Since neither has dominant marketshare, developers will still face huge obstacles when trying to do something as SIMPLE and BASIC as size text on the web. Many will stick with pixels, which are the only CSS technique that actually WORKS across browsers and platforms.

In addition to all these nightmarish problems with our browsers, there are special challenges with Linux, because unless Linux users install additional scalable fonts, you can follow all the rules for good CSS, and avoid "problem" font sizes, and still create pages that look jaggy or are unreadable on a lot of people's machines. I worry about this all the time, but I don't have a solution for it. I have actually gone back to using the stupid The way to advance the medium is to get absolute font size keywords and relative font sizes right in CSS, finish implementing HTML 4, and give us the W3C DOM, XML, and EcmaScript. (And then wait two years for users to upgrade.)

10) Pixel based alignment and HTML
(Score:4, Insightful)
by mcelrath

One of the most disturbing trends that I see in web design these days is the trend toward trying to control layout at the pixel level. As HTML (Hypertext Markup) was not intended to be a graphics language, what is your comment on this?

Jeffrey:

Separation of style and content is the way forward.

The problem is the browsers.

When I revised my "Ask Dr Web" tutorial at http://www.zeldman.com/askdrweb/, along with other pages at http://www.zeldman.com/, to use CSS layouts instead of tables, certain versions of Navigator 4 began crashing.

Actually crashing from basic CSS-1.

I wrote about this at A List Apart, ("The Day the Browser Died") and because of this, Netscape invested some time and resources to fixing some of these bugs in Navigator 4. It didn't catch them all, and it didn't catch them in Linux. These bugs will never be fully fixed in Navigator 4, because Netscape is wisely spending its energy to finish the Mozilla browser. Unfortunately, this means that Netscape users will continue to face serious usability hazards throughout the web until Netscape 6 is released ... *OR* it means that developers will continue to use TABLES for layouts for the next two years (as Jakob Nielsen has predicted).

If you look at these pages - http://www.zeldman.com/steal.html or http://www.zeldman.com/icon.html are other examples - you will see that we are talking about extremely BASIC layouts. An expert from the CSS pointers group actually volunteered hours of her time trying alternate combinations of the very basic CSS on those pages to see if she could find ways to stop Netscape from crashing. She could not; neither could I. Netscape did what it could for its 4.0 users, but it can't do anything more until the next generation is released.

On my personal site I made the tough decision to leave these pages as-is. I don't have time to recode them all using tables.

You can agree or disagree with that decision.

Linux folks can either use the Mozilla or Opera betas to navigate those pages in safety and comfort.

It's worth noting that W3C pages also crashed Netscape 4, for the same reason.

What happens when Netscape's browser is this badly damaged? I get hate mail from people who don't understand the issues involved. I also got a letter of thanks from Netscape's Eric Krock, because good companies WANT us to help them find bugs in their software.

As an example of this, many sites (including yours) use font size=1 to acheive a font that is fairly uniform in pixel size across browsers. Anyone with a high-resolution screen will tell you that this is highly annoying, since it results in an almost unreadable font.

See above for the explanation as to why developers are stuck using 1994 technology to support late-1990s browsers. The same questions, the same answers.

The good thing - the ONLY good thing - about the font size tag is that it is user-resizable. The rest of this has been answered above.

Forcing netscape to use a larger font size often destroys the layout of the page. What's worse, some pages use dynamic fonts and other features to force this on the user.

Right, although in some cases it is justified.

As another example, many pages use the table , and layer to specify the exact size in pixels of portions of the page, and then put a little notice at the bottom ("This site best viewed at 800x600") or some such.

Yes, that is usually a bad design decision. Whenever possible, I use what Glenn Davis (WaSP and Project Cool co-founder) calls "liquid" design ... design that reflows to exactly fit the visitor's monitor. That's almost always a better way to go. Examples of my liquid designs include http://www.alistapart.com/, http://www.the-adstore.com, and most of zeldman.com. If you dig long enough in zeldman.com, you'll come upon pages older than the NYC subways, that simply use BAD design ... though at the time, it wasn't all that bad.

Liquid design is not always appropriate but it is generally best.

What are standards groups doing to fix this?

Nothing. The W3C can't make better or more intelligent designers out of people, and neither can the WaSP, whose sole purpose is to agitate for W3C standards in browsers (and eventually in web authoring tools).

We can try to lead by example. http://www.webstandards.org/ is liquid (aside from the front page, which is "semi-liquid" owing to the large low-rez graphic) and it validates.

MEMBERS of standards groups can write articles on the subject and hope that people read them. Of course, if people "can't get past" a 4k splash page, they will not learn about my articles on the subject.

Will I be looking at pages designed for 800x600 (or worse, 640x480) with my 1920x1440 screen forever? Will persons with laptops at 640x480 be unable to read the web soon? Will standards bodies ever require percentage-of-screen width and height specifiers, or even better, implement table width=30ch to specify sizes in relation to the current font size?

Standards bodies can recommend certain authoring practices, and they can develop standards that make such practices possible, but they cannot enforce good authoring.

11) Evaluate Slashdot
(Score:5, Interesting)
by Pseudonymus Bosch

What would you change, what would you add, what would you remove in Slashdot?

Jeffrey:

It's a community and it works. It has achieved visibility, notoriety, and even commercial success without giving an inch. Pretty awesome achievement. What would I change?

Sometimes the longer threads take a long time to load, due to back-end technology, platform and server issues. The technology works better on Linux than it does on my platform of choice (Mac OS) but, hey, that's okay.

I know you want me to comment on the design. Design is subjective. Black backgrounds and teal are not my favorite color scheme (though I used black backgrounds at the 1995 Ad Graveyard (http://www.zeldman.com/ad.html) and the January 1997 Furbo Filters so who am I to talk? The main thing I was trying to do at Furbo was get CSS to work - and to let people know about Craig Hockenberry's and my Furbo Filters, which were the only Photoshop plugins at the time that dealt with the web-safe color palette - at least to our knowledge.)

I might change the color scheme and some other things if Rob Malda went on a crack run and asked me to redesign Slashdot, but that ain't likely to happen. And I think the design of Slashdot is just fine. It focuses you on the breaking stories, allows you to read more (or not), and provides access to almost everything else on the site via small navigation units. In terms of usability it is damn good, and it has plenty of attitude.

Of course, it commits the "cardinal sin" of teal, but I can get past that.

12) Do you agree with Nielsen?
(Score:4, Interesting)
by Pseudonymus Bosch

I have no idea about you and your views, but I have read lots of the Alertbox columns by Jakob Nielsen.

Do you agree with him? Do you disagree? What about?

Jeffrey:

I agree with his comments on oral sex and wearing white after Labor Day.

And I like that he can get $25,000 to talk for an hour. I'll do the same for half that amount.

I also agree with Jakob that most websites should be usable by as many people as possible.

What I have done about that is help found The Web Standards Project, so we can actually achieve that goal instead of using duct tape and lasagna to build sites that work for "most" people. And I try to make my pages accessible in spite of the limitations of current browsers and some of the cross-platform issues discussed above.

If you are interested in my views, you can read them at http://www.alistapart.com/, Adobe.com (here, http://www.adobe.com/we b/columns/zeldman/20000320/main.html, for instance), http://www.webstandards.org/ and of course at http://www.zeldman.com/. If you can get past the 4k splash page.

At least you share the use of TITLE attributes in hyperlinks (a good feature that Slashdot shouldn't chomp away).

Thanks! The reason Slashdot chomps title tags is probably because they are not supported in Netscape yet. They are an important usability feature, and in some browsers they also offer nifty low-grade special effects - along with the opportunity for contextual ampliciation or ironic commentary.

jeffrey

Can't act. Can't sing. Can dance a little.

http://www.zeldman.com
http://www.alistapart.com
http://www.happycog.com
http://www.webstandards.org

We got a lot of (shall we say) slightly impertinent questions for Web Standards Project co-founder Jeffrey Zeldman, but that's okay. He reads Slashdot and knows the nature of the beast, and he's hard-core enough to give as good as he gets. So set your humor module to high, then sit back and enjoy Mr. Zeldman's (appropriately impertinent) answers to the 12 questions we forwarded to him.

1) Here's my question:
(Score:5, Insightful)
by FascDot Killed My Pr

If you're such a hotshot web designer, why have you committed one of the cardinal sins of web design: Putting an "entry page" that does nothing but suck bandwidth and make it difficult to "back" out of a site?

Jeffrey:

I'll answer this one piece by piece.

"If you're such a hotshot web designer."

Never claimed to be. Roblimo wrote that glowing description. It's not surprising that some of you, who have no idea what I do, were pissed off when those words of high praise took you to a very simple, low-bandwidth, personal site.

I wish Rob had said "Zeldman is a co-founder of The Web Standards Project" (WaSP), and had explained what the WaSP does, maybe even mentioning the role we played in getting Netscape to throw out its old rendering engine and begin building Mozilla around the standards-compliant Gecko core. I'm guessing people would have overlooked my supposed "design sins" or their distaste for the color orange on my personal site if they had a better idea about what I actually do.

For those who don't know, the WaSP organized a petition drive to persuade Netscape to throw out its old rendering engine and build its new browser around Gecko. Then-group-leader George Olsen of WaSP, along with ThunderLizard's Jim Heid, got 2,000 developers to sign the petition. Netscape is a company that listens - at least, for the last two years, it has been listening - and you all know the result: an upcoming browser that is designed to fully comply with HTML 4, CSS-1, the W3C DOM, XML, and EcmaScript.

No disrespect to Roblimo either. I dig the guy. And what he said is true in a sense. I *am* a web designer and writer, and a lot of the work I've done over the past five years *has* gotten imitated, for better or worse. For instance, oddly enough, the original Mozilla.org (http://www.mozilla.org) was copied from the simple HTML-and-CSS layout I did The Web Standards Project (http://www.webstandards.org/): from the technique, to the color palette, to the crude four-pixel black outlines around content areas. Don't bother checking; the new Mozilla layout has evolved away from that original look, though it still bears trace elements of the original design. A lot of you probably do remember the original Mozilla layout. I'm sure when Roblimo saw it, he realized it was copied from http://www.webstandards.org and I think that's the kind of thing he was referring to in his overly kind introduction to my work.

By the way, I wasn't upset by what Mozilla did; I was flattered by it. You may think it is ugly design, though I'm sure that none of you said so to Mozilla because you believe in the project. It's weird to me that the same people who dig Mozilla would be rude in their comments to someone who, at least in a small way, helped influence the direction of that browser, and who also influenced the initial DESIGN of that project, but whatever. I also talk with Microsoft, because the goal of WaSP is to get standards in *all* browsers, and the fact that I talk to engineers at that company may make me evil incarnate in your book. I can deal with that. If we get better browsers, I'll be satisfied.

I do get copied a lot and often those copies are better than the original. In that sense "VIEW SOURCE" functions like "OPEN SOURCE." ;) I am happy when someone takes an idea of mine and makes it better (and their own).

"why have you committed one of the cardinal sins of web design"

I've been designing websites for five years. I don't claim to be a genius and I'm far from the best designer on the planet, but your take on cardinal sins of a profession you do not participate in is about as meaningful as my comments on your programming decisions would be.

You are parroting Jakob Nielsen or some other expert whose work you've read. You haven't read my work on the same subject (no problem) and you don't know my work as a designer (no problem). Just as in programming, design is about decisions. A designer never sins. He/she makes informed decisions. If you get to know the work, you may understand why those decisions were made. If you never bother to engage with the work - if you merely believe that all design must conform with a small set of rules written by one or two people - you don't understand the nature of the thing you are criticizing. Especially if you spend all of five seconds looking at it, and then rush to be the first to post a rant. There are rules of grammar, too, and James Joyce threw them all out. True, I ain't him. But I am me. All designers make decisions, and if the entire web looked like http://www.useit.com I don't think that would be such a great thing. Anything that departs from the look of http://www.useit.com is violating at least a few of Jakob's "rules," and that's the nature of the beast.

"Putting [up] an 'entry page' that does nothing but suck bandwidth and make it difficult to "back" out of a site?"

The bandwidth sucked is exactly 4K. I think you can handle it.

The "entry page" is a temporary placeholder while I rethink the front end of my personal site. Notice the words "temporary," "placeholder," and "personal." The previous front page was navigational in nature, and it is archived at http://www.zeldman.com/mozillatest.html . The name refers to the fact that the page revealed a bug in recent builds of Mozilla. I have left it online so the Mozilla folks can use it to track down and fix that bug, which they are doing now.

Recently, I've been focused on WaSP and A List Apart (http://www.alistapart.com/), a web design magazine and mailing list I co-founded with Brian Platz. The content on my personal site (275+ pages) has not been my most recent focus, so I determined a while back that it was silly to stop the visitor with a primarily navigational page. I should explain that some people visit zeldman.com for entertainment like The Ad Graveyard; a completely different audience visits for web design info, such as the Ask Dr Web tutorial; and so on. To accommodate those very different visitors, I initially had a core page that was navigational. I didn't put real content on page one, because I was accommodating maybe six completely different audiences, and there was nothing in all that content that would appeal to ALL of them. On http://www.alistapart.com/ I start with content on page one, because the audience is more unified.

Even that old navigational page (http://www.zeldman.com/mozillatest.html), with all its rollovers etc., was very low-bandwidth. I recently got to look at it while stuck at an airport in Stockholm. The airport had five Windows boxes sharing one 56K modem. I looked at some of my favorite sites, and they were all crawling onto the screen. I was pleased that my own front page loaded instantly. I design for low bandwidth, which explains why my work rarely looks like that of "such a hot shit designer." Back to the point. I haven't yet figured out how to restructure the front end of my site, so I put up a 4K placeholder with a bone-simple rollover and a 6 second refresh to the single page at my site that I have been focusing on lately.

Now you know why I have a temporary entry page; now you know why it does "nothing" (it is temporary, and what it does is redirect you); and now you know that it does not suck bandwidth.

How it "makes it difficult to 'back' out of the site" is a mystery to me, so I can't comment on that clause in your question. Personally I find database driven pages much harder to navigate and back out of than 4K html pages. And with browsers that suck, frames-based pages can also be tough to navigate. My 4K page is frameless HTML.

2) I have a question:
(Score:4, Insightful)
by Skinka

What's with that small font www.zeldman.com, haven't you read any (web) usability guides?

Jeffrey:

Yes, I've read them, yes I've written on the subject, yes yes yes.

Along with another WaSP member, I helped influence Microsoft to make ALL web text resizable by the user in IE5/Mac for reasons of accessibility and usability, and we are hoping to get the same from Mozilla. (At the moment, this feature is only available in IE5/Mac. It should be in every browser. It's not in the Windows version of IE and it's obviously not in the current version of Navigator.)

Why small fonts? Personal design decision on a personal site. You can enlarge the type in some browsers, not all. That day is coming.

There are methods of CSS that allow you to resize type in *all* browsers.

Why do I often avoid those methods?

Because they are not supported in most "CSS-capable" browsers.

Absolute font-size keywords are broken in Navigator 4 (all platforms) and IE5/Windows.

Percentages and ems are broken in Netscape 4.

Points are meaningless on computer screens, and the reliance on points in Style Sheets is a widespread authoring error.

Until all browsers support standards, designers will be stuck using pixels or FONT SIZE tags. Or simply making no effort at all to control the appearance and size of type on the web page. If this bothers you, join The Web Standards Project.

(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)

Unless you design web sites every day, you have no idea of the compatibility nightmares involved. But in your own work, I'm sure you have plenty of examples of brain-dead decisions by others that force you to use hacks and workarounds. It's the same in web design.

At the moment, the main text at http://www.zeldman.com/coming.html (the one page in all my work that most Slashdotters seem to have looked at) is laid out with ems. This is wonderful, scalable technology. You can easily enlarge or reduce the type in just about any browser.

Except, of course, that it doesn't work at all in most versions of Navigator 4. If you're using Navigator - and you know you are - you will see large ugly type, not the type treatment I intended. Until we have standards, that's just the way it will be.

3) Not to flame, but...
(Score:5, Insightful)
by mr.nobody

I find it hard to ask HTML questions to someone who has committed the cardinal sin of taking away the status bar with JavaScript.

Jeffrey:

Another cardinal sin.

Hmm. Let's see.

The status bar *does* reveal the url of the page it links to - just like an untreated status bar would do. It also provides ADDITIONAL INFORMATION AND COMMENTARY. I guess that's a bad thing. I can't see why, but I guess I'll take your word for it. URL = good, URL + additional information = bad. Because you say so.

The title tag also provides additional information, but Question #12 told me that that was okay, even good. Whew! That's a relief.

4) where's the interview
(Score:4, Interesting)
by geekpress

Jeff, I programmed for a web design company in which design issues totally trumped more practical concerns like download time. (In one case, I was forced to create absurdly complex html tables just so that the designer could get his one-pixel rounded corners on his notecard design.) What do you see as the appropriate balance between aesthetics and practical usability?

P.S. That company is now out of business, thank goodness!

Jeffrey:

I almost always design for low bandwidth.

I was creative director at a web firm and had designed a layout with thin black borders (yes I do this same thing over and over again) for a database driven site that would be creating tables on the fly. The design effect would not render in Navigator, but the page still looked fine in Navigator, even without those little black outlines.

It was possible to FORCE Navigator to display the effect by surrounding every table with an additional, empty table. That is sometimes okay, obviously - I've been doing it since we could begin applying rudimentary styling to tables - but on a large page full of data, it would unnecessarily increase the bandwidth per page, force all browsers to burn cycles as they calculated the appearance of complex table-in-table displays, possibly cause display errors, and completely yoke the content to the presentation, making it that much harder to fix later, when we have better browsers.

So I told the company president it was a usability nightmare and a waste of resources and bandwidth and therefore not worth doing.

He told me to do it anyway.

So I quit my job and started my own company.

Rounded edges, high bandwidth, all that stuff can be fine in the right situations, as long as alternatives are provided and rules of accessibility are respected. Usually I persuade my clients to go in the low-bandwidth direction, and I almost always go low-bandwidth on the noncommercial sites I do (zeldman.com, http://www.webstandards.org/ and http://www.alistapart.com/ ).

But high bandwidth is fine for the right audience. Consider http://www.praystation.com, which is a brilliantly designed site by Joshua Davis. It's amazing work. The audience for that site is primarily Joshua's fellow designers, and most of them have T1 or DSL access. Since the site's goal is to push design as far as it can go on the web, and since the audience is known to have fast connections and a desire to see great design, there is absolutely nothing wrong (and lot right) with the higher-bandwidth road taken by this project.

5) Optimism?
(Score:5, Funny)
by Chalst

How hopeful are you that Microsoft can be coaxed into making IE standards compliant? What exactly do you think Microsoft's motive was in not supporting HTML 4.0 completely?

Jeffrey:

It varies by the hour. Sometimes I think they are going to do this and simply have not committed to it because they're not sure they can pull it off. Sometimes I suspect that as the current market leader (guys with the most users) they think they don't have to bother with this. ("Our way *is* the standard." That kind of thinking.) And sometimes I reckon that they're doing this to fuck up Mozilla. ("You're going to support standards? Well, we have more users. You lose.") I don't *know* what they're thinking, but I suspect that different people there are thinking combinations of all the above.

I do know there are engineers there who are committed to supporting standards. Not only because I've met some of them through my work with WaSP, but also because - in the case of IE5/Mac - they've actually pulled it off. Remember, Microsoft (along with Netscape, Sun, invited experts, etc.) helped come up with these standards in the first place. Why would you design blueprints and then not follow them when you build the house? The engineers who participate in the standards process are committed to complying with standards. Some people in management may not be. Or they may be delaying, for short-sighted competitive reasons, or from fear of committing until they are sure they can do it right.

HTML 4 - the LAST HTML - includes dozens of accessibility improvements, and it is insane for any company not to fully support that. Without full support for HTML 4, millions of web users get hurt. That's morally wrong, and it's also just plain bad for business. I think that in time, all browser companies, including Microsoft, will come to see that. I also think the W3C's recent hiring of a conformance manager (http://xmlhack.com/read.php?item=517) signals that the W3C will soon take a more active role in "helping" companies get with the program, support standards, and stop screwing up developers and web users in a game where everybody - including the browser companies - eventually loses.

6) Balancing Technologies
(Score:5, Insightful)
by Proteus

As you are no doubt aware, the technology that drives web site design is advancing rapidly. However, there are still a lot of users who run older browsers, or prefer to use text-only browsers such as Lynx.

Obviously, one wants to reach as large an audience as possible, but not "lag behind" too far. How do you go about balancing the use of newer technology on a site without alienating users of older software, disabled users, and text-only browsers?

Jeffrey:

Using HTML 4, ALT tags, and the TITLE tag goes a long way toward achieving this goal.

So does using CSS for type, instead of FONT FACE and FONT SIZE tags that yoke content to presentation.

I do both these things, and all the other little things you have to do, for instance with framesets. I think there may be some really old (1996) framesets at zeldman.com where I left out full content inside the noframes tags. I'm cleaning that up as quickly as I can. At ALA http://www.alistapart.com/), wherever I used framesets, I included the full text inside the noframes tags, and I also included TEXT versions of all articles.

The next stage is full separation of content from structure, and that means using HTML 4 and CSS (and eventually, replacing HTML 4 with XHTML; and eventually, migrating to XML).

We can't safely do that yet. Gecko is still in development, Netscape 4 has appalling "support" for CSS, IE5/Windows has better but far from complete support, and the only released browser that gets it right - IE5/Mac - has a 6% market share.

SOON. Not soon enough, but SOON, we will look back on this era of stupidity and laugh. Oh, how we will laugh. This is the TRON era and we are striving to reach the MATRIX era.

7) Reverse scenario question...
(Score:5, Interesting)
by Jonny Royale

Have you ever seen anything come from a browser publisher "extending" a standard (Microsoft, Netscape, other), and thought "Gee, I wish that was in the standard"? Examples?

Jeffrey:

Yes.

LOW SRC was a funky old tag from Netscape (dating back to Netscape 1.1) that allowed you to slip a low-bandwidth image into place, and then have it replaced by the more bandwidth-intensive image when the latter finished downloading. For people with very slow connections, it was a useful hack. It also enabled creative web designers to add a certain amount of "SFX magic" (cough) to even the most primitive pages, viewed by the oldest browsers, under the most adverse conditions. That's gone. Too bad. I miss it.

Because of browser offsets in all released versions of Navigator and most versions of Explorer, I wish the "four horsemen of non-validation" (leftmargin, topmargin marginwidth and marginheight) had made it into HTML 4.0 transitional. We won't need them eventually, but until the browsers are smarter, we still do need them. The W3C is always ahead of what the browsers can deliver, of course; but by discouraging these dumb proprietary tags, the W3C has put us in the position where PAGES THAT WILL NOT WORK without these tags will fail at http://validator.w3.org. That kind of failure discourages developers from building standards-compliant pages. It is a small thing, and it is transitional, but DURING THE TRANSITION, I would have liked to see those four stupid tags get approval with a benevolent sigh.

On the other hand, designers who know what they are doing may include these tags and ignore those validation errors, but don't tell the W3C I said so.

Given the brain-dead way Navigator 4 and IE4/5/Windows handled absolute font size keywords in CSS, I *sometimes* wish font size tags were not discouraged YET. I hate them and hardly ever use them, but (for instance) there's no way to get small type in Linux that is actually READABLE without relying on these dumb old non-standard tags. What I really wish in this case, of course, is that Netscape and Microsoft hadn't fucked up this simple CSS technology. So I take the FONT SIZE tags thing back. Uh, never mind. I just wish Netscape and Microsoft had gotten CSS right the first time.

8) Banners
(Score:5, Interesting)
by TheTomcat

This is only vaguely related to design, but directly related to the web, and functionality.

We all know that banners don't work anymore. The only way a business can profit from banners is to show thousands per day. Most users don't even SEE banners anymore. We avoid them the same way we dig in the couch for the remote when commercials interrupt The Simpsons.

Do you have any suggestions to make future, content-based sites profitable?

Jeffrey:

There are several issues here. One is, a lot of the best work is done as a labor of love, and always will be. Those who need a revenue model before they are willing to even think about working will lose one of the golden opportunities of the web, which is free expression and the building of communities, regardless of financial issues. For instance, Slashdot was born as a community and still is one. Eventually, Slashdot got into a position where it could make money, but Slashdot is true to itself and was not corrupted or changed by any commercial considerations. So it is possible to make a good thing and not blow it when the cash register starts jingling. But a lot of other sites and communities have turned to dreck when money was involved.

We all agree that banners suck - Roblimo even wrote an article for ALA on that subject, back when ALA was just getting launched. With a big enough readership, banners *can* be profitable, as they are at Slashdot. But I agree that most of us just hate 'em.

Sponsorships are another possible means of revenue. "This issue of Webmonkey brought to you by Hewlett-Packard." With an entertaining HP minisite available at the click of a link, for those who care. Kaliber 10000 (http://www.k10k.net) has gotten Apple sponsorship, and all that means is, there's a tiny Apple link in the top right hand corner of the front page. If you click it, you get a popup window with text on why the site's designers like their Macs, and links to some current movies in Apple Quicktime format.

The Cluetrain guys have spoken about this model of corporate sponsorship as well.

I think about it sometimes. For instance, http://www.alistapart.com/ could be "brought to you by" Macromedia or Adobe. But to tell the truth, I don't really pursue this idea because I'm not motivated by money when it comes to creating web content. I simply want to create or choose the right content, and totally control it, and I'm not sanguine that I could do that if I *had* corporate sponsorship. Thinking about it some more is on my to-do list, but it's about 500 layers down in the list. I make enough money designing websites that I don't worry about "revenue models" for my content sites. It is a real issue, though. Just one I haven't bothered with personally, yet.

9) Jeff, your CSS suck
(Score:4, Insightful)
by Nicolas MONNET

I quote from your website:

H1 {font: bold 24px verdana, helvetica, arial, sans-serif; margin-top: 0xp;}
H4 {font: 12px verdana, helvetica, sans-serif; margin-top: 0px; margin-bottom: 10px;}

So why, tell me, WHY did you use PIXELS (px) instead of POINTS (pt), thereby overriding my painfully crafted DPI settings, rendering your all page unviewable on my Linux machine?

Jeffrey:

Refer to the answer to Question 2. Also refer to this Word from the WaSP column:

http://www.webstandards.org/wfw/ieah.html

The best way to style text - and the way the W3C recommends - is to use relative sizes or absolute size keywords.

Both these methods are completely broken in Navigator 4. Totally frickin' useless. Don't shoot the messenger. Netscape agrees, and that's why they threw out their old rendering engine and started from scratch.

And absolute size keywords are stupidly mis-supported in IE4/5 for Windows, where "medium" means large, and "small" means medium.

Faced with this maddening stupidity on the part of browser makers, designers/developers have two choices:

Do not style text at all. Have a nice day.

*OR* rely on pixels, which work in all "CSS-capable" browsers.

I sadly choose the latter until the browsers fully comply with W3C standards.

As to POINTS versus pixels, points are absolutely meaningless on the web, and the fact that they are used by thousands of developers who should know better proves only how little CSS is understood by the development community.

Certain point sizes may work on your platform in your style sheet. That proves that certain point sizes work on your platform in your style sheet. Cross-platform it is not transportable, and points are print-based units of measurement that have no meaningful relationship to the wonderful world of monitor resolution.

For a good discussion of CSS problems, see Todd Fahrner's "Beyond the Font Size Tag: Practical HTML Text and Styling" at http://style.metrius.com/font_size /livetext.html (Unfortunately, even some of *THESE* techniques do not work in more recent versions of Navigator 4.)

In a few months, there will be exactly two browsers that get CSS-1 right: Mozilla/Nav 6 for all platforms, and IE5/Mac which we have now. Since neither has dominant marketshare, developers will still face huge obstacles when trying to do something as SIMPLE and BASIC as size text on the web. Many will stick with pixels, which are the only CSS technique that actually WORKS across browsers and platforms.

In addition to all these nightmarish problems with our browsers, there are special challenges with Linux, because unless Linux users install additional scalable fonts, you can follow all the rules for good CSS, and avoid "problem" font sizes, and still create pages that look jaggy or are unreadable on a lot of people's machines. I worry about this all the time, but I don't have a solution for it. I have actually gone back to using the stupid The way to advance the medium is to get absolute font size keywords and relative font sizes right in CSS, finish implementing HTML 4, and give us the W3C DOM, XML, and EcmaScript. (And then wait two years for users to upgrade.)

10) Pixel based alignment and HTML
(Score:4, Insightful)
by mcelrath

One of the most disturbing trends that I see in web design these days is the trend toward trying to control layout at the pixel level. As HTML (Hypertext Markup) was not intended to be a graphics language, what is your comment on this?

Jeffrey:

Separation of style and content is the way forward.

The problem is the browsers.

When I revised my "Ask Dr Web" tutorial at http://www.zeldman.com/askdrweb/, along with other pages at http://www.zeldman.com/, to use CSS layouts instead of tables, certain versions of Navigator 4 began crashing.

Actually crashing from basic CSS-1.

I wrote about this at A List Apart, ("The Day the Browser Died") and because of this, Netscape invested some time and resources to fixing some of these bugs in Navigator 4. It didn't catch them all, and it didn't catch them in Linux. These bugs will never be fully fixed in Navigator 4, because Netscape is wisely spending its energy to finish the Mozilla browser. Unfortunately, this means that Netscape users will continue to face serious usability hazards throughout the web until Netscape 6 is released ... *OR* it means that developers will continue to use TABLES for layouts for the next two years (as Jakob Nielsen has predicted).

If you look at these pages - http://www.zeldman.com/steal.html or http://www.zeldman.com/icon.html are other examples - you will see that we are talking about extremely BASIC layouts. An expert from the CSS pointers group actually volunteered hours of her time trying alternate combinations of the very basic CSS on those pages to see if she could find ways to stop Netscape from crashing. She could not; neither could I. Netscape did what it could for its 4.0 users, but it can't do anything more until the next generation is released.

On my personal site I made the tough decision to leave these pages as-is. I don't have time to recode them all using tables.

You can agree or disagree with that decision.

Linux folks can either use the Mozilla or Opera betas to navigate those pages in safety and comfort.

It's worth noting that W3C pages also crashed Netscape 4, for the same reason.

What happens when Netscape's browser is this badly damaged? I get hate mail from people who don't understand the issues involved. I also got a letter of thanks from Netscape's Eric Krock, because good companies WANT us to help them find bugs in their software.

As an example of this, many sites (including yours) use font size=1 to acheive a font that is fairly uniform in pixel size across browsers. Anyone with a high-resolution screen will tell you that this is highly annoying, since it results in an almost unreadable font.

See above for the explanation as to why developers are stuck using 1994 technology to support late-1990s browsers. The same questions, the same answers.

The good thing - the ONLY good thing - about the font size tag is that it is user-resizable. The rest of this has been answered above.

Forcing netscape to use a larger font size often destroys the layout of the page. What's worse, some pages use dynamic fonts and other features to force this on the user.

Right, although in some cases it is justified.

As another example, many pages use the table , and layer to specify the exact size in pixels of portions of the page, and then put a little notice at the bottom ("This site best viewed at 800x600") or some such.

Yes, that is usually a bad design decision. Whenever possible, I use what Glenn Davis (WaSP and Project Cool co-founder) calls "liquid" design ... design that reflows to exactly fit the visitor's monitor. That's almost always a better way to go. Examples of my liquid designs include http://www.alistapart.com/, http://www.the-adstore.com, and most of zeldman.com. If you dig long enough in zeldman.com, you'll come upon pages older than the NYC subways, that simply use BAD design ... though at the time, it wasn't all that bad.

Liquid design is not always appropriate but it is generally best.

What are standards groups doing to fix this?

Nothing. The W3C can't make better or more intelligent designers out of people, and neither can the WaSP, whose sole purpose is to agitate for W3C standards in browsers (and eventually in web authoring tools).

We can try to lead by example. http://www.webstandards.org/ is liquid (aside from the front page, which is "semi-liquid" owing to the large low-rez graphic) and it validates.

MEMBERS of standards groups can write articles on the subject and hope that people read them. Of course, if people "can't get past" a 4k splash page, they will not learn about my articles on the subject.

Will I be looking at pages designed for 800x600 (or worse, 640x480) with my 1920x1440 screen forever? Will persons with laptops at 640x480 be unable to read the web soon? Will standards bodies ever require percentage-of-screen width and height specifiers, or even better, implement table width=30ch to specify sizes in relation to the current font size?

Standards bodies can recommend certain authoring practices, and they can develop standards that make such practices possible, but they cannot enforce good authoring.

11) Evaluate Slashdot
(Score:5, Interesting)
by Pseudonymus Bosch

What would you change, what would you add, what would you remove in Slashdot?

Jeffrey:

It's a community and it works. It has achieved visibility, notoriety, and even commercial success without giving an inch. Pretty awesome achievement. What would I change?

Sometimes the longer threads take a long time to load, due to back-end technology, platform and server issues. The technology works better on Linux than it does on my platform of choice (Mac OS) but, hey, that's okay.

I know you want me to comment on the design. Design is subjective. Black backgrounds and teal are not my favorite color scheme (though I used black backgrounds at the 1995 Ad Graveyard (http://www.zeldman.com/ad.html) and the January 1997 Furbo Filters so who am I to talk? The main thing I was trying to do at Furbo was get CSS to work - and to let people know about Craig Hockenberry's and my Furbo Filters, which were the only Photoshop plugins at the time that dealt with the web-safe color palette - at least to our knowledge.)

I might change the color scheme and some other things if Rob Malda went on a crack run and asked me to redesign Slashdot, but that ain't likely to happen. And I think the design of Slashdot is just fine. It focuses you on the breaking stories, allows you to read more (or not), and provides access to almost everything else on the site via small navigation units. In terms of usability it is damn good, and it has plenty of attitude.

Of course, it commits the "cardinal sin" of teal, but I can get past that.

12) Do you agree with Nielsen?
(Score:4, Interesting)
by Pseudonymus Bosch

I have no idea about you and your views, but I have read lots of the Alertbox columns by Jakob Nielsen.

Do you agree with him? Do you disagree? What about?

Jeffrey:

I agree with his comments on oral sex and wearing white after Labor Day.

And I like that he can get $25,000 to talk for an hour. I'll do the same for half that amount.

I also agree with Jakob that most websites should be usable by as many people as possible.

What I have done about that is help found The Web Standards Project, so we can actually achieve that goal instead of using duct tape and lasagna to build sites that work for "most" people. And I try to make my pages accessible in spite of the limitations of current browsers and some of the cross-platform issues discussed above.

If you are interested in my views, you can read them at http://www.alistapart.com/, Adobe.com (here, http://www.adobe.com/we b/columns/zeldman/20000320/main.html, for instance), http://www.webstandards.org/ and of course at http://www.zeldman.com/. If you can get past the 4k splash page.

At least you share the use of TITLE attributes in hyperlinks (a good feature that Slashdot shouldn't chomp away).

Thanks! The reason Slashdot chomps title tags is probably because they are not supported in Netscape yet. They are an important usability feature, and in some browsers they also offer nifty low-grade special effects - along with the opportunity for contextual ampliciation or ironic commentary.

jeffrey

Can't act. Can't sing. Can dance a little.

http://www.zeldman.com
http://www.alistapart.com
http://www.happycog.com
http://www.webstandards.org