Daily Archives: January 22, 2008

internet, microsoft, web authoring, windows

Why Internet Explorer users get the worst of the Web

3 Comments

Microsoft’s Chris Wilson has a post on Compatibility and IE8 which introduces yet another compatibility switch. IE8 will apparently have three modes: Quirks, Standards, and Even More Standard.

Here’s the key paragraph:

… developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in “standards mode,” even though it didn’t follow the specification – because they’d already made their content work with our model. In many cases, these sites would have worked better if they had served IE7 the same content and stylesheets they were serving when visited with a non-IE browser, but they had “fixed their content” for IE. Sites didn’t work, and users experienced problems.

In other words, so many web pages have “If IE, do this” coded into them, that pages actually break if IE behaves correctly. Alternative browsers will do a better job, even if IE is equally standards-compliant, because they do not suffer the effects of these workarounds.

Microsoft’s proposed solution is to make the supposed Standards mode a new quirks mode, this time frozen to IE7 compatibility, and to force developers to add a further meta tag to enable the better standards compliance of which IE8 is capable.

It actually goes beyond that. Aaron Gustafson explains the rationale for the new X-UA-Compatible meta tag which enables web developers to specify what browser versions their page supports. The idea seems to be that browsers parse this tag and behave accordingly.

This sounds uncomfortable to me. Versioning problems are inherently intransigent – DLL Hell, the Windows GetVersion mess – and this could get equally messy. It is also imposing a substantial burden on browser developers.

Has Microsoft made the right decision? Trouble is, there is no right decision, only a least-bad decision. Personally I think it is the wrong decision, if only because it perpetuates the problem. It would be better for IE to do the correct thing by default, and to support meta tags that turn on quirks modes of various kinds, or an option in browser preferences, rather than doing the incorrect thing by default.

Still, Wilson makes a case for the decision and has some supporters. Nevertheless, he is getting a rough ride, in part because the IE team has failed to engage with the community – note for example the long silences on the IE blog. Why is Wilson telling us now about this decision, as opposed to discussing the options more widely before it was set in stone, as I suspect it now is? Even within the Web Standards Project, some of whose members assisted Microsoft, there is tension because it it appears that other members were excluded from the discussion.

Another point which I’m sure won’t go unnoticed is that Wilson makes a good case for using alternative browsers. IE users get inferior markup.

Technorati tags: , , ,
internet, web authoring

Use HTML not Flash, Silverlight or XUL, says W3C working draft

3 Comments

The W3C has posted its working draft for HTML 5.0. Interesting statement here:

1.1.3. Relationship to XUL, Flash, Silverlight, and other proprietary UI languages

This section is non-normative.

This specification is independent of the various proprietary UI languages that various vendors provide. As an open, vender-neutral language, HTML provides for a solution to the same problems without the risk of vendor lock-in.

Food for thought as you embark on your Flash or Silverlight project. I would have thought XUL is less proprietary, but still.

The contentious part is this:

HTML provides for a solution to the same problems

I doubt that HTML 5.0 can quite match everything that you can do in Flash or Silverlight, depending of course what is meant by “a solution to the same problems”. The other issue is that Flash is here now, Silverlight is just about here now, and HTML 5.0 will be a while yet.

Technorati tags: , , , ,
internet, software, software development, web authoring

Escaping the Adobe AIR sandbox

2 Comments

Adobe’s Mike Chambers has an article and sample code for calling native operating system APIs from AIR applications, which use the Flash runtime outside the browser.

I took a look at the native side of the code, which is written in C# and compiled smoothly in Visual Studio 2008. The concept is simple. Instead of launching an AIR application directly, you start the “Command Proxy” application. The Command Proxy launches the AIR application, passing a port number and optionally an authorization string. Next, the Command Proxy creates a TCP socket which listens on the specified port. The AIR application can then use its socket API to send commands to the Command Proxy, which is outside the AIR sandbox.

It’s a neat idea though Microsoft’s Scott Barnes gave the design a C- on security grounds. He clarified his point thus:

The communication channel between the command proxy and AIR application looks like a potential vulnerability. One of the things application developers should worry about with security is insecure cross-process communication mechanisms hanging around on someone’s machine. For example if a process listens on a named pipe, and that named pipe has no ACLs and no validation of inbound communication, the process is vulnerable to all kinds of attacks when garbage is sent down the pipe. In the example on using the command proxy how do you secure it so that it doesn’t turn into a general purpose process launcher?

Barnes has an obvious incentive to cast doubt on AIR solutions (he’s a Microsoft RIA Silverlight evangelist), but nevertheless this is a good debate to have. How difficult is it to do this in a secure manner? It is also interesting to note the opening remarks in Chambers’ post:

Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0.

This is really one feature: access to native code. I remain somewhat perplexed by AIR in this respect. Is the inability to call native code a security feature, or a way of promoting cross-platform purity, or simply a feature on the to-do list? I don’t think it is really a security feature, since AIR applications have the same access to the file system as the user. This means they can execute native code, just not immediately. For example, an AIR app could download an executable and pop it into the user’s startup folder on Windows. That being the case, why not follow Java’s lead and provide a clean mechanism for calling native code? Adobe could add the usual obligatory warnings about how this breaks cross-platform compatibility and so on.