I addressed it briefly in my previous post, the one where Opera learns to talk, but I want to elaborate more in this post, since I think the World Wide Web Consortium (W3C) doesn't lead the web to it's full potential, but rather leads it into the world of complex languages that are device specific. I guess that we actually want to have something that can be accessed on all devices without the need for browser checks or other kind of support checks (at least have access to the most important thing, content). Let's start with the SVG specification. It is utterly complex and tries to define everything that is needed for an application instead of defining what you would expect from a vector graphic language. Because the specification is that large and the working group didn't look into incompatibility problems with other specification it can't be implemented on mobile devices directly. The W3C released two separate SVG profiles for mobile devices; I would like to name the word useless.
How on earth am I supposed to write an application for both mobile devices and "normal computers"? Indeed, according to the W3C I would need to use different files with markup each specific for the device that retrieves it (if($browser == "IE")...). This is mainly because the working group tries to incorporate everything into the specification. And more, it creates dependencies on other specifications. Where you can use HTML or Web Forms 2.0 without something as complex as XML Schema, you need that 800 pound specification for XForms, along with support for a complex selecting language, called XPath, event handles, XML Events and other specifications. And of course, because you need to support XML Schema there needs to be a separate XForms Basic Profile for mobile devices which means you can't use the same page. (XML Schema is so damn complex it shouldn't be implemented on current mobile devices.) This is not the case with Web Forms 2.0, where web authors probably only need to apply different style sheets. And that isn't hard, since it is in fact a feature of CSS to provide different style sheets for different media. (Exactly, using a single document with multiple representations instead of having multiple documents with multiple representations; the way it looks the W3C is going.)
It seems that the various working groups are not working together closely or asking each other on their profession. Although SVG is some kind of styling language it does use CSS and some parts of the specification are created in such a way that they are incompatible with CSS (and other) specifications. SVG does also not have the flexibility of CSS like easily switching colors when an alternate style sheet is selected. You probably need to use XSLT for that job, which would create another dependency for small devices that even desktop browsers haven't implemented. (And using XSLT is probably not a good thing, since it shouldn't be send over the wire.) It is also that SVG isn't really meant to be combined with other languages such as XHTML; it is designed to suitable for stand alone applications. When I first heard that I was wondering where they got the semantics from, since SVG is more stylish than your FONT element could ever be! I still don't know.
One of the problems is probably that most of the people who work at the World Wide Web Consortium are not practical people. This reminded me of a post made by Russell Beattie, PHP Web Projects Continue to Impress Me, where he states in the end:
I think it's because PHP programmers want to get stuff done and Java programmers are geeks who want do stuff the "right" way. I'm getting sick of being in the latter camp.
While this may not be exactly the same as we put the W3C versus the WHATWG I do see some similarities. The latter is obviously not a standard organization, but it is a working group that tries to create something authors can work with today, not in 20 years. I can hear the argument that XForms has this great formsPlayer plugin for Internet Explorer (there is even a MathPlayer, but I don't think that is a good one or helps the language to evolve in a forward compatible manner:
text/html MIME type for something that is clearly XML and should have an application/xml MIME type. This basically means that the example is rendered as HTML tag soup in any browser. This also means that you will create compatibility problems with other implementations. (I'm not even sure if this works together with the MathML player, which requires application/xhtml+xml I believe.)
(I don't really dislike XForms by the way; I just don't think it is practical to have right now. Things like Web Forms 2.0 have far more potential and they are understandable for everyone. For people who like to think hard about things, it might be a good time to take a look in the real world and see what is happening. Learning XML Schema, XPath, XML Events, Namespaces and more isn't something everyone likes to do to create a (simple) feedback form. The XForms dependency is one of the parts I dislike from XHTML 2.0 as well. I don't really care it isn't backwards compatible, I can do things with HTML 4.01 along with some extensions for now (using XHTML 2.0 on the server), I just don't like the dependencies on things like XForms. (The meta data profiles are kind a tough too for new people, but you don't have to use them.) In case there was any doubt, I don't like the SVG application thing. SVG should take down in size and focus on being a graphic language. (Not that it will ever happen.))
I haven't read the SVG spec, but I'm very excited about its possible applications. From what I've read though, the working group behind it went mental and created an entirely new system (like you said). That's just stupid.
As for the WHATWG, the thing that put me off from the start was their comment on making their whole spec with Internet Explorer in mind.
I like the idea of XForms because it is based on XHTML/XML. I also like XHTML2. But I don't fancy having to learn half-a-dozen completely different languages to be able to do cool stuff.
I don't know where I was going with this. Nowhere I guess.
SVG 1.0 wasnt as bad, but it got worse with each design...adding more and more and more...even when it is in stuff like CSS where they already use...
but to stop myself from ranting already said stuff, well put Anne, very well put.
I'd just like to say a big loud +1 to this, Anne. Well put.
I've dabbled with SVG myself lately, but really only have been generating it from Illustrator, but what i've found that it is capable of is really astounding.
I use Illustrator on a daily basis and am well aware of what it is capable of (Yes that car is completely vector-based). SVG is almost capable of creating something that complex using the same methods Illustrator used to create them. Pretty much all it lacks at the current moment when creating this car is gradient meshes. It creates an image and then clips it with a clipping mask (I'm probably not using the actual terms that SVG refers to these things as, but what Illustrator calls them). I don't see a simple language creating something like that.
I've looked at the generated code myself to get an idea of what it's like and it's pretty deep stuff especially when drawing complex paths with attributes that are 30 lines long with nothing but coordinates for the points. I can see, myself, typing out SVG in a text editor for simple stuff, but for complex stuff i'll probably leave it up to Illustrator to generate it for me then go into the file and delete all the unnecessary bull Illustrator puts in there.
I don't know if many of the groups converse with each other or not. Seems that in some cases people within a particular group don't converse with each other either. XD
