MozillaZine

Wired News Redesigns With Web Standards

Friday October 11th, 2002

Brent Marshall, Anonymous, sacolcor and Doron all wrote in to tell us that Wired News has a new, standards-compliant design. The site, part of Terra Lycos (Condé Nast owns the magazine bit), is now coded in XHTML 1.0 Transitional and CSS with not a <table> tag in sight (though as Scott Andrew points out, the front page doesn't quite validate right now). In addition, the site now features user-selectable alternative stylesheets. It also looks great.

Doron adds: "Eric Meyer from the Netscape Evangelism group has an interview with the Network Design Manager at Netscape DevEdge." Eric Meyer is also quoted in the Terra Lycos press release.


#1 aparently konqueror chokes on this

by joschi

Friday October 11th, 2002 3:05 PM

Reply to this message

my friend who is a kde buff tells me that "wired's new design looks like dog poo in konqueror" :) I'm just curious, i hear konq has really good standards support, and i read here that wired's new xhtml isnt quite valid, so anyone know who's at fault here?

#2 Re: aparently konqueror chokes on this

by turi

Friday October 11th, 2002 3:28 PM

Reply to this message

Does work well with my KDE 3.0.1 Konqueror even though the font is extremely tiny. The text-size changer of wired.com doesn't work (works with mozilla though). But using the zoom function of Konqueror everything seems to be fine.

#3 Site now validating

by choess <choess@stwing.upenn.edu>

Friday October 11th, 2002 5:27 PM

Reply to this message

They must have fixed whichever popup ads were breaking it; the site now validates.

#4 Not Quite Standards Compliant Yet!

by schapel

Friday October 11th, 2002 5:43 PM

Reply to this message

The page is served as text/html instead of text/xml. Check the Page Info.

#8 Why text/html

by tepples <tepples@spamcop.net>

Friday October 11th, 2002 8:52 PM

Reply to this message

In IE, a page served with content-type: text/xml, application/xml, or the preferred application/xhtml+xml will be displayed as a source code outline rather than as rendered HTML. The switch to application/xhtml+xml will probably take place sometime around the switch to XHTML 2, an incompatible change that pushes XHTML toward the functionality of docbook.

#11 Re: Why text/html

by michaelg <mike@vee.net>

Saturday October 12th, 2002 2:53 AM

Reply to this message

Yes, and IE is broken in that respect, and should be fixed. See <http://www.hixie.ch/advocacy/xhtml> for reasons why XHTML should not be sent at text/html.

If you're serving XHTML, serve it as text/html, if you want IE users to be able to see it, serve HTML instead.

/mike.

#12 Re: Why text/html

by michaelg <mike@vee.net>

Saturday October 12th, 2002 2:55 AM

Reply to this message

Err I meant to say: "If you're serving XHTML, serve it as *text/xml*", of course.

:(

#17 Go ahead and use text/html

by leafdigital

Tuesday October 15th, 2002 4:09 AM

Reply to this message

Come on, serving XHTML as anything other than text/html is NOT an option. 'If you want IE users to see it' - that's not a want or an if, it's an imperative fact that you can't possibly ignore 90%+ of your audience.

I don't think people should be discouraged from using XHTML for this reason. Yes, XHTML should be stricter (and hopefully will be when served as application/xhtml+xml) but fine, people can deal with any problems that causes when they change MIME type. Consider it the 'training wheels' version.

The really critical problem is that common Web servers provide no sensible way of serving different MIME types based on the user agent, without resorting to server-side scripting. You ought to be able to do it in Apache with the rewrite engine, but due to bugs, it doesn't work, and there's no clean solution that doesn't involve multiple copies of the files.

The ability to easily serve XHTML documents as application/xhtml+xml (initially, to known-compliant user agents) and as text/html (initially, to all unknown user agents) is an essential feature for proper XHTML adoption and the use of the correct MIME type. Until Apache has this feature (with a preconfigured list of browsers and an easy switch in .htaccess to enable), the new MIME type will not be used.

It would be nice if sites which obviously use a lot of server-side scripting anyhow were also able to send the correct MIME type as well to those browsers (primarily Gecko) which support it... although realistically, given that their ad banners etc. are likely to break things until they get it settled down, Wired could probably do with the 'mostly compliant' text/html training wheels for now anyhow.

--sam

#20 Not User Agent

by bertilow

Tuesday October 15th, 2002 5:46 AM

Reply to this message

"The really critical problem is that common Web servers provide no sensible way of serving different MIME types based on the user agent, without resorting to server-side scripting."

It should not be done based on "User Agent". It should be done based on the "Accept" header. But it's still true that common Web servers don't give any easy way of doing this.

It can however be done without too much trouble with PHP, ASP, JSP or any similar thing.

#21 You're right of course - and a solution

by leafdigital

Tuesday October 15th, 2002 6:29 AM

Reply to this message

Sorry, my brain was blanking on that one. Yes, of course you're absolutely right and it should be done using the accept header.

Actually although there was nothing out there last time I looked several months ago, and the rewrite-rule I wrote for it hit an apache bug of some sort, I researched it again and somebody has found a solution. Check the .htaccess listed on this page:

<http://schneegans.de/tips/apache-xhtml.html>

Very nice. (Would be nicer if it worked for / URLs as well as .html URLs...)

--sam

#5 3/4 Credit

by Wiggins <wiggins@danconia.org>

Friday October 11th, 2002 6:19 PM

Reply to this message

I give them 3/4 credit. Sure they adopted the standards for the coding, and hooray for not using tables for the design, but I can't help stating that why bother to go to all the trouble and then create a site that is left justified and stationary. A simple use of 100% width in the main content area would have made the site really stand out as impressive, but until that happens it is still nothing more than a print design coded so that a browser can understand it, granted it is nice that all the browsers can understand it, but they still aren't thinking in non-print terms when it comes to layout, which I suppose is not surprising from a "magazine" even if it is called wired.

All of the sites that I visit on a regular basis and enjoy use this concept, mozillazine, mozilla, amazon, my yahoo!, slashdot, sourceforge, linux.com, etc.

Then you go to a site like wired, or the detroit free press, la times, ny times, abc news, MSN (ick), ESPN, at least CNet and ZdNet are centered (though they aren't full browser width), and they all look like sh*t.

So, sorry wired you get 2 stars for making the attempt and following through on the code base, but you lose a star for the print design, and lose 2 more stars for patting yourself on the back while missing the mark.

#16 Re: 3/4 Credit

by johajoha

Sunday October 13th, 2002 10:31 AM

Reply to this message

One reason for the limited width could be readability. I like to keep my browser maximized/quite large, it is so much harder to follow the text from left to right the whole width of the screen with your eyes than to read a narrow column.

- Johannes

#19 I'd give them a plus for that

by leafdigital

Tuesday October 15th, 2002 4:27 AM

Reply to this message

I generally prefer fixed-width sites. Liquid sites nearly always have major line-length issues.

It's possible, with careful use of max-width (a property which, btw, will actually work only for around 1% of wired's audience) to restrict lines to a reasonable length so that you have liquid sites which don't become unreadable on too-large browser windows. But most liquid sites don't do this.

The really important thing here is user education. We need to teach users that blank space is *not* 'wasted space' and that it's far, far better to have text lines of a sensible length (up to about 14-15 words max, with 8-12 being a more comfortable norm) than to fit somebody's misguided idea of 'not wasting any space'.

Save your eyes, not a few blank pixels.

--sam

#6 Slashdot?

by nick <nick@reloco.com.ar>

Friday October 11th, 2002 6:48 PM

Reply to this message

No.. slashdot is a mess of <font> tags and invalid HTML. But I'm in the process of creating an exact clone of Slashdot homepage using CSS:

<<http://mazinger.technisys…ruebas-nick/slashdot.html>>

Look how the rounded thing of slashdot is done by -moz-border-radius =).

There are still some tables left.

#7 Slashdot?

by nick <nick@reloco.com.ar>

Friday October 11th, 2002 6:49 PM

Reply to this message

Wow.. the link detection code in MZ is eally buggy, heer we go again: <http://mazinger.technisys…ruebas-nick/slashdot.html>

#9 GIF. Ecch.

by tepples <tepples@spamcop.net>

Friday October 11th, 2002 8:54 PM

Reply to this message

You really should burn all GIFs ( <http://burnallgifs.org/> ). All 4.1 and higher browsers can display PNG image.

#18 -moz-border-radius. Ecch.

by leafdigital

Tuesday October 15th, 2002 4:16 AM

Reply to this message

Although for some common types of image, PNG files are slightly larger than GIFs (even when compressed efficiently i.e. not using Photoshop), a fact which is largely ignored...

More to the point, though, um, you're not supposed to use -moz-border-radius on the Web; it's non-standard, which in fact makes it worse than a font tag since that may be deprecated but was at least in the standard, where as -moz properties are specifically non-standard and will never work on any other browsers...

--sam

#10 Re: Slashcode

by schapel

Friday October 11th, 2002 9:57 PM

Reply to this message

Slashcode is open source. Why not make Slashdot and all other Slash sites standards compliant for real? And I agree that it should be GIF-free, too.

#13 Re: Re: Slashcode

by peter

Saturday October 12th, 2002 8:00 AM

Reply to this message

I'm working on making Slashcode comply with both W3C's Web Content Accessibility Guidelines and XHTML 1.1. I've not released any code yet, but I will soon. See <http://slashcode.com/arti…mp;mode=thread&tid=24> for more information. Feel free to mail me, <peter@openflows.org> with questions / whatever about this.

NOTE, this does not mean that slashdot will use this code. This is up to the OSDN people to decide.

#14 A bit too standards compliant

by bertilow

Saturday October 12th, 2002 8:24 AM

Reply to this message

Choosing XHTML 1.1 is probably going a bit too far. As of now only Mozilla (and possibly Opera) can make heads or tails of XHTML 1.1. If you chose XHTML 1.0 Strict or Transitional (with allt the HTML compatibility tricks) the code might have a reasonable chance of being adopted by anyone. Choosing HTML 4.01 Strict or Transitional would probably be even more realistic for Slashdot.

I would go for XHTML 1.0 Strict. Once the world is ready for XHTML 1.1 it would be a small task to upgrade the code to the new standard.

#15 Re: A bit too standards compliant

by peter

Saturday October 12th, 2002 8:36 AM

Reply to this message

I do plan on offering instructions and scripts to convert Slashcode's templates / code into HTML 4.01 Strict ( from XHTML 1.1 ). And let each site admin choose if they want XHTML or HTML.

#22 www.opera.com validates for XHTML 1.0 and 1.1

by motobass

Tuesday October 15th, 2002 2:09 PM

Reply to this message

Opera upgraded their site recently too.