rc3.org

Strong opinions, weakly held

Tag: standards

The risky aspect of HTML5

The theory is that if all the User-Agent providers implement all these algorithms exactly as specified, complete interoperability will be achieved and people who build Web applications need no longer concern themselves with the differences between User Agents. Which would of course be wonderful.

Will it work? Nobody knows; it’s a science experiment. Just because nobody has ever succeeded in specifying a workable networked object model doesn’t mean this project will likewise fail. But it does mean that when considering the future of HTML5, we should recognize that this is a very hard problem, and there’s no guarantee that that part of it will come off.

From a blog post on HTML5 by Tim Bray.

A new way of writing a standard

I’ve been paying attention to the various goings on in the world of markup this week, and there will be lots of relevant links in the next roundup I post, but I wanted to comment on this email from Shelley Powers on Ian Hickson’s decision to give every browser maker veto power over any of the features listed in the HTML 5 specification. Powers absolutely hates this idea, but I confess that I’m intrigued.

Hickson has decided that the spec will not contain any features that browser vendors have not committed to support. This is very different from the usual standard-writing process, especially when it comes to W3C standards. In the past working groups have come up with lots of exciting new features and various rules to be obeyed and then the programmers go off and create something loosely based on that standard. The degree to which browsers are compliant with recent standards is a running joke, although things are much better now than they were a few years ago.

When asked whether each browser vendor can, by themselves, prevent a feature from being included in the HTML 5 recommendation, Hickson responds:

Not immediately, but if you had notable market share and we could not convince you to implement these new features, then yes, I’d remove them and then work with you (and everyone else) to try to come up with solutions that you would agree to.

Even if you did not have notable market share, I would work with you to understand your objections, and try to resolve them. (Naturally if your goals are substantially different than the WHATWG’s goals, then this might not go anywhere. For example, if Microsoft said that we should abandon HTML in favour of Silverlight, without making Silverlight backwards- compatible with HTML, then this would be somewhat of a non-starter, since backwards-compatibility is an underpinning of our work.)

What I find interesting about Hickson’s approach is that he makes the presumption of good faith. His process will only work if the browser vendors wish to collaborate to improve the Web experience by adding new features to HTML 5. Powers objects because she assumes bad faith on the part of vendors:

If we continue to allow one vendor/one veto to be the underlying philosophy of the HTML WG, then we might as well end working on it at this point, because I can’t see it being anything more than a race to the bottom, with each vendor looking to cripple open web development in favor of its own proprietary effort.

Worse, this process completely and totally disregards the community of users, of web developers, web designers, accessibility experts, and gives ultimate power to five companies: Google, Apple, Microsoft, Mozilla, and Opera–with Microsoft having the largest veto power. The rest of us might as well go home, because we have no say, no input, nothing of value to add to the future of the web. Not unless we crawl on bent knee to each vendor and ask them, “Please sir, I want some more.”

So here’s what I like about the Hickson philosophy. It will expose whether browser vendors want to work together to build new things everyone can benefit from, or if they want to rekindle or perpetuate the browser war. The thing is, we’ll know it earlier in the process than we would otherwise. Powers proposes a “three vendor” standard — if three vendors promise to implement a feature, it will be included. But then what happens is that the features go into the spec, those three browser vendors implement the feature, and the intransigent vendors do not? As professionals we can’t use new features anyway until they’ve been implemented. Under Hickson’s approach, the inclusion of a feature in the recommendation signals a commitment from all browser vendors to implement. We can plan ahead based on that.

If nothing else, it’s a new approach to an old problem. I’ll be curious to see what the process yields.

Microsoft Office XML

Back in December 2006, Andrew Shebanow commented on the difficulty of creating a converter for Microsoft’s Office 2007 document format, which uses XML after Bob Sutor of IBM called it a one-way format due to its complexity. Based on some numbers posted a Microsoft explaining why it would take longer to release a converter for the Mac version of Office, Shebanow came up with this estimate of the effort required to build such a converter:

It would take 5 developers a year to do a quarter of the work. That means the whole job is roughly 20 man-years of development time. That doesn’t include testing, documentation, or localization. That would probably double the number of man-years, at least. But it gets worse:

This is just for Word. We need additional teams for Excel and PowerPoint.

Back of the envelope, we’re now talking about 120 man-years. For Mac Office, Microsoft decided such an investment wasn’t practical, so instead they waited for Win32 Office to go final and are now porting the Win32 code to the Mac.

Today I read that Microsoft still hasn’t released the converter from Office 2007 to Mac Office 2004. It was scheduled for release in January, but has been pushed back to June.

Is IM interop alive?

Florian Jensen reports that AOL is testing ICQ and AIM interoperability using XMPP. If they adopt XMPP, AIM and ICQ should work with Google Talk as well, although they could of course prevent that from happening if they chose to do so.

I started blogging about the need for interoperability among instant messaging services years ago, but very little progress has been made. Still, this is a sign of hope.

© 2024 rc3.org

Theme by Anders NorenUp ↑