- 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>
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 future. >>Suggestions for how to improve this situation would be most welcome, of >>course. > >Do a switch on the media type is the obvious answer. We already do a switch on the media type. See e.g. <http://validator.w3.org/check?uri=http://validator.w3.org/base.css>. 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