Forum Moderators: open
The Web Hypertext Application Technology Working Group was founded by various people with an interest in web technology, particularly from the Mozilla Project and Opera. They've got a Web Forms 2.0 spec on the way, edited by Ian Hickson (of both Mozilla and Opera fame) and some other projects down the road.
Here's the URL: [whatwg.org...]
The plan to follow the model Microsoft used with DOM, presenting a complete technology to an existing standards group. This gets things done more quickly than the usual design-by-committee, but allows the standards group to fix technical problems (as the W3C did with document.all and innerHTML).
The really interesting part about this project is that they plan to implement compatibility shims to make the new specs work on IE6 via a combination of CSS, JS, and HTCs. That, combined with a design that degrades reasonably well on older browsers, could allow us to begin using some of these technologies this year instead of this decade. It's not clear when we'll see native implementations in Mozilla and Opera, but hopefully that'll come pretty quickly.
One thing which unites the attendees of the workshop is their support of standards, but the workshop ended with a division into three clear camps, each with their own view of the future of web applications.
The WhatWG was set up by those who support the third option, namely the backwards-compatible, Opera/Mozilla route. All specifications developed by the WhatWG will be subsequently submitted to the W3C or the IETF for adoption.
As for application developers, which represent the large majority of the readership of WebmasterWorld, they already use the existing technologies of HTML, CSS, etc. to build their successful businesses. Personally, I feel more "in tune" with the WhatWG approach, which offers a transition towards a more powerful web experience, with compatibility retained for older browsers. Of course, it is only natural that browser developers such as Opera and Mozilla would favour using browser technology to deliver web applications rather than by any other method.
What of the traditional W3C approach? Microsoft have made it clear that they do not intend to go further down the W3C route, and that even to browser to be included in the long-awaited "Longhorn" Windows release will not support XHTML served as
application/xhtml+xmlOf course, anything must be better that the appropriation of the web by a single company, represented by Microsoft's XAML/Avalon approach.
References:
Why they can't accept the massive success of HTML 4 and learn to grow on that is beyond me, it's almost as if we're dealing with little kids who want to change something every day because they want to change it, and because you've let them have that power. And at some point the grownups have to step in and tell the little kids that they need to stop. Fortunately Opera and Mozilla are doing that, or trying. The real world web market seem to have little interest in the W3C's latest ideas, and maybe the market is right in this case.
As some of those links point out, things like xhtml have so little presence on the real www that you really have to ask how the w3c can seriously even think of trying to move to xhtml 2. And, for once, I have to applaud microsoft for simply refusing to play this particular game.
It's taken me months of reading WebmasterWorld postings to start understanding exactly what was happening, since it makes no sense at all if viewed from a user/producer perspective, it's completely obvious that html 4, + CSS 1 and 2, plus even more tag options, is a great thing, people love it, for good reason.
I have to admit, the first time I saw some of the recommendations for a draft of XHTML 2, I had to ask myself what on earth the W3C was thinking. It destroyed almost all the features of what made the web a fantastic medium, easy to use, democratic, and most important, accessible to all users, and replaced it with what can only be considered in my opinion a programmer's bad dream.
I'm struggling to see how the XHTML2 spec. will have this level of an imapct. For a start, XHTML is the markup language used by site designers/developers to present their content and design to the online world. The web will remain "a fantastic medium, easy to use, democratic, and most important, accessible to all users".
XHTML is the next stage in the seperation of style and content from our markup - this is a good thing in many ways, but let's use one of your arguements: accessibility. By stripping away all the style related markup, we are left with a page that is content rich with semantic tags (and class and id calls for the style). For a special needs user browsing with assistive technology this sort of a page is perfect. The (say) screen reader understands that text surrounded by <em> tags should be emphasised. So, instead of taking away from accessibility like you are suggesting, it adds to it.
Now, you advocate sticking with HTML4. Fine, browsers will continue to render it for some time to come and it is the decision of the site designer/developer to use whatever markup version they want. However, to suggest that XHTML2 is a step backwards is misleading and, in my opinion, quite incorrect. The value of simple, semantic markup with style and content being seperate is huge. But in the true spirit of the web, it's your choice!
As I said, there are three ways forward - two of which have fundamental problems. The current W3C approach of XHTML2, X-Forms and the rest of it is not wrong per se, but it is missing a vital element - the dominant player (Microsoft) has no intention of adopting this route.
The second approach is Microsoft's own preferred route, in which MS leverages it's dominant position to appropriate the web via the introduction of proprietary, patent-protected technologies such as XAML and Avalon. This is the most dangerous possibility by far.
The final approach comes from the two browser-makers which have done the most to promote open standards (CSS, for example, came directly from Opera): avoid the multiplication of new, overlapping standards, and build on the existing framework of HTML, CSS2, the DOM, in order to further extend the possibilities, whilst in the meantime ensuring backwards-compatibility, which is absolutely essential for their success.
The advances brought about by the W3C in terms of accessibility, style/content separation and rich, semantic markup are not only retained, but enhanced. All future WhatWG proposals will be submitted to the W3C or the IETF for approval - it's just that there will be less "design-by-committee" and a more focussed approach.
On an interesting point, the tabbed navigation on the WHAT site look very broken when looked at in IE!
Edit: Typo fix!
[edited by: BlobFisk at 6:48 pm (utc) on June 18, 2004]
...HTML4. Fine, browsers will continue to render it for some time to come
I'd go a bit beyond this statement. My guess is that XHTML is never going to catch on the way HTML 3.2 and 4 did, for two very simple reasons: 1: it's harder to use and keep error free, and 2: it has fewer features than html 4.
This is not a smart way to market a new product. Harder to use, no real advantages for end users, and fewer features. No wonder almost all standard, non techie sites are staying with either <html> or the quirks mode html 4.01 doctype.
This is quite different from CSS, which is seeing a significant rise in useage among top sites, because it does improve performance, it does offer more power to the site.
XHTML with even one error has no reason to exist, it defeats the entire purpose of having an xml quality html document, like a php script with a few extra ' or ; characters. Humans make errors, things like xhtml only make sense when you are talking about full machine generation of all code, which is the vision I presume is driving xhtml 2 development.
Since apparently MS IE has no plans to support xml or xhtml 2, if I read it right, most of these points are completely moot, of only theoretical interest for the coming web generation.
On an interesting point, the tabbed navigation on the WHAT site look very broken when look at on IE!
I had the same reaction when I initially viewed this in IE - "these guys can't properly code a tabbed menu bar!" - lol.
I *like* the new W3C technologies. They're better than what WHATWG is likely to provide--but I despair of ever being able to use any of it on the public Web.
