W3C 'clarifies' HTML 5 v XHTML
Vendors moving too fast on RIA
The group, meanwhile, has also acknowledged vendors are - once again - pushing their own platform-specific technologies, this time on RIA, with the standards process unable to keep up. This poses a problem on interoperability.
A detailed comparison highlights these differences and suggests that the two standards will appeal to different sets of developers.
There has been concern, voiced by Reg readers at least, that the W3C is layering on multiple standards, creating confusion over what standards and technologies to use.
The W3C has also moved to position HTML 5 in relation to proprietary UI languages from Adobe, Microsoft and Mozilla - namely, Flash, Silverlight and XUL. The editor's draft said HTML is limited to providing a semantic-level markup language and associated semantic-level scripting APIs.
It's also an open language without risk of proprietary lock in.
Microsoft's Wilson: modular HTML 5
"For sophisticated cross-platform applications, there already exist several proprietary solutions (such as Mozilla's XUL, Adobe's Flash, or Microsoft's Silverlight)," the group said.
It also appeared to acknowledge the vendors pushing their own, platform-specific rich internet application technologies faster than the standards process can keep up. It noted the complexity challenges of interoperability. We've seen a similar pattern of activity before, more recently on web services where - for example - Microsoft and IBM set the agenda on WS-* and repeated W3C-based work led by IBM and Sun Microsystems.
"These solutions are evolving faster than any standards process could follow, and the requirements are evolving even faster. These systems are also significantly more complicated to specify, and are orders of magnitude more difficult to achieve interoperability with, than the solutions described in this document," the latest W3C draft said.
"Platform-specific solutions for such sophisticated applications (for example the MacOS X Core APIs) are even further ahead."
Interestingly, Microsoft, Mozilla and Apple have participants on the HTML5 working group, but Adobe is absent.
Of possibly greater concern is the time it will take for the massive HTML 5 specification to be refined and implemented. In a recent SD Times interview Chris Wilson, Microsoft's Internet Explorer architect, suggested that HTML 5 should be split into more manageable pieces and progressed by several teams working in parallel.
One of the main improvements over previous versions of HTML is the inclusion of multimedia features and a recognition that future web applications could be accessed from mobile devices. The importance of this was emphasized this week when Trolltech revealed that it had built HTML 5 audio and video support into its QtWebkit development tool.®
Additional reporting by Gavin Clarke
Separating the content and style might not be to your liking but you have alternatives you could use. For anyone else running a large website it's a Godsend.
The ease of changing the style of a website even dynamically is great. When you have multiple content editors who are news hacks and don't know anything about HTML tags (no offence to the el Reg) then you need them to be able to add content whenever and wherever they are you would not be able to do it with a rigid fixed layout.
Newspapers and book shave been doing this for decades. A newspaper has a semi rigid frame and a definitive style and the content is flowed into it.
It sounds like you come from a traditional graphic design background who's got into "New Media" rather than a web developer who actually do the grunt work.
XHTML should be now, HTML should be dead
WTF! The HTML 'standard' should be retired and all the work moved to XHTML and sub projects. It's about bloody time that web authors learnt to use XML properly and got told off (and shown the right way) every time they misusing the document type or abused the document structure!
All web pages should be XHTML pages and a strict document type should be standard so that the browsers can be streamlined and not have to guess (wrongly) what was intended.
The garbage DOM API should be retired and be replaced with a proper, usable XML document API, similar to XOM (Java), with XPATH. A proper API should only allow child elements to be added from other valid XML documents, not direct from text. All XML APIs should transparently deal with escaping text; there is no excuse not to do this!
Sorry but this article really is complete nonsense, and shows a real lack of understanding of XML. I can't speak for the Adobe/MS stuff but to suggest XHTML is competing as a replacement for Mozilla's XUL is nothing but rubbish.
Mozilla's XUL is built from an XML language called XBL. XBL 2.0 has already been ratified by the W3C as a way of "BINDING" and thus extending arbitrary actions and behaviours into XML elements. XBL is as usable alongside XUL as it is XHTML, because it binds and extends behaviours as the author intends.
XUL doesn't have a "treeview" element because XUL defines a <treeview/> element it, it's because XBL binds a set of "tree like" behaviours to an XML document that happens to have a .xul extension (and XUL XML namespace).
Please sort it out. The X in XML stands for extensibility.