And more Web technologies get bastardized

Microsoft released a preview of IE 9 with support for XHTML and Scalable Vector Graphics (SVG). Microsoft should be commended for supporting XHTML, SVG and their attempt to make application development easier using these technologies. However, their implementation of XHTML and SVG in IE 9 destroys the very essence of these technologies - which is that they must be used according to specification.

What is SVG?

SVG is an XML markup language for rendering vector graphics, which are made up of mathematically described shapes such as lines, circles, polygons, etc. Unlike bitmap graphics, vector graphics can be stretched to any size without much distortion. This makes vector graphics ideal for building maps, charts, graphs and diagrams.

What is XHTML?

XHTML is a version of HTML that follows the rules of XML. Web developers can instruct Web browsers to process XHTML as HTML or as XML using an HTTP header. XHTML can be very useful in the area of content management and other application development, because it is very easy to parse and transform using off-the-shelf DOM and XSLT parsers.

What did Microsoft do to XHTML and SVG?

XHTML and SVG were designed to be XML languages but IE 9 processes them with what appears to be an HTML parser. As a result IE 9 will try to render incorrectly written XHTML and SVG documents without notifying the user that there are markup errors. Let's look closely at the implications of this. Below is an SVG document that contains, let's say, important pricing information:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200">
<polygon style="fill:yellow;stroke:black;stroke-width:1" points="85,41 132,48 100,81 108,127 65,105 25,127 33,81 0,48 45,41, 65,1" />
<text style="font-size:26px;fill:#800080" x="40" y="70">$</text>
<text style="font-size:40px;fill:#000000" x="51" y="84">1</text>
<text style="font-size:40px;fill:#000000" x="67" y="84">0</text>
</svg>

The following screen shot shows how Opera will display the preceding SVG document:

Screen shot of Opera Web browser displaying a yellow star with text: $10.

Now let's introduce a markup error into this document. For example, an incorrectly quoted attribute in the last <text> element. This time, Opera will display an error message as shown in the screen shot below:

Screen shot of Opera Web browser displaying an XML error message with the option to reparse the document as HTML.

However, instead of an error message, IE 9 Developer Platform Preview release will try to render the incorrectly constructed SVG document. As a result, it will display incorrect information as shown in the screen shot below:

Screen shot of IE 9 preview Web browser rendering a yellow star with text: $1.

Do I hear you say: "But Microsoft will get better at auto-correcting SVG"? Unfortunately, some errors cannot be auto-corrected.

Now let's take a look at how IE 9 will process an incorrectly constructed XHTML document. If the following document is served to IE 9 with a content type application/xhtml+xml, which is an explicit instruction to the Web browser to process content as XML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Hello world!</title>
</head>
<body>
<p>Hello World!
</body>
</html>

...IE 9 will display the document as follows:

Screen shot of IE 9 preview Web browser displaying the text: Hello World!

The correct behaviour of course would be to display an error message informing the user that the XHTML document is incorrectly constructed.

How do Web technologies get bastardized?

It starts with good intentions. I do believe that in IE 9 Microsoft is trying to make XHTML and SVG easy for developers to use. But history has shown that well intentioned but unilateral decisions by browser vendors have far reaching consequences for all stakeholders in Web technology. For example, Netscape was probably motivated by good intentions when they decided to silently auto-correct invalid HTML. That decision made the cost of developing Web browsers skyrocket, which in turn wiped out many competing browsers. That's why today even the richest companies in the world such as Google and Apple cannot afford to build Web browsers from scratch and instead rely on 3rd-party libraries.

How Microsoft can fix the problem

How browser vendors implement XHTML and SVG affects all stakeholders in Web technology. To Microsoft I say: Please consult with other stakeholders in Web technology regarding the parsing method for XHTML and SVG before the final release of IE 9.

Update: Mozilla follows Microsoft's lead. Pre-release versions of Firefox 4 parse inline SVG and MathML as HTML and do not display error messages if SVG or MathML markup contains errors.

Public comments

1. Posted by Richard
on Tuesday 2010-03-23 at 06:10:32 PST

It's a really tricky one. I take your point about the pricing information example but it is a little hypothetical, after all a web builder or content editor could just as easily mistype a digit in a text price code.
Ideally errors should be shown as errors, however if that rule was insisted on many many websites would display nothing at all (admittedly it might mean that more care is taken in coding properly which can only be a good thing). To give a counter example in a different field, my digital TV reception isn't perfect (which is odd given that we have direct line of site to the TV mast about a mile away) and every so often a glitch happens and the screen is pixellated or briefly frozen, however usually the sound carries on regardless (presumably because it is only a small fraction of the bandwidth and the buffering allows it to continue). If the digital receiver insisted on fully compliant information in its signal then it would freeze the sound and the picture and probably flash up an error message, but of course that would be much more irritating to me than the current setup.

2. Posted by Martin Kliehm
on Tuesday 2010-03-23 at 06:37:32 PST

Unfortunately it is impractical to serve XHTML with the correct MIME type when draconian error handling is in place. Even when your code is perfectly valid, it doesn't prevent mobile carriers from changing or adding invalid code to your markup. For example, some providers compress pictures further, but when you click on the picture you get an option to replace the compressed with the original image. That's done with JavaScript, alas they had the brilliant idea to add the script tag *after* the closing html tag, so there goes your valid document - say hello to error screen. Therefore I never serve XHTML as XML, and Microsoft's decision hurts my webstandards feelings, but it's the most pragmatic and reasonable approach.

3. Posted by Tim Jansen
on Tuesday 2010-03-23 at 07:11:59 PST

@Martin Kliehm: Are there any providers that actually modify 'application/xhtml+xml' content? Or do they only modify 'text/html' content?

4. Posted by Mike
on Tuesday 2010-03-23 at 09:12:28 PST

Maybe web developers should be empowered with an instruction that they can sent to browsers and ISPs that says don't modify the content I'm sending because it contains important info that I don't trust you to fix or compress or alter in any way. Maybe that instruction should be 'application/xhtml+xml'. Maybe Microsoft is taking that power away from developers.

@Richard, if your digital TV receiver continued to show the signal with errors but also kept a count and info on these signal errors that you as a user can access and review, I bet the TV carrier would get its finger out and fix the problems. But instead you as a consumer is kept ignorant to the actual quality you are receiving versus what quality you are paying for.

5. Posted by Tony Ross [MSFT]
on Tuesday 2010-03-23 at 15:44:43 PST

I want to jump in and try to clear things up a bit. An HTML parser is not being used for XHTML and SVG, nor is any attempt at fixing up the content being performed. The work to display XML parsing errors in IE9 simply hasn't been completed yet.

From the IE9 Platform Preview Release Notes(http://ie.microsoft.com/testdrive/info/ReleaseNotes/Default.html):

> XML Parsing Errors (affects XHTML and SVG)
> No notifications are currently displayed for XML parsing errors encountered
> while parsing XHTML or SVG. Note that even without notifications, parsing
> correctly stops and only content occurring before the error is rendered on
> the page.

FWIW, Chrome and Safari also display content occurring before the first parse error. They render the error message just above the page content.

6. Posted by Vlad Alexander
on Tuesday 2010-03-23 at 17:27:01 PST

Tony Ross [MSFT] wrote: "The work to display XML parsing errors in IE9 simply hasn't been completed yet."

Thank you for the clarification. Are you able to let us know:

1. Will the final release of IE 9 parse inline SVG (SVG markup embedded within an HTML document) the same way as external SVG?

2. Will the final release of IE 9 display SVG error messages to all users if inline SVG within an HTML document contains errors as in the following example:

<!DOCTYPE html>
<p>This is HTML and SVG in the same document!
<BR>
<svg width="200" height="100">
<circle cx="50" cy="50" r="45" fill-opacity=".5" fill="red">
<circle cx="100" cy="50" r="45" fill-opacity=".5" fill=yellow" />
</svg>
</p>

Additionally, would you be able to comment on whether or not there are plans to correct the way IE renders alternative text?

7. Posted by Mike
on Tuesday 2010-03-23 at 23:43:39 PST

>FWIW, Chrome and Safari also display content occurring before the first parse error.
Is that the behavior to imitate? Or are Firefox or Opera doing it better? I think there should be an open discussion about this and it would be good if all the browsers then implemented a consistent approach to XML error handling.

8. Posted by James
on Friday 2010-03-26 at 05:57:03 PST

Why are we even discussing how to handle XHTML ?
Even the W3C have officially killed it, so why would anyone care?

Incidentally, it was arguably the unilateral decision to create XHTML that caused this issue in the first place.

9. Posted by Vlad Alexander
on Friday 2010-03-26 at 09:02:53 PST

James wrote: "Even the W3C have officially killed it [XHTML] ..."

No, they did not. They stopped funding further development of XHTML 2, which is not the same XHTML 1.x that we are talking about. HTML5 will have XML version called XHTML5.

James wrote: "... so why would anyone care?"

Business runs on XML. Behind the scenes, business stores, transfers and processes content as XML (which includes XHTML). And given the opportunity, many businesses would elect to deliver content to end-users as XML.

10. Posted by Jeff Schiller
on Tuesday 2010-03-30 at 08:00:28 PST

Yep - as the Microsoft guy pointed out, this is clearly in the release notes/documentation for IE9 Platform Preview 1 that the error parsing in XML mode hasn't been implemented yet. Your term "bastardization" is a little harsh here.

As for your questions about SVG-within-HTML, you probably need to read the HTML5 spec. That specification defines how processing of foreign content (SVG/MathML) should be handled in a text/html context - things are different than in XHTML5 and I expect IE9 to follow the spec and you can leave off quotes in attributes or closing tags and still get things to render. That's just the fun world of HTML5.

11. Posted by Vlad Alexander
on Tuesday 2010-03-30 at 21:05:31 PST

Jeff Schiller wrote: "As for your questions about SVG-within-HTML, you probably need to read the HTML5 spec."
I could not find a description of error notification for embedded XML content within HTML documents in the HTML5 spec. I would appreciate it if you could point me to the relevant section of the spec that talks about this.

Jeff Schiller wrote: "I expect IE9 to follow the spec and you can leave off quotes in attributes or closing tags and still get things to render"
The browser vendors will implement a spec that they are writing themselves! If browsers will render incorrectly written SVG, then SVG authoring tool vendors will be forced to support this behaviour. My guess is that the SVG authoring tool vendors will see this as bastardization of SVG.

Comments are closed for this article.

Rebuilding The Web