Archive for June, 2004

Should Mozilla/Opera/Apple talk to their WHATWG guys?

Wednesday, June 30th, 2004

So Mozilla’s got a new plugin architecture and it’ll work with Safari and Opera too - great news, it shows that the strategies of these three companies and the future of Web Applications are pretty sound, basic HTML and plugins for the new stuff, as you can see with the suggested uses of such plugin based systems.

For example, a user shopping for clothing on a web site that takes advantage of the new plugin capabilities could mix and match different styles and colors for shirts and pants using an interactive Flash movie, and pricing and other information in an associated web page would be updated as a result.

In order to foster a richer experience on the web, we need to enable more dynamic and deep interaction between the browser, the plugin, and web content. This is the first step in that direction; it will give web content developers new, portable options for creating innovative experiences and applications.

Unfortunate though, many of these companies employees (but not the companies we must remember) are spending their time on the WHATWG, now as I said I thought this had little chance of getting much take up. But with this press release, it doesn’t even look like it’s the policy of Moz, Opera and Apple - so why are the employees doing it?

Why Web Forms 2.0 isn’t far enough to make a difference

Monday, June 28th, 2004

The WHAT WG kicked off a lot of discussion on how to improve the current state of the web languages available to us, so as to create the future web-applications. The general consensus (e.g. 1, 2, 3) appears to be we need “graceful degradation” so that it works in IE6 but offers something more elsewhere.

The argument appears to be:

  1. Create something that makes authoring easier but only works in the exciting new ways in Mozilla, Opera and Safari, but degrades elsewhere.
  2. The developer will get such a implementation gain from these improvements, that they’ll use it.
  3. Users will learn of the improvements in these other UA’s and switch to them.

I don’t think this argument works, it relies on authors willing to forego the enhanced performance in IE6, for the ease of authoring with the new technologies. The alternative traditional script solutions to extending the capabilities of web documents, work fine in IE6, they’re well understood (if poorly implemented) and generally work either as well, or only marginally worse in the other browsers - the ones today too, not some new ones that people need to have upgraded too.

IE6 is too important to authors and product managers, whatever the solution is we ship to IE that’s the most important, we can’t compromise that in any way. So whilst offering a calendar control that degrades to a text box might be a fair enough if we’re degrading to IceBrowser, it’s not acceptable to us for IE - We’ll ship one of the common script calendar controls that degrade to a text box when there’s no script. Our IE customers are simply the most important, they’ll get 95% of our development and testing time, in that scenario the degradation must not compromise IE6 behaviour at all.

The WHAT-WG’s approach to this appears to be javascript shims to get it working. As I often say javascript development is almost universally crap, under-tested and poorly implemented. Libraries are often the worse kind, the test requirements are simply too high to do on the huge variety of systems out there, that javascript code can run on, they’re generally not rich enough to do everything - so you’re always extending them, libraries simply haven’t been shown to work on the web. (If I’m wrong, show me some sites!).

These libraries would also need to have to no licence encumberance or risk for me to just re-use them, and most likely be free (all the script the Web Forms 2 spec offers is available for free out there now, how do I justify the cost of something new.) Who’s going to write it? There’s maybe only a hundred or so people with the script skills available, but generally they’re pretty busy doing real work, that actually puts food on the table.

But let’s suppose that authors can deliver good enough IE6 sites through these script methods that they’re willing to ship it. Great, but all that happens now is that users have no reason to move to a new browser, the pages in IE6 are just as good as they would be in those other browsers. Without the motivation to move the process of degradation as an evolutionary strategy doesn’t work, we’ll still be stuck authoring the same pages in the same styles. Only now we’ll also have to worry about a large javascript library that we have little control over.

So what’s the solution?

Flash has shown us how to ship sites which don’t degrade in IE - we use a plugin for the new features, it’s worked great, plugin solutions for IE degradation are fin. So long as what it offers the developer is something of a leap in performance (authoring, technical etc.) that they simply can’t do it in traditional HTML ways, it’s fine. This is where we can make a new technology platform, develop a real improved solution that can be rendered in an IE plugin. IE plugins can go full browser window no problem, and you can change the accept-headers of IE in the install - they don’t need to be done with HTML and OBJECT elements, in this case. Of course IE users who don’t install the plugin won’t get much other than the degradation to HTML, what the users will get though is an incentive to change, since the features will be new and offer something worth installing.

Of course, moving to this system, is a much more complicated system, it’ll take longer to come about, but I think it’s a much more likely scenario than imagining Web Forms 2.0 will really offer enough benefits to either authors, or developers to achieve anything, it’ll just be another XHTML 1.1 never used in the real world.

Google still broken, BBC fixed.

Saturday, June 12th, 2004

So 3 weeks after I mentioned the Google script insertion flaw, and long after I mentioned it to them (years really of course as it’s the same as one from 2002) it’s still sitting there - and this is a company we trust with our email? I wonder how long it really takes to fix trivially simple security holes in your product?

The BBC news site is fixed now though, in fact they fixed pretty quickly, and also removed all the personal tracking stuff they had on the page both from ATDMT and Red Sherriff. The Red Sherriff stuff was mentioned on the privacy page, the other stuff wasn’t and it was this I mentioned. Well done the BBC.

Extending IE with behaviors like IE7

Saturday, June 12th, 2004

I’d always thought from the IE7 idea that Dean Edwards was a little mad, he was making heavy use of behaviors these are absolutely useless in release quality IE code, I spent a lot of my time trying to get rid of them. Maybe he didn’t know, but it turns out he does, so it looks like he’s fully aware what he’s doing, but is happy to carry on regardless. So I’m guessing that yes he is mad.

I hope the WHAT WG people don’t seriously think HTC’s are a viable model for providing any support to IE6, yes they’ll have support, but it’s not support anyone can actually use on the real world, HTC’s are simply not robust enough (and MS ain’t gonna fix them.). Unfortunately though, it really looks like they do think that.