evolt.org Workers of the Web, Evolt!

1. The alternative styles are slow to change. This is due to the graphic loading as well. (Even when cached, it seems to require reloading.) Nor do they change the rest of the page much.
    
2. The dropdown menus are cool, but they are too close together. The W3C Accessibility Guidelines tells us to separate links with a symbol (such as a line or dot) to make them clearer.
    
3. The links don't print out the URL in IE6. My guess is they're using the CSS command :after to generate the URL - I've seen it published somewhere. Great idea, but it only works in two or more very new browsers, and not IE! A better idea might be to add the URL in a div after each link, then make it {display:none;} in all stylesheets except for the print one. It's an idea I had this week for our site at work, and I might try it out soon.

I thought I'd share a few brief thoughts on some of our design choices in the hopes of answering the points commenters have raised.

• Font sizing/test-resize gimmick-- unfortunately, there are no good choices for sizing fonts on the Web. Even leaving the size totally alone isn't a good choice. We decided to use pixel-sized text because most browsers have text zoom functions that override any text sizing. Since the exception is IE/Win, we needed the gimmick, but it's one we felt we had to provide in order not to leave IE/Win users without any options at all. One can argue this shows we made a bad choice, but one can also argue this shows that browsers (ALL browsers) still have some way to go in terms of accessibility.
• "Theme" choices-- yeah, we could have done more in terms of different layouts, and I wanted to do so. But since this redesign effort went from zero to done in less than two months, including a complete reworking of our data structures in the backend and dramatic changes to the way we build the site, we had to settle for variations. Radical restyling just wasn't something high enough on the priority list. We hope to add more varied themes and powerful customization features down the road.
• "Theme" reloading-- only IE/Win does this, because we had to script our way around problems in its behavior. In our original RC build, when you switched the theme, the masthead's background wouldn't appear. The only way around it was to force the browser to reload the page. Other browsers don't have the same problem, so they don't need the reload hack.
• Navbar links too close together-- IE/Win bugs in inline layout are to blame for that. We're thinking about lightening up the borders between the links for visual reasons. There isn't an accessibility issue there, because in the unstyled view those links are an unordered list. Thus no symbol or separator is needed; the separation is already built into the structure.
• Printed link URLs-- yes, that uses generated content; and no, IE doesn't support it. When IE is updated to support generated content, then its users will get the benefit. In the meantime, they're missing out on a minor (cool) feature, but it's nothing that prevents them from making use of the site. We can't use a solution like nolayer because it will prevent validation.

Thanks for the comments!

.. and my apologies if my initial remarks were a bit scathing - I am generally impressed with what's been acheived.

My critisism was rooted in the way the user-style and font control is presented as an accessibility feature, when very little accessibility benefit is gained - for example, why is one of the options not light text on a dark background, or dark text on a tinted background (many people find a tinted background much easier to read against than white).

That IE doesn't resize pixel text might be a bug ... but that really is irrelevant. Sure, it's counter-productive to concede to netscape 4 and ie4, but not to ie5 and ie6 - these are the majority browsers, however buggy they are; you can't ignore something so fundamental, especially when you flag what you've done as a good example to others.

As it goes - I find % font-size pretty reliable - consistent between ie5/6 and mozilla, at any rate, and only marginally smaller in Opera.

Since the majority of surfers use IE, I'd have thought it prudent to make sure things like printable URLs work in that browser, and as a luxury, Mozilla and Opera, etc. But then we're talking about the Netscape DevEdge site here! :-)

Kirkaracha - "Classes would probably be better to use than DIVs, since you're likely to have more than one URL on a page.".
It doesn't matter how many divs you have, they can all reference the same CSS. Or is that breaking any rules? The main reason I don't use classes is that I once had a page with several divs on that would fail to display one of them properly. After much testing and frustration, I eventually concluded that I had too many classes on the page. Sounds crazy? Well I replaced them all with "id"s instead, and the page then worked. So now I avoid divs with classes.

Also, I would replace your class in testCSS2.css with .url {display:inline;}; as this helps to keep the printed URL with the surrounding text.

Eric - "Navbar links too close together-- IE/Win bugs in inline layout are to blame for that. We're thinking about lightening up the borders between the links for visual reasons.".
No, the links are too close on all the browsers I looked at the site in. It looks like a sentence of words, rather than a set of links. However, only later did I notice the black borders inbetween them! On my screen, you can barely see them due to the dark blue background. All you need to do is add some padding at the left and right to space the links out.

One last thing. The Print Preview in Opera 7 on Windows 98 gives me a first page that's completely blank! The second page has the text, but no borders! You might want to look into that. Could be a browser bug or the code needs tweaking.