Andrew Gregory

Posts tagged with "ie"

IE8 Interoperability

Sunday, 31. August 2008, 05:01:50

web, microsoft, standards, compatibility ...

The news that IE8 specially configures intranet pages to display in a compatibility mode is no surprise to me.

I blogged about Microsoft's compatibility problem several months ago, and decided that they needed two browsers - one for private intranets and one for the public Internet. All Microsoft have done here is roll all that into a single browser.

Håkon is wrong to complain about that. Microsoft have no choice unless they don't want any of their corporate customers to upgrade to IE8. How would that help improve web standards? No, the best way to improve web standards is to allow private sites backward compatibility, while allowing public sites to default to web standards. That will allow the maximum number of users to upgrade to the vastly more standards-compliant IE8, which in spite of how a lot of people feel, will eventually become the most widely-used browser.

Håkon is not wrong to complain about the broken page icon. Icons in status bars are usually there to draw your attention to them, indicating something important or a potential problem. From a users point of view, being in standards compliant mode is neither. All users care about is if the page looks and works OK. Web developers will ensure that will be true for their IE visitors. It is absolutely wrong to associate a broken page icon with standards compliant web pages and rendering modes.

What would be useful is an icon to indicate whenever the browser has had to guess how to handle broken page code - typically invalid HTML or CSS. Browsers should never have to guess. If they do, then web developers are relying on luck for correct display. Developers should want something more reliable than that, and their users certainly do!

That's really what everyone wants. That every web page should just work. No buttons, no icons, no special rendering modes (it's OK if the different modes are hidden, as they are now). Everyone agreeing to and using the same standard is the only way to get there.

5 comments

Microsofts Compatibility Problem

Wednesday, 23. January 2008, 14:16:29

web, browsers, standards, ie

So, the Microsoft team are busy working away on version 8, and they're finding all sorts of web sites are breaking.

Welcome to the world of web development, Microsoft! It's what everybody else has to deal with!

Make no mistake, this is a real problem for Microsoft. They have to support legacy web sites. Often such sites are unmaintained intranet sites that would need to be totally rebuilt to support a new standards-compliant browser.

In their quest for a solution, Microsoft decided to get some outside advice, and the best they could find was a browser-specific meta tag.

I've already left my take on the problem, but I'll repeat it here:

The problem is fundamentally a Microsoft problem. It's a problem where sites have not developed a "web site", but have instead developed an "Internet Explorer site". This is not a problem to be solved by standardizing a new tag for all browsers. It's a problem to be solved by Microsoft and Internet Explorer.

The best solution to handling "Internet Explorer sites" is to have a dedicated "Internet Explorer browser". In practice, that would have to be a standalone copy of Internet Explorer 6. Maybe version 7, but there's already plenty of grumblings from places who have blocked updates to IE7 because it breaks their IE6 sites.

It's already possible to have a "nearly standalone" copy of IE6. Some details such as conditional comments don't work properly, and maybe some other things too, but it's hard to see it being a massive task for Microsoft to sort those out and end up with a truely standalone version of IE6 to be used for those legacy sites.

That would 100% solve Microsoft's compatibility problems and free up their IE development team to concentrate on bug fixes and new standards-based features.

Note that Microsoft's existing VM-based browsers don't solve the problem, as their customers will certainly want to set up icons to launch their legacy sites in the old browser, and I don't see how that could be done with a VM.

No comments

IE, XHTML, MathML and SVG!

Saturday, 1. December 2007, 04:11:40

mathml, web, browers, standards ...

Yes! They can all be one happy family!

A few weeks ago I was fiddling with MathPlayer, a MathML viewer for IE. What I glanced at without letting it sink in, was that MathPlayer recommends you serve your pages using the 'application/xhtml+xml' MIME type.

The important thing is that with an appropriate DOCTYPE, MathPlayer will detect that and automatically switch IE from XML mode to HTML mode. So, with MathPlayer you can use XHTML and serve it with the correct MIME type for all browsers, without any need for special server-side processing for IE! Of course, you don't need to use any MathML on your page. You can just use MathPlayer to give IE support for correctly-served XHTML.

The next piece in the puzzle is SVG. Adobe have their SVG Viewer. Sadly, they're discontinuing it from 1 Jan 2009, even though it's currently the only way to get SVG into IE. Edit: Not true, there's also Renesis Player.

A little bit of Googling turned up a demo by Peter Jipsen that combines XHTML, MathML and SVG on the one page, served as 'application/xhtml+xml', and displays just fine in IE (with the aforementioned plugins), Firefox, and Opera (9.50 windows build 9656 or equivalent for MathML). Safari works too, apart from the MathML.

Stripped down, the page code is valid, very simple, and has a small concession for Adobe's SVG viewer:

<!DOCTYPE html PUBLIC
    "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
    "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:svg="http://www.w3.org/2000/svg">
  <head>
    <title>A XHTML document with ASCIIMathML, MathML and SVG</title>
     
    <!-- for inline Adobe SVG: -->
    <object id="AdobeSVG" classid="clsid:78156a80-c6a1-4bbf-8e6a-3cd390eeb4e2">
    </object><?import namespace="svg" implementation="#AdobeSVG"?>
    
  </head>
  <body>
    <p>MathML
      <math xmlns="http://www.w3.org/1998/Math/MathML">
        <mfrac>
          <mi>a</mi>
          <mi>b</mi>
        </mfrac>
      </math>
      
and SVG
      <svg:svg width="50px" height="50px">
        <svg:circle cx="25px" cy="25px" r="20px" fill="green"/>
      </svg:svg>
    </p>
  </body>
</html>

Christmas wish for 2007: That Microsoft start bundling Adobe's SVG Viewer and Design Science's MathPlayer plugins with IE, and make them a Windows Update.

It would be a huge step forward for web standards, bring IE into close parity with Firefox and Opera, all for next to no effort for Microsoft.

And while we're at it, world peace would be nice too.

No comments

Faking server-sent events in IE?

Tuesday, 20. November 2007, 11:31:25

web, whatwg, browsers, ie

IE ActiveX(”htmlfile”) Transport, Part II describes a way to stream data to IE. My first thought was: "would that make it possible to fake the server-sent events API in IE?"

I don't have the time right now to investigate further, so this post is part reminder to me for later, and part invitation to the lazyweb.

No comments

SVGs on web pages

Saturday, 4. August 2007, 16:04:27

adobe, web, standards, asv ...

Up until now, I've been using code similar to the following to put SVG images on my web pages:

<!--[if !IE]> <-->
<object type="image/svg+xml" data="foo.svg" width="420" height="360"></object>
<!--> <![endif]-->
<!--[if IE]>
<embed src="foo.svg" width="420" height="360"></embed>
<![endif]-->

The common mood on the 'net at large is that the Adobe SVG Viewer (ASV) (the only way to get IE to display SVGs) is not happy with the standards-compliant object element, but works much better with the embed element. The conditional comments ensure that standards-compliant browsers (including the HTML validator) got the standards-compliant code, while IE and ASV got what they wanted.

The problem with that is that it's clunky and duplicates the src/data, width and height attributes, which makes it easy to mistakenly put different values in the two elements.

A recent project of mine involving a web-enabled microcontroller caused me to revisit the above code. I was running really tight on memory, literally counting bytes to get everything to fit. The above code was a good candidate for trimming a bit of fat.

After some searching and trial-and-error, I found that ASV's problem with the object element was nothing more than the type attribute! The above code reduced to:
<object data="foo.svg" width="420" height="360"></object>
So much shorter, simpler and more maintainable!
This has changed, see below. I tested it to work with IE+ASV, Firefox, Opera and Safari(Windows). It also validates, of course. The only caveat is that the web server must use the correct MIME type ("image/svg+xml"), which it should be doing anyway.

The bytes saved enabled me to polish off the last couple of remaining bugs in my microcontroller project without spending ages scrounging around for fatty code elsewhere - with a whole two bytes to spare!

Edit: Last night I was reviewing this and found it had stopped working in IE and Firefox, but I was too tired to be bothered investigating. However, this morning it's working again! It never stopping working in Opera.

Edit2: I've just found the following that seems to be more reliable:

<object type="image/svg+xml" data="foo.svg" width="420" height="360">
<param name="src" value="foo.svg" />
<a href="foo.svg">Demo SVG</a>
</object>

(The anchor is not required, it's just there as a fallback)

Source of above: http://joliclic.free.fr/html/object-tag/en/object-svg.html

4 comments

IE6 is technically very good

Monday, 17. April 2006, 13:07:50

browsers, ie, www, web

Over the last year or so, it's occurred to me that IE6, in spite of it's neglect since it was released in October 2001, is really an incredibly capable browser; much more powerful that any other in many ways.

My reasoning is this: how many other browsers at that time could be "upgraded" using client-side scripting to improve their standards support? Current browsers when IE6 was released were: Netscape 6.2, Opera 5.12, IE/Mac 5.0, Konqueror (probably a v1.x). Mozilla, Firefox and Safari didn't exist, not as final versions anyway.

There are many web design features that IE6 does not support. Since its release, smart people have developed scripts to fix many of them: transparent PNGs, :hover on any element, position:fixed, min/max-width/height, <abbr>, SVG, <canvas>, DOM-compliance. Then there's the big-momma of them all: "IE7". The common thing these scripts share is that they are all client-side scripts and download and do their thing without the user being aware of anything; nothing needs to be installed.

I don't think there is any other browser around, even today, that could do that!

Of course, today's browsers don't need to do that! They haven't stood still like IE has. In particular Opera, Mozilla, and Safari have all been striding ahead implmenting fabulous new features for web developers and fixing bugs. They do it smaller, faster, better.

I'm just amazed at how effectively people have been able to drag IE up to even somewhat the level of current browsers! The point of this is how powerful is the underlying infrastructure of IE that allows that to happen!

5 comments