the daily report
web design news since the 14.4 modem was hot
Live. Free. Designing with standards. Registration requested.
25 February 2003 :::
9 am
Eating their own dog food 3.0
Now online for the third time, Marko Karppinen’s biannual standards compliancy test checks to see how many W3C member sites are actually using the standards the body develops and advocates.
The latest results show an increase of 75.7% from the initial test of February 2002. It sounds better than it is. In the initial tests, a mere 3.7% of W3C member sites used valid markup and (optionally) valid CSS. Today the number is up to 6.5% of member sites – still low.
“It is easy to see this as being somewhat representative of how the big businesses and leading academic institutions are adopting web standards,” says Marko. :::
From our Swedish connection
Our Swedish pal Peyo Almqvist shares some of the work he’s been doing lately. Pensum (Swedish language) is the good looking site of a banking co. – and it validates as XHTML 1.0 Frameset. Falcon.se (Swedish language) is a fancy-pants multimedia site that lets you bet on hockey games rendered as Flash movies. (Choose “Ja” to enter.) Port Elizabeth is a destination site with smart features and heavy front page image load times. Some of its subtler features don’t yet work in Mozilla or Kmeleon based browsers but they will. The site displays fine in these browsers, it’s just missing a few tricks due to scripting based on document.all and document.layers instead of document.getelementbyid. :::
24 February 2003 :::
11 am
A new look for an old dotcom
Fray.com has received its first facelift in six and a half years and is looking good. The Fray is a personal storytelling site and one of the web’s longest-running independent content sites. But you know that. The redesign retains familiar, lovable elements from the long running original designed in the mid 1990s, while successfully recasting them in a modern format. :::
Designing with standards
The first draft of Designing with Web Standards is finished, and all but six chapters have gone through final revision. A book like this must benefit designers who’ve worked with standards for years, but it must also speak to those who know lots about ASP or PHP or Flash and less about structured markup and logical CSS. Finding the right balance is tricky. Consider DOCTYPE switching.
Some of us assume that everyone knows about DOCTYPE switching by now, but this is not so. Many designers and content people I’ve spoken with recently had never heard of DOCTYPE switching, which is a toggling mechanism invented by Todd Fahrner in 1998 that lets browser makers support standards without breaking sites built the old-fashioned way.
Though the premise of DOCTYPE switching is simple, IE’s Standards mode differs from that of Gecko browsers like Mozilla, Netscape, and the user agent formerly known as Chimera. In true Standards mode, Gecko browsers assume an inline model for images, which can have unexpected consequences for some hybrid (CSS + table) layouts. To make things easier for designers, later Gecko browsers (Netscape 7, Mozilla 1.01+) added an “Almost Standards” mode that works like IE’s Standards mode. Of course there is more to it than that. There is an entire chapter’s worth of more to it than that.
It is necessary to explain it all without scaring standards novices by making it seem as confusing as, well, as it actually is. Yet it must be covered in sufficient detail to serve designers who are familiar with DOCTYPE switching but unaware of some nuance or other. Many such issues must be discussed without bogging down in tangents or losing focus. The book must be clear, precise, design- and results-oriented, and it must be fun to read. Time and readers will tell. :::
Candies for you
Dinc Type has always made great fonts “for people with computers.” Now they are all free. ::: Pixelgirl Presents OS X icons and desktop pix. ::: Chmork.net is pretty and campy. ::: Yesterme: pinup pix. :::
Bits from all over
Using Apache to serve XHTML as application/xhtml+xml for XHTML aware browsers, text/html for others. ::: How accessible is Safari? ::: Websites mit dem richtigen Doctype versehen (ALA article in translation). ::: Zeldman goes mobile. :::
20 February 2003 :::
5 pm | 4 pm | 1 pm EST
There’s a new style switching tool bar in the left-hand sidebar. When in doubt, reload.
ESPN redesigns with standards
ESPN.com has redesigned using CSS layout. For now, the retooling is limited to the front page. Once it’s been fine-tuned, the approach will work its way into the rest of the vast site. Though the site has problems that will likely be fixed in the coming weeks, here’s what art director Mike Davidson and his team got right:
- All CSS positioning. No tables for layout except in sponsored Microsoft elements beyond the design team’s control.
- No font tags.
- Bandwidth, bandwidth, bandwidth. Front page markup and code are now half the size they were before the relaunch while displaying a much richer page. (With structural markup, the bandwidth savings would be even greater.)
- Only one style sheet for all browsers – no detection used or needed. The site looks more or less identical in all browsers that support
getElementById(including Safari), though Linux rendering may be unattractive.
Visitors using non-standards-compliant browsers (fewer than 2% of ESPN’s audience, we’re told) are bumped to an upgrade page. If they choose not to download a conformant browser, they can view a “light” version of the site. This old, WaSP-inspired technique is not to everyone’s taste, but it may be appropriate given the site’s emphasis on scripting and rich media. The approach will be more justifiable once the team has ironed out validation issues, some (but not all) of which are due to third party content.
Naturally, no sooner had we written about the site, than an unclosed comment tag showed up at the top of the page, breaking the layout in Mozilla. CMS error or human error? Only their hairdressers know for sure. (IE apparently ignores the error.)
ESPN’s approach to standards is not purist and it’s not perfect. There is more browser detection than may be necessary, and markup errs in the direction of presentation. Accessibility could be also improved. Some of these changes may be made in the coming weeks. Though ESPN.com’s approach to standards could be better in some areas, the fact that such a huge and influential site has begun the process of abandoning Stone Age methods is a win. :::
The smell of design
We designed the new style switching tool bar on the plane between sunny New Mexico and snowy New York City. We were seated at the rear of the aircraft, pleasantly adjacent to the restroom. A small boy fidgeting on the line to the toilet pointed at the Titanium Powerbook on our tray table and informed his mother, “I want one of those.” It was so like an Apple commercial we expected Jeff Goldblum to pop out of the can with an appropriately whimsical voiceover. “The new Powerbook from Apple. It goes where you do.” :::
WaSP Phase 3
The Web Standards Project has recruited seventeen new steering committee members — and this WaSP has retired from the group he co-founded in 1998. The seventeen look like the right people to take WaSP where it needs to go. Mr Zeldman will continue to use, teach, and write about web standards in his own way.
A news article makes it appear that the “new” WaSP, in working amiably with browser and tool makers, will be breaking with its past. Actually, the old WaSP established friendly relations with engineers and standards experts at Netscape and Microsoft in late 1999, and began working with Macromedia’s Dreamweaver team in 2001. (The “angry” WaSP pretty much died in early 1999 after it had succeeded in getting Netscape and Microsoft’s attention.) :::
14 February 2003 :::
Long weekend edition
First person
Moments after writing this, I will disconnect from the Internet. Carrie and I are flying to Santa Fe, NM, where we hope to finish writing our books. Later, joined by Eric Meyer, we will drive up to Los Alamos National Laboratories, where we’ll spend time with old comrades and give little talks about CSS, accessibility, and designing websites on a shoestring budget. Here’s wishing you a happy Valentine’s Day and a joyous weekend. :::
13 February 2003 :::
2 pm | 10 am EST
DevEdge reborn
Netscape’s DevEdge has been reborn as a standards showcase: “Now DevEdge is not only a great source of tools and information for developers, it demonstrates extensive use of web standards for accessibility, maintainability, and user interaction.” Features include tableless, CSS layout; switchable styles, one of which includes a header graphic that hearkens back to the original DevEdge of the mid-1990s; cross-browser dropdown menus (these don’t work in IE5/Mac, but IE5/Mac users have been provided for); and link URLs that print out for your convenience. Eric Meyer contributed to the redesign and more information is available on his site. :::
Safari defritzed
We’ve fixed the background image latency error in Safari, where a background image at the bottom of the sidebar in the white layout erroneously appeared in the orange layout after switching styles. The fix was simple and logical: in the orange layout we explicitly told all browsers not to use a background image in the sidebar.
Old rule:
background: #c60;
Replacement:
background-color: #c60;
background-image: none;
Other than Safari, no browser tested required this change. This is a bug in Safari — there’s no doubt about that — but it is easy to work around. :::
Color blender
In still more Eric Meyer news, check his nifty new color blender, created in JavaScript, using math sussed out by Steven Champeon of Webdesign-l. The quickly-hacked-together tool may not look like much, but what it does is sweet. :::
Gecko “debugged!”
The Gecko link following issue has been solved by Paul Sowden, creator of the original style switching script. To varying degrees, Gecko browsers Mozilla, Chimera, and Netscape 7 became confused by non-CSS <link> elements in the head of the template, such as ...
<link rev="alistapart" href="http://www.alistapart.com/" title="From pixels to prose, coding to content: A List Apart Magazine, for people who make websites." />
These elements were not present in earlier iterations of the site. Earlier iterations of the site also used a different method of triggering the JavaScript function. The onclick/onkeypress was previously applied to to a <form> input, not to a linked image with return false, so browsers likely to be confused by non-CSS <link> elements never got a chance to demonstrate their confusion.
Porter Glendinning explains that the original style switcher...
...loops through link elements looking for one with a rel containing ‘style,’ disabling them all, and enabling only the one whose title matches the argument passed to the function. The problem is that not all ... your link elements have rel attributes, specifically the last two ‘rev’ links. This means that the conditional in your
setActiveStyleSheet()function that contains this check:
a.getAttribute(“rel”).indexOf(“style”) != -1... fails when it comes to the first ‘rel-less’ link element. (It can’t evaluate an
IndexOffor an object that doesn’t exist.) In certain browsers, this error is taken as a reason to puke out of the onclick handler entirely; the style sheet is switched, but then the error happens – the ‘return false’ is never reached, and the href for the link is then followed.
You can view the adjusted script at /j/nuj.js. The relevant portion begins after the // switch styles comment. If you use the ALA style switcher and if the head of your document contains links to related content, you may want to make the changes shown in the updated script to avoid triggering undesired behavior in some browsers.
David Anderson also identified the problem and contributed a script variant that came within centimeters of solving it – thank you, David – and many in the design and development community contributed additional suggestions and ideas.
Tom Sawyer thanks all the boys for painting his fence.
So is this a bug in Gecko browsers, or is it merely touchy error handling? Were IE and Opera 7 wrong to ignore the error? We will leave that one for the existentialists in the house. :::
12 February 2003 :::
5 pm | 11 am EST
Bugosity
Dozens of readers report no such bug in recent builds of Mozilla and one claims no such bug in Moz 1.1 though others claim otherwise. “For what it's worth, the style switcher works in a 20030205 Phoenix nightly under Linux, but not Mozilla nightly 2003011608,” says Peter Janes.
It works for some people. It fails for others.
Steve Champeon of WaSP claims no such bug in his Netscape 7. Will Kessel, on the other hand, experienced the following in Netscape 7/Win 98/SE: after switching to orange, he was whisked to the Style Switcher page. When he tried to switch back to white, he was again whisked back to the Style Switcher page – in orange. The only way he could return to the white style was to open the home page in another window or a new browser tab. Yeah, that’s what we’re talking ’bout.
One Chimera fan – using 0.6 – claims no such bug. No other Chimera users have yet been heard from. We are using a later version of Chimera and wonder if the bug was introduced in that build. Or even if it is a bug. We can’t be sure.
This may be a “don’t run more than one Gecko browser” problem, in which, by using more than one Gecko based browser, you corrupt the JavaScript performance in all your Gecko browsers. (Why would you use more than one Gecko browser? Because UI widgets look different in Netscape 7 and Chimera, and as a designer you need to know about thse differences.)
Some claim this is a known and long-standing Gecko problem to which they suggest a variety of fixes. Michae Guitton says:
Please try
<a href="javascript://nop/"> or <a href="javascript:void(0)">This should fix the faulty behavior in Netscape 7 and Chimera. I prefer the 1st option which looks like a true URI.
We would rather not do those things.
David Anderson claims that the issue has nothing to do with Gecko’s ignorance of return false and proposes that we modify lines 50 and 60 of our script, replacing the a.getAttribute("rel") call. Pascal Chevrel made a similar observation. What, if anything, we can make of these coders’ comments remains to be seen, and it will not be seen for a few days.
And then there’s Safari.
A new version of Safari released today (hat tip: Dan Benjamin) seems to fix the random cookie loss problem, but only if you jump through your own smallest orifice. You must delete your previous copy of Safari, launch the new version, use Safari: Preferences: Security: Show Cookies to find and delete cookies set by this site, quit the browser, and restart. If you do all that, Safari seems to remember cookie settings instead of randomly forgetting them from one page to the next.
Today’s version of Safari still incorrectly sticks the white layout’s grey-green color bar into the orange layout, but that’s a one-Advil headache at most. :::
If it slithers...
A spankin’ new About: Style Switcher page does what you expect, but it also demonstrates the JavaScript anchor link bug in Gecko browsers like Netscape 7 and Chimera. Click the wee colored toolbar in the sidebar to switch styles in any of the “no problem” browsers listed at the top of yesterday’s Report. The page’s look and feel will change as expected. Then switch styles in Netscape 7 or Chimera. After the change, you will be whisked away to the Style Switcher page.
We’re not doing anything fancy. We ain’t be sniffin’. We’re not even deliberately exploiting the bug to demonstrate it. The anchor link preceding the JavaScript onclick event is intended to provide help and information to people who can’t use the switcher or don’t need to. Text browsers and simple wireless devices should follow that link. Browsers that don’t support JavaScript should follow it. But DOM-savvy browsers should ignore the link and simply process the script. That’s what return false is for, that’s how it’s always worked, and that’s how it still works in non-Gecko browsers.
We greatly respect Gecko browsers, but if it looks like a bug, slithers about in filthy public restrooms like a bug, and goes places it should not go when you are swimming naked in the Rainforest like a bug, friends, it just may be a bug.
Of course it may be known bug. Or it may be deliberate behavior, based on some geek’s opinion that return false should be ignored due to lack of semantic purity. Before writing today’s Report, we attempted to find out.
We went straight to the source: Bugzilla. The form said “Enter a bug number or some search terms.” We entered some search terms (onclick return false). And here was the highly useful result:
“The 'bug number' is invalid. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907.”
Need we add that Bug 70907 had nothing to do with onclick events? That JavaScript was enabled in our browser? And that our browser was made by the very engineers who maintain Bugzilla? So anyway. We think Gecko browsers have a bug in the way they handle onclick events that include hyperlinks. Whether the Mozilla folks know about it or not, and whether they consider it a bug or not, we cannot say. :::