Category: SVG

Recovered from the Wayback Machine.

Sam Ruby quotes a comment Microsoft’s Chris Wilson made in another weblog post:

I want to jam standards support into (this and future versions of) Internet Explorer. If a shiv is the only pragmatic tool I can use to do so, shouldn’t I be using it?

Sam responded with an SVG workaround, created using Silverlight–an interesting idea, though imperfect. Emulating one technology/specification using another only works when the two are comparable, and Silverlight and SVG are not comparable. When one specification is proprietary, the other open, there can be no comparison.

There was one sentence of Sam’s that really stood out for me:

You see, I believe that Microsoft’s strategy is sound. Stall, stall, stall, and generate demand, demand, demand.

Stall, stall, stall, and generate demand, demand, demand. Stalling on standards, creating more demand for proprietary specifications, like Silverlight. Seeing this, how can we be asked to accept, once more, a Microsoft solution and promises that the company will, eventually, deliver standards compliance? An ACID2 picture is not enough. We want the real thing.

Jeffrey Zeldman joins with others in support for the new IE8 meta tag, based on the belief that if Microsoft delivers a standards-based browser with IE8, and companies adopt this browser for internal use, intranets that have been developed specifically to compensate for IE shortcomings will break, and Microsoft will be held liable. According to statements he’s made in comments, heads will roll in Microsoft and standards abandoned forever:

…the many developers who don’t understand or care about web standards, and who only test their CSS and scripts in the latest version of IE, won’t opt in, so their stuff will render in IE8 the same way it rendered in IE7.

That sounds bad, but it’s actually good, because it means that their “IE7-tested” sites won’t “break” in IE8. Therefore their clients won’t scream. Therefore Microsoft won’t be inundated with complaints which, in the hands of the wrong director of marketing, could lead to the firing of standards-oriented browser engineers on the IE team. The wholesale firing of standards-oriented developers would jerk IE off the web standards path just when it has achieved sure footing. And if IE were to abandon standards, accessible, standards-compliant design would no longer have a chance. Standards only work when all browsers support them. That IE has the largest market share simply heightens the stakes.

From this we can infer that rather than Pauline, the evil villain (marketing) has standards tied to the railroad tracks and the locomotive is looming on the horizon. If we ride to the rescue of this damsel in distress, though, what happens in the next version of IE? Or moving beyond the browser, the next version of any new product that Microsoft puts out that is supposedly ‘open’ or ‘standards-based’? Will we, again, be faced with the specter that if we rock the boat, those who support standards in Microsoft will face the axe, as standards, themselves, face the tracks? There’s an ugly word for this type of situation. I don’t think it’s in Microsoft’s best interest if we start using this word, but we will if given no other choice.

If Microsoft really wants to make the next version of IE8 work–both for its corporate clients and with the rest of us–in my opinion it needs to do two things.

The first is accept the HTML5 DOCTYPE, as a declaration of intention for full standards compliance. Not just support the DOCTYPE, though. Microsoft has to return to the HTML5/XHTML5 work group and participate in the development of the new standard.

The next step is, to me, the most critical Microsoft can take: support application/xhtml+xml. In other words, XHTML. XHTML 1.1 has been a released standard for seven years. It’s been implemented by Firefox, Safari, and Opera, and a host of other user agents. There is no good reason for Microsoft not to support this specification. More importantly, support for XHTML can also be used as a declaration of intentions, in place of the IE8 meta tag.

This is Microsoft meeting us half-way. It gives a little, we give a little. Microsoft can still protect it’s corporate client intranets, while we continue to protect the future of standards. Not only protect, but begin to advance, because the next specification Microsoft must meet will be support for SVG. Perhaps it can use Silverlight as the engine implementing SVG, as Sam has demonstrated. However, if the company does, it must make this support part of the browser–I’m done with the days of plug-ins just to get a browser to support a five year old standard.

Microsoft is asking us to declare our intentions, it’s only fair we ask the same of it. If Microsoft won’t meet us half-way–if the company releases IE8 without support for the HTML5 DOCTYPE or XHTML, and without at least some guarantee as to when we’ll see SVG in IE–then we’ll have our answer. It may not be the answer we want, but it will be the answer we need.

I would rather find out now than some future time that Microsoft’s support for standards is in name, only. At the least, we’ll know, and there will be an end to the stalling.

Anne Van Kesteren:

A new survey reveals that at least Microsoft and IBM think the HTML charter does not cover the canvas element.

I have to wonder, when reading the survey results, how much the people who voted actually used either SVG or the Canvas element. I covered both SVG and the Canvas Element in the book, but I focused more on SVG. Comparing the two–SVG and Canvas–is like comparing the old FONT element with CSS.

The Canvas element requires scripting. The SVG element doesn’t, even for animation if you use the animate elements. In addition, mistakes in SVG can be fun, as I found when I missed a parameter value in mistaken animation. A couple lines of markup. No script. Both Opera and Safari do an excellent job with the animation elements. I’m expecting Firefox to join this group in the next year.

If you use scripting, you can access each element in the SVG document as a separate element. You can’t do that with Canvas.

I still don’t think the Canvas element should be part of a new HTML 5, whatever the grand plans. However, since all but IE supports the Canvas element, it would be foolish to drop it. A better option would be to consider the Canvas element a bitmapped version of SVG and create a separate group to ensure it grows in a standard manner.

I did like what David Dailey wrote in the survey results:

I have considerable ambivalence about <canvas> as I have noted previously. If we were designing HTML 5 from the ground up , SVG and canvas ought to share syntax and ought not to duplicate so much functionality. <canvas> brings a few needed things with it, though it seems rather a bit of poor planning on the part of the advocates of <canvas> that has gotten us to this point. Those historically frustrated with W3C chose to ignore SVG and now seem to want W3C to ignore SVG in favor of a lesser technology. At the same time, <canvas> does enable client-side image analysis by giving the developer access to pixel values, and that alone allows for some tolerance of what otherwise seems to be a curious decoupling of reason from politics. Does it re-invent the wheel? — only about 95% of it is redundant with 20% of SVG.

As for all the discussion about semantic API…years ago I, and others, made a fight for a model and associated XML vocabulary, RDF, we said would stand the test of time and hold up under use. The road’s been rough, and few people are going to defend reification, but RDF fuels the only truly open social graph in existence. Five years ago. That was about the time when everyone believed that all we’d need for semantics was RSS. Including Microsoft.