You might have read: Web Applications and Compound Documents, IMHO and Future of the Web, a must-read, which both refer to The W3C Workshop on Web Applications and Compound Documents and Position Paper for the W3C Workshop on Web Applications and Compound Documents (from Opera and Mozilla). The problem is, in my opinion, that these "critics" don't get the attention they deserve. People don't really think, nor bother about it. When Jeffrey Zeldman goes into length about a bug in the validator the complete web community is there to complain along with him. When Ian Hickson posts about Flash (he doesn't even have plugin) everyone likes it. However, when he posts about the future of the web, where we are heading and where we could have been, nobody is seems to be interested. Probably because it is either to technical or not presented in a way Jeffrey Zeldman can (I mention Jeffrey Zeldman, but I think that Mark Pilgrim or Dave Shea to name some people, could easily do the same thing).
The future of the web is very important and if you hear from Daniel Glazman that there were proposals to extend HTML in 1998 you ask yourself why they started to work on enormous specifications that are not interoperable, like XForms or SVG (SVG is worse, the editors completely ignore other specifications, like CSS, which makes stuff not work interoperable across XML documents). Currently we have XHTML 1.0, which works in a way cross browser (the markup purists, call that evil). The next version will not work in those browsers, while it has been more or less announced that development stops on that particular, lots of users use it, browser.
The W3C seems to be trying to describe the perfect web and while that is a perfectly valid goal, the steps they take are enormously and far too difficult for Harriet. Not only are they too difficult to follow for the average user, a lot has to be supported to implement it in a browser. The HTML working group has worked for four years I believe to come up with XForms and while it may be a great thing for large set ups it is clearly not something one wants to use on the web. One might wonder what their goal is.
Web Forms 2.0 on the other hand (not a W3C specification) is almost directly clear and usable for people. Easily understandable and completely based on current HTML and XHTML standards. It isn't trying to be perfect; it tries to be a workable specification. You remember the end of the second Matrix film where the architect explains people can't live with perfection? Well that's how the web works.
(Anne notes that this is not how he normally reacts. He likes being a zealot promoting all kinds of exotic things, like XHTML Ruby, but realism is needed once and a while. He would also like to see some response from the "big weblogger world" that seems to be reading his weblog.)
Anne, you are getting old. Your posts become less and less extreme :]
Nice post. I don't have a weblog though, let alone big, so you should moderate my comment... M.
You might have read: Web Applications and Compound Documents, IMHO ...
I just read the article a bit, but I don't understand some things. Maybe I don't understand the word web-application in the way they use it.
I don't see how someone can compare XForms with SVG. SVG & XForms are both handy for web-apps, but they are so different (in my eyes). Both languages are missing important things for web-apps, but they could form a powerfull combination.
I also don't see the point of a HTML based solution for web-apps. Offcourse you can do a lot of things with it, but I don't think it's (fully) capable of handling specific web-apps. SVG & XForms are offering loads more of possibilities. The only reason for not using it is support (& maybe backwards-compatibility).
I think Java is still the most powerfull language for web-apps. It has a lot of possibilities and the support is pretty good.
I still think that SVG is a vector graphics format that should be used more often (and thus is should be supported by the major browser vendors).
However if there is another vector oriented format and it's supported by all major browsers, I might like that too. It's even possible I'm going to use it and forget about SVG.
When you use SVG by linking to it form an object or image tag its still a valid solution to get vector graphics.
You might be right however about the possibility to create an XHTML+SVG document without getting problems with CSS compatibility, I just don't know the details of the SVG standard well enough to provide an opinion about it...
Well it more that the SVG reinvent the wheel. Instead of discussing with the CSS Working Group what is sensible to include and how the new properties can be made interoperable with other languages. See also SVG specification madness.
The problem isn't really that SVG isn't going to be implemented, the problem is more that the W3C is making profiles of the specification instead of thinking of something that could be used platform wide.
First up, SVG and CSS are both rendering languages, using CSS in SVG breaks the semantics, therefore you should not use it, the biggest failing of the SVG Working Group was listening to the demands of re-using the CSS work. CSS should be removed from the SVG spec, you simply can't have optional styling of a semantics is style language.
On Web-Apps, if Hixie and the rest at the W3C pulled their fingers out, we might be able to see what it could look like, there's been a member only XBL draft for months, but instead of publishing it so we can see what's happening, it's been kept wholly private. XHTML is clearly not the future, look at Opera's position paper it talks about IE6 - instantly invalidating XHTML as relevant (or choosing to ignore RFCs)
The HTML Working and the CSS working have failed to deliver realistic workable Specifications for years, XHTML 1.1 and on has all been not implemented. CSS 2.0 is a complete joke of a moving target that gets substantially modified by errata, 2.1 and 3.0 are still slowly plodding along and don't seem to be any closer to implementation.
The main reason I don't listen too much when Hixie talks about the future of the web, is simply that he's part of the W3C, the specs he's involved in are no paragons of virtue, they're just as bad as the rest, overstepping their remit, ignoring the community etc. He's got a viewpoint, I agree with most of it, but it's not as if everything, or even that much is revelatory or different.
CLASSIC RANT FOLLOWS
It's Saturday night, you're a young bloke, go after the girls instead of torturing your mind! ;-)
Oh and by the way: this so-called classic user just wants to use FrontPage 2003...
Well, Anne the question of "the future of the web" is a big one, as anyone here around knows, and big questions like this one, can't be answered in a weblogs comment section.
As Graduate in Texttechnology, I am happy about the W3C workshop on the future of webapplications and compound-documents, because the status quo of webapplications and webdocumentclasses is not very beautifull: Mixing documents and programms [PHP], Mixing openformats and properitary formats [HTML and Flash] but mor important mixing, content and presentation [XML/HTML/SVG] is extremly ugly.
As I mentioned here a few times before, HTML was desinged to markup [hypertextual] scientific papers and browser were designed to present them on computer screens. Today HTML functions as a mixture between an document-markup-language and an Application front-end. HTML became the child of the book-page and the GUI, visually and functionally. And the web needs everything in between and even more: document presentations, webshops, vectoranimations and [if X3D - what is actually the hell of a recommendation - is ever to be implented in a webbrowser] even 3D Applications like CAD and Ego-Shooting.
The big question is, should a browser be a universal meta-software to create all types of webbased softwares, or should it be a multi-document viewer?
Jim Ley: You give Hixie too little note, I would think. For example, you wanted to see the XBL draft. He has it for your peruse on his site.
The purpose of the first official W3C XBL specification will be filling SVG RCC requirements. Later XBL versions will target other languages. Or so it seems from the SVG1.2 and XBL drafts.
Yep liorean, you can read a W3C Member only document on Hixie's site, I do not think that's right - either it's Member only, in which case it shouldn't be there, or it's suitable for the public in which case it should be as part of an open working group complete with places I can comment.
With the current draft, there's no where for publically archived comments - what should I do email the editors with it cc'd to www-archive? That's not going to get appropriate review from everyone.
Informal communication that Hixie is providing, is good and very welcome, and certainly better than nothing, but it's no substitute for proper W3 process with publication and proper mailing lists for comments and issues.
Well, I personally would prefer an open process run by the W3C, but please remember that this isn't even an official working draft yet. When it becomes an official working draft, to the level that the WGs involved in it feel they have solved their initial internal concerns, it'll enter the W3C process as a WD, as with any other TR.
I think much of what Hixie does is great, and try to comment upon it as often as I can. For example, I find the Server-sent DOM events idea very interesting, and have sent him an e-mail about it. I hate that his blog doesn't support comments -- I would like to make the comments there, and not in e-mail.
I also find the Web Forms 2.0 specification a great one, and just what we need until XForms 1.0 is adequately supported. I think what might "hurt" Hixies proposals is that he doesn't have any good processes for feedbacks and comments. I, for one, hate writing e-mails. As a matter of fact, I hate e-mail as a whole.
PS: Could you please make the error feedback on the comments a bit more meaningful? "XHTML is not well-formed" doesn't say me much when I know I haven't used anything outside the XHTML spec. The comment script doesn't like HTML entities, for example.