Slashdot Mirror

Have you found that these services are applying modifications to requested pages that specifically state not be cached with the no-cache option? Have you found these modifications to also apply to AJAX requests?

At W3C we log almost everything as well, and we end up with way too much data as a result.

But we use the logs to detect and prevent certain classes of abuse as well (e.g. too many requests in a short time interval or re-requesting the same resources over and over), and we also want to be able to track trends over time, so we have been reluctant to just throw that data away.

I have a plan that I have yet to implement, which is to log only 0.001% of the requests for certain very popular resources (e.g. HTML DTDs and valid-HTML icons), which would allow us to monitor trends without logging tens of gigs of data per day; we'd just need to compensate for it when calculating stats later.

Then I planned to monitor for abuse by also logging every request to a script that watches for abusive traffic patterns, an easy adaptation from the current script that wakes up and skims the logs every 10 mins.

(in your journal entry, when you say you are MD5ing IP addresses for privacy reasons, are you adding a random bit of data to the IP address before calcuating the MD5? If not it's pretty easy to find out which IP address corresponds to a given MD5 sum.)

At W3C we log almost everything as well, and we end up with way too much data as a result.

But we use the logs to detect and prevent certain classes of abuse as well (e.g. too many requests in a short time interval or re-requesting the same resources over and over), and we also want to be able to track trends over time, so we have been reluctant to just throw that data away.

I have a plan that I have yet to implement, which is to log only 0.001% of the requests for certain very popular resources (e.g. HTML DTDs and valid-HTML icons), which would allow us to monitor trends without logging tens of gigs of data per day; we'd just need to compensate for it when calculating stats later.

Then I planned to monitor for abuse by also logging every request to a script that watches for abusive traffic patterns, an easy adaptation from the current script that wakes up and skims the logs every 10 mins.

(in your journal entry, when you say you are MD5ing IP addresses for privacy reasons, are you adding a random bit of data to the IP address before calcuating the MD5? If not it's pretty easy to find out which IP address corresponds to a given MD5 sum.)

At W3C we log almost everything as well, and we end up with way too much data as a result.

But we use the logs to detect and prevent certain classes of abuse as well (e.g. too many requests in a short time interval or re-requesting the same resources over and over), and we also want to be able to track trends over time, so we have been reluctant to just throw that data away.

I have a plan that I have yet to implement, which is to log only 0.001% of the requests for certain very popular resources (e.g. HTML DTDs and valid-HTML icons), which would allow us to monitor trends without logging tens of gigs of data per day; we'd just need to compensate for it when calculating stats later.

Then I planned to monitor for abuse by also logging every request to a script that watches for abusive traffic patterns, an easy adaptation from the current script that wakes up and skims the logs every 10 mins.

(in your journal entry, when you say you are MD5ing IP addresses for privacy reasons, are you adding a random bit of data to the IP address before calcuating the MD5? If not it's pretty easy to find out which IP address corresponds to a given MD5 sum.)

Well yeah. That's kind of the entire point of web pages - you look at them visually.

No, but the vast majority do. In excess of 99% I'm guessing.

Regarding your last point: You're assuming that phone browsers miraculously know which bits of the CSS to change so it looks good on a phone screen.

If your menu is in the leftmost cell, then typically this gets rendered first and the rest of the page gets rendered below this. This is no different to how it would render on a text-based browser or mobile-browser if you implemented it in CSS.

The title should have read The Complete History of A/V Format Wars. Here I thought that it was going to document such things as CDF versus RSS versus Atom.

Opera has a content blocker (a fancy name for an ad blocker), not a site blocker....You would have noticed the name and the behaviour if you actually tried to use Opera.

As for Firefox and Google, back when Gmail appeared... blah blah blah... - only two browsers are coded for, the rest are usually ignored.

a bug was submitted for Gecko not being able to properly render "display: inline-block"

it's not a nice ecosystem browsers have to play in

addEventListener remains so completely broken in Gecko that KHTML/Webkit and Presto have been strong-armed into violating the specs

Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS.

It's trivial. It's a bit more complicated if you are talking about the subset of HTML and CSS that Internet Explorer supports, but there have been established techniques for years.

Let the user become the crawler- and do not eliminate the search giants (just don't rely on them completely). Already I sort of operate like a (slow) crawler with my queues of links to read, bookmarks (be weary- big load) and indexing those very interesting or important pages, sharing related tidbits, etc. Just feels like the natural extension, though I am sure that many people will want to stick with traditional GUIs and "back/forward" habits. There is also some interesting discussion in ATLAS-L re: future search infrastructures. So, in the spirit of promoting development in this area, linkage:

* Grub article (now defunct)- was distributed peer-to-peer crawler. (see also)
* Boitho, another distributed crawler
* YaCy- another peer-to-peer crawler
* How to build a web spider
* C++ web crawler lib
* LibWWW (perl)
* W3C's WebBot
* The Internet Archive's Heritrix crawler
* WebSPHINX- customizable crawler

Somehow, this is like an extension of surfraw. I imagine that soon enough we will start up an open source crawler-browsing hybrid software package, though have been surprised that nothing like it has popped up yet- it's (usually) the way of the programmer to make sure that he has the ability to do what the giants are doing. Maybe we have all been collectively blinded by graphical web browsers (IE, Firefox, Opera, etc.) and "click-click-click" thinkware?

No, you don't need those things. You think you do, but you don't. The internet was intended to spread information. Text and hyperlinks are a great way to get that across. But somewhere, someone(s) started playing with other types of content like images, animated images, built-in programmability (Javascript/ECMA script), and embedded programs and other types of media (flash, video, audio).

Information is not just text. The architecture of the web was to allow *any* resource to be hyperlinked, including mobile code. The web never would have become a popular medium (no more than Gopher was in 1993, anyway) if it were just text on a screen. The addition of IMG and TABLE had a lot to do with its growth.

Therefore, I believe it is much better to take a conservative approach to adopting standards that go beyond basic text.

Do you even live in the same world as we do? It's not the 1980's man.

XHTML offers one big benefit that many bad web developers, like yourself, fail to see. That is strict parsing and failures associated with parse errors

XHTML offers one big downside, that many bad programmers, like yourself, fail to see. It doesn't follow the Robustness Principle.

The point is not that there should be warnings about bad markup, but a user agent shouldn't reject it completely. Whereas XML parsers tend to blow up way too easily.

You can't enforce strictness unless you control both the producer & consumer code. A diverse marketplace of parsers and editors and renderers makes for a mess, and strictness just forces end-users to deal with the mess (denying access due to strictness), when it's not their job. It takes *years*, if not decades, for multiple code lines to interoperate on a complex standards. As an example, for a long time, there was only one mainstream implementation of the TCP/IP stack out there: BSD.

Beyond this, there's an issue of evolvability & extensibility. XML has been twisted beyond recognition by misguided attempts to impose order and predictability with the introduction of XML Schemas. Whoops, there goes the extensibility. Oh, but I can version my schemas & design for extensibility! Actually, that's a pretty hard thing too that they're still working on fixing. In particular, the Unique Particle Attribution rule has had a major stifling effect.

There's one good feature of XHTML, today, in my opinion: parsing is cheaper for Microformat consumers. Good HTML parsers are hard to come by, XML parsers are a dime a dozen.

The "rules" are stupid. Do you know how hard it is to make a 3-column or 4-column content site using CSS 1.0? Is it even possible? Yet I can "break" the rules, use table cells as layout, and accomplish the same thing in seconds.

<html>
  <head>
    <style>
    div { display: table;
          width: 50%;
          border: 1px solid;
          border-collapse: separate;
          border-spacing: 1em; }
    p { display: table-cell;
        border: 1px solid;
        padding: 1em; }
</style>
  </head>
  <body>
    <div> <!-- the div is only here to indicate the width and borders -->
        <p>The "rules" are stupid. Do you know how hard it is to make a 3-column or
        4-column content site using CSS 1.0?</p>
        <p>The "rules" are stupid. Do you know how hard it is to make a 3-column or
        4-column content site using CSS 1.0? Is it even possible? Yet I can "break"
        the rules, use table cells as layout, and accomplish the same thing in seconds.</p>
        <p>Is it even possible?</p>
        <p>Yet I can "break"
        the rules, use table cells as layout, and accomplish the same thing in seconds.</p>
    </div>
  </body>
</html>

But that isn't a liquid layout, i.e. one in which all three columns can change size to fit their content, like the GP asked for. It's necessary to fix the size of at least one of the columns to make it function with the CSS that's implemented by common browsers.

No, it is perfectly doable in CSS 2.1 without anything complex. Create three DIVs right next to each other with the style "display:table-cell" and they will stick and form to each other just like table cells would. (Relevant lines from the spec.) You could specify their widths, or do whatever you want. Now, every current browser out there has supported this for some time with the exception of Internet Explorer, but the original parent didn't ask about support, but specs.

Really, if IE had started supporting this when everyone else had, columns wouldn't even be a discussion now. As it stands, because IE doesn't support it, it's a headache to everyone. Personally, I'm of the opinion that you do display:table-cell and then make a special case for IE to get it to display the same. It saves a lot of trouble trying to get complex styling to work the same in IE and everything else.

It is worth noting that there is a new "column" style specified in the CSS3 drafts. It is a different type of column, like columns from a newspaper. If you have a really long text, you can have it take up the same area, but split into X number of columns, or columns of Y width. It's useful, but not the same as the 2/3 column page designs on the web right now.

Even the earliest version of the CSS 2 spec has passed its ninth birthday.

Why should a web developer use a brand new web standard that requires the use of such an outdated and difficult-to-use spec? Making web pages to standards won't be worth the extra time until 90% of surfers are using fully CSS3 compliant user agents. That still looks a long way off.

And then, no doubt, people like you will be telling us that there's no point in making web pages to standards until 90% of users are using fully CSS4 compliant user agents.

Anyhow, since when is CSS 2 'outdated'? Not only was the CSS 2 spec most recently updated YESTERDAY, but it's a specification that's actually tailored to the real-world implementations:

CSS 2.1 represents a "snapshot" of CSS usage: it consists of all CSS features that are implemented interoperably at the date of publication of the Recommendation.

As for your claim that the CSS specs are 'difficult-to-use,' in what profession other than web development have you ever heard so many people whine about having to learn the basic tools of the trade?

which the browser would automatically know about as a date field and have its own built-in popup calendar for browsing dates

XForms, the W3C's forms module for XHTML, has this.
You just mark the data as type date and it does it for you.
The control is still input.

See XForms 1.0 and XForms 1.1 which is nearly done. There's support for this feature in the native implementation for Firefox, which is presently at about version 0.8.

So, you put the data in your XML data section (just like the Ajax stuff does), then you put your data type declarations in (string, boolean, date, email address, enumeration, etc), and then you use the tags inside your XHTML to refer to the data. It's exactly a three-layer model.

which the browser would automatically know about as a date field and have its own built-in popup calendar for browsing dates

XForms, the W3C's forms module for XHTML, has this.
You just mark the data as type date and it does it for you.
The control is still input.

See XForms 1.0 and XForms 1.1 which is nearly done. There's support for this feature in the native implementation for Firefox, which is presently at about version 0.8.

So, you put the data in your XML data section (just like the Ajax stuff does), then you put your data type declarations in (string, boolean, date, email address, enumeration, etc), and then you use the tags inside your XHTML to refer to the data. It's exactly a three-layer model.

To stop writing new standards and failure modes and focus on their QA efforts while existing browser projects catch up to the existing standards. As a developer and end-user of the results of both the standards and browers, there has been a piss-poor effort of ensuring and evaluating how well each browser satisfies a standard.

They do if you actually tell the browser that you're sending XHTML, and that the browser even knows what that is. Haven't you ever seen what happens if you send invalid XHTML markup with the correct mime-type; application/xhtml+xml? It throws parse errors like any good compiler. The problem is that most developers are too lazy to do this since it requires work-arounds for, you guessed it, Internet Explorer since it still doesn't support XHTML.

Out of all of those things, the only one that's changed at all is the img tag, and that's only in two places - first, in XHTML you are required to provide an alt= attribute (instead of just strongly recommended like in HTML 4), and second, you have to close the tag properly, with a /> at the end.

Not quite. The alt attribute is required on img elements in HTML 4.01 too. A fortiori to your argument though.

Microsoft can't change how IE handles web pages, because they will break all the sites that were written to depend on IE6's behaviour. They did make some changes in IE7, but they were burnt by the experience and don't want to do it again - see Chris Wilson's comments:

IE7 did cause widespread disruption, as a case in point. I championed making those widespread changes to improve our standards compliance. In all seriousness, I've managed to hang on to my job, but sometimes I think only just. I cannot go to my team and say "hey, we're gonna break the web again (and again and again), but it's okay because it's for a good cause." The world doesn't work that way. I wouldn't be responsibly doing my job - that one where half a billion web users rely on my team to not hose compatibility with their banking web site, even if their bank doesn't know how to properly use CSS 'float'.

All the other browsers do reverse-engineer IE's behaviour, as well as each other's. HTML 5 is largely an attempt to document and standardise that reverse-engineering: anyone who wants to process the web has to do it in a way that's compatible with the real web, and the real web is written to be compatible with IE, so that has always been the de facto standard and now HTML 5 is making it into a real standard.

There are many cases where IE's exact behaviour is too insane to copy, but Mozilla and Opera and Apple have experience of what behaviour is close enough to work in reality (based on feedback from bug reports about broken sites) - so the result is something that should be sufficiently compatible with IE in all the cases which web authors depend on.

When you register, does that mean my email address and name are public?

Not explicitly, but if you participate in the mailing list your name and e-mail address will be visible via the Web archive.

The "rules" are stupid. Do you know how hard it is to make a 3-column or 4-column content site using CSS 1.0? Is it even possible? Yet I can "break" the rules, use table cells as layout, and accomplish the same thing in seconds.

Using CSS 1.0, that's probably impossible. However, that's not too surprising since that version of the spec didn't even pretend to offer much more than basic text formatting.

But besides that: CSS 1.0?! You do know that even the revised version of that spec is eight and a half years old, right? And that the original version of it is nearly eleven years old? Even the earliest version of the CSS 2 spec has passed its ninth birthday.

Web developers would use the standards if the standards reflected the reality of their job and *made it easier*.

In general the problem is not, and never has been, the specifications. The problem has always been the implementations. Once browsers started to actually do what the specification specified, the job suddenly got dramatically easier. Before about 2002 or 2003, the table-based -vs- tableless layout debate made some kind of sense. But since then, the widely-used browsers--even including IE 6 and all of its bugs--have become robust enough that if tableless layouts aren't making your job easier it's because you don't know what you're doing.

In the past 3 years, for example, I've used one base template for every HTML document I've created, and the actual structural markup probably changes less than 15% from the original in any given case--regardless of layout. I can change columns from side to side by changing three CSS declarations, and any number of columns can be added by adding one new div element per column to the markup. Pages built this way are also usable on small-screen devices with almost no alteration, and making pages that print well becomes absolutely trivial.

The "rules" are stupid. Do you know how hard it is to make a 3-column or 4-column content site using CSS 1.0? Is it even possible? Yet I can "break" the rules, use table cells as layout, and accomplish the same thing in seconds.

Using CSS 1.0, that's probably impossible. However, that's not too surprising since that version of the spec didn't even pretend to offer much more than basic text formatting.

But besides that: CSS 1.0?! You do know that even the revised version of that spec is eight and a half years old, right? And that the original version of it is nearly eleven years old? Even the earliest version of the CSS 2 spec has passed its ninth birthday.

Web developers would use the standards if the standards reflected the reality of their job and *made it easier*.

In general the problem is not, and never has been, the specifications. The problem has always been the implementations. Once browsers started to actually do what the specification specified, the job suddenly got dramatically easier. Before about 2002 or 2003, the table-based -vs- tableless layout debate made some kind of sense. But since then, the widely-used browsers--even including IE 6 and all of its bugs--have become robust enough that if tableless layouts aren't making your job easier it's because you don't know what you're doing.

In the past 3 years, for example, I've used one base template for every HTML document I've created, and the actual structural markup probably changes less than 15% from the original in any given case--regardless of layout. I can change columns from side to side by changing three CSS declarations, and any number of columns can be added by adding one new div element per column to the markup. Pages built this way are also usable on small-screen devices with almost no alteration, and making pages that print well becomes absolutely trivial.

I will never understand why HTML5 gains momentum while XHTML2 has become shunned. The page describing diffrences between HTML4 and HTML5 is chock full of "WTF?" moments: presentational tags coming back from the grave, new tags that fill niches narrower than a human hair, and new attributes that are simply bizarre. The ping attribute is so ripe for abuse (by marketers) that I can't even begin to describe how bad of a design decision it is. Other structural problems (such as the dl element's lack of internal organization) remain unaddressed.

XHTML may not have been developed that way everyone wants now, but it is a victim of circumstance: IE doesn't handle the application/xhtml+xml mime type at all. Is this the fault of the original XHTML working group? No, the blame for that lies at Microsoft's feet.

XHTML2 has elegant solutions which HTML5 eschews in favor of bloating its tag set. The role attribute could replace half a dozen or more of the new special purpose HTML5 tags. Adding href and src to nearly all the tags is another stroke of genius.

In a world which has embraced XML, why should the most public-facing specification of the W3C make XML compliance optional? Tag soup is for idiots, just like babushka tables. Some claim that XHTML was never embraced by developers. Which developers do they mean: the ones who have read and understand the standards, or the WYSIWYG monkeys who couldn't write a valid "Hello, world!" paragraph by hand if their lives depended on it?

I find it appalling that the W3C has allowed this usurpation to happen. And nothing against Chris Wilson personally, but him as the working group chair will probably have dire consequences eventually.

It's too hard to implement, because there is no default way it should look like. There is no default, standard stylesheet. What height is H1 supposed to look like by default?

I fail to see the difficulty. Headings aren't supposed to have a particular default height. What makes this difficult? Browser vendors can simply pick one themselves.

Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS.

It's trivial. It's a bit more complicated if you are talking about the subset of HTML and CSS that Internet Explorer supports, but there have been established techniques for years.

Fact is, HTML is based on a page/document model, whereas, nowadays, HTML "pages" are most of the time "screens", part of an application.

Part of Apple's philosophy is that applications should be based around the concept of documents, and they've been quite successful with it. A document model is not antithetical to applications.

most content in pure-ist HTML+CSS is basically a bunch of div's and span's.

This is not true. The idea is to use the most appropriate element type. <div> and <span> elements should only be used when there isn't something more suitable.

IMHO, if I were to redesign HTML today, it would look a lot like Xul, with XBL2 and microformats on top.

Please refer to the Rule of Least Power. It has all kinds of implications that make what you are suggesting a much worse idea than a document-based design.

Maybe I'll do that.

Interestingly, I think I found a Firefox bug on the "Public Account Request Form" that blog entry links to: http://www.w3.org/Help/Account/Request/Public . If I draw across the phone number text to select and copy it, my selection disappears as soon as I release the mouse button and the cursor instantly moves into the text field.

<!ATTLIST IMG
  %attrs; -- %coreattrs, %i18n, %events --
  src %URI; #REQUIRED -- URI of image to embed --
  alt %Text; #REQUIRED -- short description --
  longdesc %URI; #IMPLIED -- link to long description
                                          (complements alt) --
  name CDATA #IMPLIED -- name of image for scripting --
  height %Length; #IMPLIED -- override height --
  width %Length; #IMPLIED -- override width --
  usemap %URI; #IMPLIED -- use client-side image map --
  ismap (ismap) #IMPLIED -- use server-side image map --
  >

I have no idea what Microsoft Corporation's agenda is, but ever since they rejoined the CSS Working Group, the Internet Explorer team has been actively participating in the working group. Markus Mielke has been consistently pushing us to spell things out explicitly one way or the other rather than leave anything undefined; Paul Nelson, whose expertise is in internationalization and fonts, has volunteered to pick up some of the specs whose editors left the working group years ago; and Arron Eicholz and his QA team are working to contribute Microsoft's CSS tests to the CSS2.1 Test Suite. That's not the behavior of a group that wants to hold back standardization. Markus's team wanted to fix more bugs in IE7, but the release schedule didn't give them the chance to make many of the changes they wanted. I won't say anything about the rest of the company or how they handle such issues in other forums, but the reps Microsoft sends to the CSS Working Group genuinely believe in cooperating through the W3C and moving forward with web standards.

The problem seems to be that a significant percentage of web site developers lack the discipline or interest to follow rules. And, of course browsers don't necessary work with 'correct' documents. IE7 is said to still be out of compliance -- at least wrt CSS. Microsoft has the resources to make its browser standards compliant. Why haven't they? Beats me.

My take is that browsers should work with 'correct' HTML. I don't have any problem with non-compliant pages as long as the folks who generate them can make them work acceptably with real browsers. the latter is a lot of work, but some folks (e.g. Google) do pull it off.

The input element's type attribute now has the following new values:

• datetime
• datetime-local
• date
• month
• week
• time
• number
• range
• email
• url

Microsoft has several people participating in the HTML Working Group, and Chris Wilson, the leader of the IE team, is the chair of the group. So you don't have to worry about Microsoft being left out.

You jest, but it is actually that simple. HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.

The result is that browsers will show you the finger if you don't code to the standard.

I'm a participant in the HTML Working Group and I can tell you that this is incorrect. You're thinking of XHTML2, not HTML 5. XHTML2 has the XML parser strictness and pages will fail to display if they're not well-formed. HTML 5 is going the complete opposite direction, assuming that people will code poorly and defining failure modes for browser vendors to follow when that happens.

XSLT lets you format the final output of XML data in any way you want - seperating the content from the layout, in the same way that CSS lets you seperate the content/layout from the style.

Oh yes, and even Internet Explorer has XSLT support!

Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.

Don't believe me? Here are the two standards. Compare:

WHATWG HTML5
W3C HTML5

Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.

Uhhh.. you can still use for underlines. Oh, and you can always end your paragraph, start your list, then restart your paragraph. But then again, when people complain that they can't use &, I should probably leave well enough alone since they don't know about entity references.

Your argument is basically the same as saying "Why do we need a bold tag in HTML, why can't we just specify a style that uses a heavier weight?"

The difference is, HTML is not and never was intended to preserve a document pixel-perfect, the way PDF does. People do not have an unreasonable expectation that bold will look exactly the same on all browsers.

In fact, if you read the spec, you find that it does not expect identical implementations. They do provide an image of what it might look like, but the spec is intentionally vague in order to be flexible.

However, as I understand it, the reason for all this cruft in the OOXML "standard" is so that old documents may be preserved pixel-perfect, in complete implementations -- in other words, in Word 2007, since no one else can produce a complete implementation. And here's the huge difference -- if you look at the language of the HTML spec, it's intended that different browsers might display bold text differently. But if you look at the OOXML spec, it's intended that anyone implementing the SmallCapsLikeWord95 tag (or whatever) should implement it exactly like Word 95.

In other words, the HTML spec is exactly as vague as the standard is intended to be, while the OOXML spec wants you to implement it in a very specific way, but they won't tell you how.

Word processing documents are not just words with formatting (though many people treat them that way), they have tables of contents, links, indexes, styles, etc... semantic markup.

You just answered your own question:

Let's take an example. Suppose you have 10,000 legal documents written in Word 95, and many of them use "small caps" to indicate a specific legal meaning. Now, let's convert the documents to ODF, and those "small caps" are merely converted to a smaller font.

Well, I would actually define a style that is "SmallCapsLikeWord95", but which also defines that the capital letters use a smaller font. It may mean you need a more powerful style engine than ODF currently has -- but by "more powerful", I mean allowing a style to specify a separate font size for caps and lowercase, not having a built-in style that requires every implementation to carry around cruft from Word95.

The result: ODF can have a simpler implementation, while still preserving all the information you want it to -- including being able to search for all your SmallCaps stuff. And maybe now you start using styles properly -- you rename that "SmallCapsLikeWord95" style in the new document to something that reflects what you want small caps to mean.

As an update to my tongue-in-cheek comment, maybe they really are getting it:

Stylesheet

They're trying anyway--fails, but it's actually not that bad, looks like just typos.

As an update to my tongue-in-cheek comment, maybe they really are getting it:

Stylesheet

They're trying anyway--fails, but it's actually not that bad, looks like just typos.

As an update to my tongue-in-cheek comment, maybe they really are getting it:

Stylesheet
They're trying anyway--fails, but it's actually not that bad, looks like just typos.

As an update to my tongue-in-cheek comment, maybe they really are getting it:

Stylesheet
They're trying anyway--fails, but it's actually not that bad, looks like just typos.

How can anyone take ISO seriously when hardly a single one of the member bodies' web sites validate with W3. Hell, the Greek Member web site even uses some shitty Flash "intro"!

What a disgrace.

I wouldn't be advertising a website that horribly fails its validation, in a discussion about Web 2.0 greatness... http://validator.w3.org/check?uri=http%3A%2F%2Fwww .mapgroove.com%2F 87 errors.. ouch!