Slashdot Mirror

There is no difference to CSS whether I have: <button>hello</button> or <div>hello</div>

No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.

Also please note that the CSS2 spec explicitly says that backgrounds should not be set for HTML items: The background of the box generated by the root element covers the entire canvas. For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the 'background' property for the HTML element is different from 'transparent' then use it, else use the value of the 'background' property for the BODY element.

For those of you with trouble reading spec-ese, this means a couple of things. First, the allegedly required functionality (widget background setting) is actually recommended against in the specification.

Second, the Mozilla implementation misinterprets the spec. Having a button on a BODY that has a background image or background color would create the same visual effect within the button's bounding box as setting the button's own background image or background color -- which is to say, a surround effect, not a fill effect.

The supposedly required functionality is not required, and Mozilla is interpreting the functionality in a clearly incorrect way.

Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading [w3.org]. Ultimatly while form elements may normally look like they've been rendered with this style sheet [w3.org] there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.

Nope, sorry, you're reading that wrong too. The goal there is to be able to use system default appearances, not to get away from system default appearances. Search for the string "system standard rendering" -- it appears many times -- and note statements like:

Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. This proposal extends them to provide the ability, through CSS, to style elements based upon their various user interface related states, and to make an arbitrary structural element take on the dynamic presentation, or system default look and feel, of various standard user interface widgets.

The exact rendering of check and diamond depends on the user agent, but it is suggested that the same glyph which is used on the platform to render a "checked" menu item be used for "check", and similarly for those platforms which support rendering of a "diamond" next to a menu item. Conformant user agents may render 'diamond' the same as 'check'. The radio- and checkbox- values are rendered as they are by default on the platform.

Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.

Tim

These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button.

These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button.

These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button. Widgets are not required to be transparent and to show their background image through them. A correct interpretation would show, for instance, a normal platform button sitting within its box surrounded by, not filled by, the background image or color. See the CSS2 spec on this point.

If you were to interpret the background properties consistently as meaning fill color or image, then the text areas shown would be inconsistent. The characters would need to be drawn in their background image or color (as the widgets are), rather than on top of their background image or color.

The things on the page that appear to be correct w.r.t. the spec are doable natively. Widget colors are controllable on both major platforms. Frames and backgrounds for text editing areas are also controllable with native widgets on both major platforms. (Couldn't speak to Linux.)

In addition, no user agent is required to render every possible combination of CSS properties. See the CSS2 spec: A computed value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the computed width. The actual value is the computed value after any approximations have been applied. Sure, the more coverage the better, but does Mozilla render fractional border widths? Approximation of computed values in rendering still leaves a user agent conformant.

Tim

These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button. Widgets are not required to be transparent and to show their background image through them. A correct interpretation would show, for instance, a normal platform button sitting within its box surrounded by, not filled by, the background image or color. See the CSS2 spec on this point.

If you were to interpret the background properties consistently as meaning fill color or image, then the text areas shown would be inconsistent. The characters would need to be drawn in their background image or color (as the widgets are), rather than on top of their background image or color.

The things on the page that appear to be correct w.r.t. the spec are doable natively. Widget colors are controllable on both major platforms. Frames and backgrounds for text editing areas are also controllable with native widgets on both major platforms. (Couldn't speak to Linux.)

In addition, no user agent is required to render every possible combination of CSS properties. See the CSS2 spec: A computed value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the computed width. The actual value is the computed value after any approximations have been applied. Sure, the more coverage the better, but does Mozilla render fractional border widths? Approximation of computed values in rendering still leaves a user agent conformant.

Tim

For general reference, the HTML4 LINK tags are defined here

You can add your own, but if you do, you should use a profile statement. See the Dublin Core for the usual example.

For general reference, the HTML4 LINK tags are defined here

You can add your own, but if you do, you should use a profile statement. See the Dublin Core for the usual example.

Just look it up in the standard

Mozilla *is* made by Netscape. Yes, it's open-source, but most of the major contributors are Netscape employees who're paid to work on it. They then do an occasional code freeze, fix the most obvious bugs in the frozen version, add horrible branding, and call it Netscape 6.

The Gecko engine (Mozilla's renderer) has the advantage that, unlike NS4, it makes an effort to render non-legacy HTML correctly. Ever tried persuading Netscape 4 to work with perfectly correct Cascading Stylesheets? (Yes, I even tried running the W3C validator on them. They *were* valid.) It supports just enough CSS to try to parse the stylesheet, but not enough to get it right (overlapping images and text were a common problem for me). At the moment my website uses a loading method which *should* be supported, and is supported by everything else which uses CSS (IE, Mozilla/NS6, Opera, ...), specifically to trick NS4 into rendering the no-CSS simple-but-legible version instead of its broken half-CSS.

And that's quite impressive considering that

"Cascading Style Sheets, level 1 (CSS1) became a W3C Recommendation in December 1996."
-- w3.org

Netscape 6.x, Galeon, Mozilla, etc. use the mozilla rendering engine. Is it because it's parsing poor html? If more people used the validator, would it be faster?

No. No law was passed in Australia mandating Web accessibility.

Tables are perfectly OK for accessibility if their content makes sense when linearized, as is usually the case in nice rectilinear content blocks. Also, every screen reader in common use save for OutSpoken for Macintosh handles tables (and frames) just fine.

Next, lets go to your home page. No doc-type definition, so it doesnt validate. Bad. Plus you are using out-of-date tags. Check it here[w3.org].

I ran the site through the validator and got the response:

"Congratulations, this document validates as HTML 4.01 Transitional!"

Your posting might have had some credibility if you hadn't over-ridden the DOCTYPE of the document in the links you provided and if you hadn't been quite so selective in the pages you chose to reference.

The Oracle HOWTO page was a quickie that required only a couple of minor edits to bring into compliance.

The sites www.Erskine.edu and www.KentMcCarter.com are no longer under our control but the work we delivered validated. www.GaeaCorp.com does validate.

Perhaps you enjoy wasting your life away trying to put square pegs into round holes (or is it just a way to bill the customer for more hours?) but I will continue to support standards.

Standards-compliant HTML which works in all browsers is nice, but contradictory.

First off, there is no HTML Standard - only a WWW Consortium Recommendation. Secondly, there is more than one Recommendation, based on the DTD used to author the page. So making pages largely compatible involves using the relevant DTD for each User-Agent (note User-Agent, not browser). There's no point hacking an HTML4.01 Strict DocType to work in Netscape 3, since this browser implements a form of HTML3.2.

A lot of these myths and fallacies are covered by the document Publishing on the Web Is Different

Detecting browsers is often misused, but with older Javascript implementations the only way is sometimes to use a browser sniffer.

Never use a browser sniffer. MSN.com proved conclusively the idiocy involved in relying on User-Agent strings.

If only there was a standard function like browser.does("DOM_2") or something so you could switch by features rather than browser...

There is, and always have been. Javascript object-detection is a recommended way of determining a browser's functionality, so if(document.getElementById) {} identifies browsers that comply with W3C recommendations to DOM.

The one thing most web-designers are completely forgetting is that plain old HTML is supposed to be a document structure, not a layout format. Trying to force it to layout can only reduce the effectiveness of the structure, thus impair its future as a www-document.

With ideas like the Sematic Web approaching fruition, it is essential for webdesigners to concentrate on getting the document structure right first, then use CSS for layout.

Lets move beyond the fuzzy effects, and concentrate on the web's future. Its obvious msn have no clue about the web's potential as a global and open medium.

Standards-compliant HTML which works in all browsers is nice, but contradictory.

First off, there is no HTML Standard - only a WWW Consortium Recommendation. Secondly, there is more than one Recommendation, based on the DTD used to author the page. So making pages largely compatible involves using the relevant DTD for each User-Agent (note User-Agent, not browser). There's no point hacking an HTML4.01 Strict DocType to work in Netscape 3, since this browser implements a form of HTML3.2.

A lot of these myths and fallacies are covered by the document Publishing on the Web Is Different

Detecting browsers is often misused, but with older Javascript implementations the only way is sometimes to use a browser sniffer.

Never use a browser sniffer. MSN.com proved conclusively the idiocy involved in relying on User-Agent strings.

If only there was a standard function like browser.does("DOM_2") or something so you could switch by features rather than browser...

There is, and always have been. Javascript object-detection is a recommended way of determining a browser's functionality, so if(document.getElementById) {} identifies browsers that comply with W3C recommendations to DOM.

The one thing most web-designers are completely forgetting is that plain old HTML is supposed to be a document structure, not a layout format. Trying to force it to layout can only reduce the effectiveness of the structure, thus impair its future as a www-document.

With ideas like the Sematic Web approaching fruition, it is essential for webdesigners to concentrate on getting the document structure right first, then use CSS for layout.

Lets move beyond the fuzzy effects, and concentrate on the web's future. Its obvious msn have no clue about the web's potential as a global and open medium.

Standards-compliant HTML which works in all browsers is nice, but contradictory.

First off, there is no HTML Standard - only a WWW Consortium Recommendation. Secondly, there is more than one Recommendation, based on the DTD used to author the page. So making pages largely compatible involves using the relevant DTD for each User-Agent (note User-Agent, not browser). There's no point hacking an HTML4.01 Strict DocType to work in Netscape 3, since this browser implements a form of HTML3.2.

A lot of these myths and fallacies are covered by the document Publishing on the Web Is Different

Detecting browsers is often misused, but with older Javascript implementations the only way is sometimes to use a browser sniffer.

Never use a browser sniffer. MSN.com proved conclusively the idiocy involved in relying on User-Agent strings.

If only there was a standard function like browser.does("DOM_2") or something so you could switch by features rather than browser...

There is, and always have been. Javascript object-detection is a recommended way of determining a browser's functionality, so if(document.getElementById) {} identifies browsers that comply with W3C recommendations to DOM.

The one thing most web-designers are completely forgetting is that plain old HTML is supposed to be a document structure, not a layout format. Trying to force it to layout can only reduce the effectiveness of the structure, thus impair its future as a www-document.

With ideas like the Sematic Web approaching fruition, it is essential for webdesigners to concentrate on getting the document structure right first, then use CSS for layout.

Lets move beyond the fuzzy effects, and concentrate on the web's future. Its obvious msn have no clue about the web's potential as a global and open medium.

Since when was <p> deprecated? No sign of it here... XHTML v1.1 tags list

<p>Use of <p> as a glorified line break is deprecated. It's a non-empty tag. It surrounds a paragraph, like this one (since I'm posting in HTML anyway, I've faked an extra p tag to illustrate it). I suppose use of <p> as anything except a paragraph is also deprecated.</p>

Actually, it's more important than <div> - a div tag has no particular significance (it's just a box with linebreaks for CSS and scripting to refer to), whereas a p tag definitely represents a paragraph (complete with conventional formatting like blank lines, which you can change to indents or something with CSS if you so wish). Remember, if you want unreadability, write continuous text; if you want legible writing, paragraph it (or that's what they told me at school anyway :-)

Indeed, the first tags Dave Raggett's HTML tutorial (hosted by the W3C) describes are title, h1 to h6, and p.

The problem is that in order for all browsers to see everything, a web site would probably have to use HTML 1.0, resulting in a very boring web. More current technologies aren't standards based since they are so new. Where does it stop? Everything must be compatible with Mosaic 1.0?

I disagree. There are at least two ways to provide content for web browsers that don't support the latest standards. The first is to detect the browser and display for it, and the other is to design degradable pages - which is the proper way to do it, and what the w3c has been continuously trying to encourage people to do for the last ten years. (Except for a couple of looney years when HTML 3.2 was around.)

Right back since HTML 2.0, which was the first stable formal release of an HTML spec, the w3c has requested that user agents ignore what they don't understand.

If you look properly at the HTML 4.01 or even better the XHTML 1.0 strict spec (which is basically the same thing except with an XML syntax enforced), the whole thing is rigged around building a page using only basic markup like headings, paragraphs, lists, and so on. Nearly everything to do with formatting has been deprecated, except for what was more or less available in HTML originally.

The HTML syntax has been reduced to the one for providing the actual information - or that's what the intention is, at least. All of the cool looking stuff has been moved to other specs like CSS (which is approaching version 3), that are defined externally and linked to the HTML file. With the most modern standards, it's possible to take a very basic HTML web page of marked up information, and turn it into a flashy, presentational marvel. That is for people who choose to use browsers that display those extentions. At the same time however, it doesn't prevent blind people from getting directly to the information. It doesn't prevent people using lynx.

IMHO, good web design should always put the information part on the HTML and build the presentation around it. The alternative is serving browser-specific content, but that's really ugly because your server needs to know about all the different browsers, and it needs more server hardware for the extra processing.

The time where it is useful is for web browsers that think they support a certain standard and act like they support a certain standard, but then completely screw it up. Netscape 4 does this with CSS. Some of the earlier browsers do it with javascript, and so on.

It's not just legacy browsers that don't support modern standards, it's modern browsers that don't work in visual media. For example, tell me how a speech browser would support the tabbed menu selector at the top of MSN in a way that would convey "The Microsoft Network Experience". And yet you can be sure it supports all the standards that are relevant to its media.

The thing is that it's always supposed to have been up to the user agent on the user end to decide how to present the content. That's why web servers serve up markup instead of images. I wish more managers out there would understand that. Incidently, does anyone know if Microsoft was letting in MSIE clients who had CSS and/or Javascript disabled? I forgot to check.

My feeling now is that Microsoft has just recently used some hypocritical doublespeak and screwed over a general management view of how web standards are supposed to work, stating some of the facts but ignoring the most important ideals that they're there for.

The W3C has links to many validators here. Go test your website(s) with them.

The W3C has links to many validators here. Go test your website(s) with them.

"Please point me to the part of the table standard (or even the CALS derivation that spawned it), that say you should not use tables for presentation or layout."

Here you go.

From the HTML 4.01 Specification, Section 11.1: Introduction to Tables:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

From the Web Content Accessibility Guidelines 1.0, Guideline 5. Create tables that transform gracefully.:

Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables").

"Please point me to the part of the table standard (or even the CALS derivation that spawned it), that say you should not use tables for presentation or layout."

Here you go.

From the HTML 4.01 Specification, Section 11.1: Introduction to Tables:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

From the Web Content Accessibility Guidelines 1.0, Guideline 5. Create tables that transform gracefully.:

Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables").

"Please point me to the part of the table standard (or even the CALS derivation that spawned it), that say you should not use tables for presentation or layout."

Here you go.

From the HTML 4.01 Specification, Section 11.1: Introduction to Tables:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

From the Web Content Accessibility Guidelines 1.0, Guideline 5. Create tables that transform gracefully.:

Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables").

"Please point me to the part of the table standard (or even the CALS derivation that spawned it), that say you should not use tables for presentation or layout."

Here you go.

From the HTML 4.01 Specification, Section 11.1: Introduction to Tables:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

From the Web Content Accessibility Guidelines 1.0, Guideline 5. Create tables that transform gracefully.:

Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables").

Strange...I tested Mozilla with captions and it displayed the text just fine. You aren't referring to ALT attributes on IMG tags, are you? ALT attributes are not meant to be used as captions, you know. For user agents that cannot display images, forms, or applets, [ALT] specifies alternate text. Yes, IE will display a tool tip with the ALT content when you hover over an image, but that is NOT a standard implementation or use of an ALT tag. A decent screenreader should know how to interpert ALT tags in pages.

What do you mean, IE has a better UI than Netscape 6.1? I'd prefer Mozilla's UI to IE's any day. Netscape 6.1 is not much different. UI is a subjective thing...what you really mean is that you like IE's UI better... ;)

DennyK

Strange...I tested Mozilla with captions and it displayed the text just fine. You aren't referring to ALT attributes on IMG tags, are you? ALT attributes are not meant to be used as captions, you know. For user agents that cannot display images, forms, or applets, [ALT] specifies alternate text. Yes, IE will display a tool tip with the ALT content when you hover over an image, but that is NOT a standard implementation or use of an ALT tag. A decent screenreader should know how to interpert ALT tags in pages.

What do you mean, IE has a better UI than Netscape 6.1? I'd prefer Mozilla's UI to IE's any day. Netscape 6.1 is not much different. UI is a subjective thing...what you really mean is that you like IE's UI better... ;)

DennyK

TBL is absolutely right. The foundation for a free Internet is standard compliance. But where are we when not even Slashdot is W3C HTML compliant???

I tried to validate it at validator.w3c.org, but I got more than 600 errors!
Try for yourself

No Goat is hidden here

Brisbane Tourism

travel info

Drool sheets

local W3C node

A rather interesting fact ... they recently put on HPCAsia 2001 where they revealed that Brisbane has not one, but THREE Virtual Reality facilities (UQ, QMI, Boeing). According to their blurb, they're involved in the Japanese Whole Earth Simulator (4 Teraflops), something called a Virtual Reef, as well as using it for designing their scramjets. Actually after rummaging around the AUUG website a more interesting workshop to attend would be their security symposium in Nov.

My first thought was to see what the HTML Validator at HTML Validation Service had to say about their www.msn.com page. MSN seems to be blocking it, 'cause it gets the "browser upgrade" page too.

... And even that simple page fails the validation.

I would guess that the server side code is checking the user agent field very early in the page generation process, so that later on their html generation code doesn't need to do that check.

I used IE to save the complete page and uploaded the html file to the W3C validator. This page fails on the first line - the DOCTYPE! The document claims HTML 4.0, while the validator expects HTML 4.01. So much for using the latest HTML standards

Good thing the main page doesn't even validate as XHTML 1.0 strict...

Funny, the W3C doesn't seem to think so...

and what the f..k is this ??? How can we stay here bitching about how site www.something.com is not w3c compliant whe /. itself isn't too ??? I'm a /. and opensource supporter, but sometimes it's neccessary for me or someone else to play devil's advocate.

If M$'s reason for keeping out other browsers is that they don't follow the W3C standards, then what is the excuse for this? [validator.w3.org]

in the article, the microsoft guy claims:

"Visse said earlier Thursday that the message would be shown to people using "browsers that we know don't support (W3C) standards or that we can't insure will get a great experience for the customer." W3C refers to the World Wide Web Consortium, which is developing industry standards for Web technologies."

Now begins the funny stuff:

http://validator.w3.org/check/?uri=http%3A//www.ms n.com

yes: even the W3C validator is bumped out by their restrictions, and, even more funny, the bump out text is NOT w3c-compliant !!!!

I think this is the best joke of the year from Redmond ! Kudos to those guys ! they're more funny than David Letterman and Michael Moore together !!!! :-)))))))

I tried to run MSN through W3 Validator, and it was validating the reject-page. Coincidentally, the reject-page is in broken xhtml.

If they will, as the article hints, submit these to the W3C then bear in mind that Microsoft helped draw up the W3C's Patent Policy which requires a 'Reasonable and Non-Discriminatory' license.

Here is the (failed) validation of www.msn.com for people to see

If only reporters knew about things like this - it would have put some spice into the second article if the reporter had pointed out that msn.com provably didn't follow xhtml standards.

With web design, one day you have to stop supporting a browser. I can't code pages for Mosaic - it's just too old.

At some point you have to say "that browser is to old". And then you work accordingly. What this means is you create two design - one fancy for new browsers, and one simple for old browsers. How do you tell them apart? From the user agent string. The UA string is fairly arbitary, but then choosing which design you display isn't a matter of life and death.

One example website I did was Oscillations. It has a look at the user agent string, and if you are using Netscape Navigator 4 it will give you a crusty version. (This can be set in your user preferences on the website.)

Is creating two version a problem? Not if you mark your pages up according to the standard.

What MS has done here is completely different: it is discrimination, through and through. Not only that, but they are violating the standards of the W3C that they proclaim they follow. Look: Web Content Accessibility Guidelines 1.0: Guideline 6. Ensure that pages featuring new technologies transform gracefully..

Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.

Also to call any browser other than those written by Microsoft outdated (as their intro message does) is pretentious BS. Fact is, IE5 sucks when it comes to standard. Half the workarounds I have to write are for that crate of tripe. Complete and utter bollocks. I have nothing but contempt for Microsoft and their decision to display that message.

Please, I encourage you to submit a Web Accessibility Initiative report that details EVERY aspect of their page that sucks. Here is a sample.

Please, I encourage you to submit a Web Accessibility Initiative report that details EVERY aspect of their page that sucks. Here is a sample.

Please, I encourage you to submit a Web Accessibility Initiative report that details EVERY aspect of their page that sucks. Here is a sample.

i ran msn.com through the validator at w3c.org. as you can see from the result, the validator doesn't even get through (as has been said before). but it is as easy to see that not even their 'sorry your web browser does not support this site' is not w3c standards compliant!

i would post the output of the validator, but hey, the 'lameness filter' killed that idea in a heartbeat.

-sam

And yet: this1 is what the w3c validator thinks of www.msn.com

"Sorry, this document does not validate as XHTML 1.0 Strict." - W3C validator.

<td width="150">
Error: there is no attribute "border" for this element (in this HTML version)

</input>
Error: end tag for element "input" which is not open; try removing the end tag or check for improper nesting of elements

I tried to run the page through the HTML validator but noticed that it just checks the page suggesting IE so I download the source using the OmniWeb, and ran validator on that. I got 20 errors.

If you are seeing this page, we have detected that the browser that you are using will not render MSN.com correctly. Additionally, you'll see the most advanced functionality of MSN.com only with the latest version of Microsoft Internet Explorer or MSN Explorer. If you wish to visit MSN.com, please select the appropriate download link below.

• Internet Explorer for Windows
• Internet Explorer for Macintosh
• MSN Explorer for Windows

Errors/warnings in http://www.msn.com/
line 1, char 280: Unknown XHTML attribute topmargin
line 1, char 280: Unknown XHTML attribute leftmargin

Also doesn't seem to validate too well with the W3C HTML validator either.

Standards indeed.

Errors/warnings in http://www.msn.com/
line 1, char 280: Unknown XHTML attribute topmargin
line 1, char 280: Unknown XHTML attribute leftmargin

Also doesn't seem to validate too well with the W3C HTML validator either.

Standards indeed.

On cnet.com they quote
"All of our development work for the new MSN.com is...W3C standard," said Bob Visse, the director of MSN marketing, referring to the World Wide Web Consortium, which is developing industry standards for Web technologies. "For browsers that we know don't support those standards or that we can't insure will get a great experience for the customer, we do serve up a page that suggests that they upgrade to an IE browser that does support the" standards.

On the other, if you go to the w3c validator you get 4 errors for www.msn.com and msn.com.

'"All of our development work for the new MSN.com is...W3C standard," said Bob Visse, the director of MSN marketing.'

So is it actually standard? According to http://validator.w3.org/check?uri=http%3A%2F%2Fwww .msn.com%2F&charset=%28detect+automatically%29 &doctype=Inline, nope: there are 4 errors. Unsurprisingly, the page it is validating is, of course, not the actual MSN home page. Evidentally, the W3C doesn't understand the latest W3C standards. Now, admittedly, I'm not sure anyone actually understands the most recent XHTML spec, but it's a bit unkind of MSN to say so.