saved byGary Edwards on 2008-07-03
XHTML2 has some very good ideas that I hope can become part of the web. However, it’s unrealistic to think that all web authors will switch to an XML-based syntax which demands that browsers stop processing the document on the first error. XML’s draconian policy was an attempt to clean up the web. This was done around 1996 when lots of invalid content entered the web. CSS took a different approach: instead of demanding that content isn’t processed, we defined rules for how to handle the undefined. It’s called “forward-compatible parsing” and means we can add new constructs without breaking the old.
So, I don’t think XHTML is a realistic option for the masses. HTML 5 is it.
suppose that HTML5 is good enough if the only interoperability you are concerned with is that between web page server and desktop browser. But it is massively underspecified as a standard for exchange of web documents between web applications. Likewise the CSS2 class libraries, which are virtually worthless for the purpose because the CSS is typically defined in site templates rather than in the web documents themselves.
For example, I can go to any number of web applications and find myself creating different custom markup to identify a footnote call or a footnote, including Mr. Lie’s Prince software. And were I to attempt to exchange web documents among, e.g., Wikimedia, WordPress, Google Docs, and Zoho Writer, my only hope is to recode content manually.
# Response to marbux supporting the WebKit layout/document model.
Marbux argues that HTML5 is not interoperable, and CSS2 near useless. HTML5 fails regarding the the interop web appplications need. I respond by arguing that the only way to look at web applications is to consider that the browser layout engine is the web application layout engine! Web applications are actually written to the browser layout/document model, OR, to take advantage of browser plug-in capabilities.
The interoperability marbux seeks is tied directly to the browser layout engine. In this context, the web format is simply a reflection of that layout engine. If there's an interop problem, it comes from browser madness differentials. The good news is that there are all kinds of efforts to close the browser gap: including WHATWG - HTML5, CSS3, W3C DOM, JavaScript Libraries, Google GWT (Java to JavaScript), Yahoo GUI, and the my favorite; WebKit.
The bad news is that the clock is ticking. Microsoft has pulled the trigger and the great migration of MSOffice client/server systems to the MS WebSTack-Mesh architecture has begun. Key to this transition are the WPF-.NET proprietary formats, protocols and interfaces such as XAML, Silverlight, LINQ, and Smart Tags. New business processes are being written, and old legacy desktop bound processes are being transitioned to this emerging platform.
The fight for the Open Web is on, with Microsoft threatening to transtion their entire business desktop monopoly to a Web platform they own. The Web is going to be broken. There is no way of stopping Microsoft at this point. What we can do though is focus on Open Web solutions that are worthy alternatives to Microsoft's proprietary push. For me, this means the WebKit layout/document model supported by Apple, Adobe and Google.
~ge~