W3C home > Mailing lists > Public > www-validator@w3.org > February 2006

Re: Error Message Feedback: text/css not currently supported.

From: Terje Bless <link@pobox.com>
Date: Tue, 14 Feb 2006 00:22:15 +0100
To: Steven Pemberton <steven.pemberton@cwi.nl>
cc: www-validator@w3.org, Håkon Lie <howcome@opera.com>
Message-ID: <A0202000e-1044-9C9529AE0F914D6DABE66F4CC4FE749F@pounder.neutri.no>

Steven Pemberton <steven.pemberton@cwi.nl> wrote:

>>While there is, obviously, a W3C CSS validator, the W3C Markup
>>Validation Service does not, for obvious reasons, support checking CSS.
>I don't follow the "for obvious reasons".

Ehm. I should perhaps have emphasized the “Markup” part of the name. :-)

>validator.w3.org could very
>easily distinguish the media type and forward it to the correct parser. I
>don't see why the user need to be aware of different validators when it
>is so easy to automatically distinguish which one is needed.

Well, there are user interface issues involved but that's somewhat out of scope
for this discussion. But to the point, the current state of affairs is that this
is simply not technically feasible now or for the foreseeable future; for the
reasons Nick outlined and for simple lack of development resources.

>Why make all clients upgrade whenever W3C adds a new validator, when it
>only needs to be done once at the server?

I'm tempted to make quips about XHTML 2.0, but I'll try to restrain myself. :-)

The relevant URL is one of the two most used such tools and they've been stable
for more revisions of the main browsers than I care to remember. We're not
talking about retrofitting raw UTF-8 support in all mail server installations in
the world (a task which was seriously considered at one point!), and a
theoretical changed URL here could be “upgraded” through a copy&paste to text a
field in a settings dialog if need be.

Your point is well taken, but the accumulated effort of maintaining this
client-side in all current browsers is still far far less than what it would
take to implement what you suggest centrally.

What you suggest is a complex and heavy-handed — if arguably elegant, powerful,
and convenient — way to go about the task. It's not in general a bad idea to
rather find the lowest level of technology that can possibly work and deploy
that. In this instance, that means the clients of the service have to maintain a
few URLs which might possibly conceivably change or expand at some point in the

>>Suggestions for how to improve this situation would be most welcome, of
>Do a switch on the media type is the obvious answer.

We already do a switch on the media type. See e.g.

The problem is that this (low-tech) approach only works for a very limited
subset of cases (i.e. GET on a reachable URL), and Opera, due to the way they've
elected to implement the relevant feature (POST of the private document), always
falls afoul of this limitation.

To provide a more advanced version of this functionality — which we've
discussed, to be sure, and have taken some baby steps towards — would require
significant development resources which just simply aren't available (the tools
are maintained entirely by volunteers except the few hours Olivier can allocate
to them in between his other duties).

  «Terje, you are a sick and twisted individual, and I
   think I speak for all of us when I say, “Thank you!”»

               -- John Gruber <gruber@barebones.com>
Received on Monday, 13 February 2006 23:23:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:47 UTC