CodeDread Blog » SVG

SVG/Canvas Marketshare: Nov 2010

Jeff — Tue, 21 Dec 2010 17:31:48 +0000

I’ve updated my marketshare spreadsheet for Nov 2010 charting the percentage of web users who can view SVG and Canvas: 44.57%

I’m also tracking what percentage of web users can see SVG in an <img> tag: 18.41%

Start Chopping Off Heads

Jeff — Tue, 21 Sep 2010 17:02:10 +0000

Because my kids are now old enough to grok some complex games, I’ve introduced them to the Magic: The Gathering card game. They love it. I love it. To continue the fun, we went to a local comic book store and bought a couple booster packs, which apparently are still being sold throughout the world. One of my kids got a Protean Hydra. Sweet! The Hydra is a mythical beast with nine heads, and every time you chop off a head, two more grow back.

The web is like that. And we’re not chopping off heads fast enough.

Now that Internet Explorer has come out of its corner swinging with SVG support, I figured it’s time to make sure we can actually deploy web pages with SVG content in them. Did you know that there are at least thirteen ways to deploy SVG on the web?

inline in HTML5 as not-XML (or !XML as I like to call it)
inline in XHTML (1.1 or 5) as XML
via the HTML:img element
via the HTML:object element
via the HTML:embed element
via the HTML:iframe element
via the SVG:image element
via the SVG:foreignObject element
as a fragment via the SVG:use element
via the background-image CSS property
via the list-image CSS property
via the border-image CSS property
directly linking and then browsing to a SVG file

Does anyone know why the <embed> element was not deprecated in HTML5? Was it the realities of the IE deployment difficulties around the <object> tag? It sounds like IE9 will help to fix that so maybe <embed> can eventually be deprecated in HTML6 five years from now?

What’s worse is that the properties on the embedding context and the SVG elements affect how the SVG is rendered. The width/height properties on <object>/<embed>/<iframe> tags. The width/height/viewBox properties on the <svg> element. The preserveAspectRatio attribute on the <svg> element.

The width attribute on a <svg> element can be specified in units of em, ex, px, in, cm, mm, pt, pc or it can be unitless or it can be a percentage. Of course the height attribute can be specified in different units.

The embedding context also determines whether scripts are run within the SVG document. Hint: Should not be run in image contexts.

But it gets worse. Let’s just look at one case: embedding an SVG document in a web page via the <object> tag:

<object type='image/svg+xml' data='...'></object>

For the data attribute you can specify a local file, a http/https URL or a data URI. The browser can treat each of these cases differently.

The file served to the browser can have a MIME type of image/svg+xml or text/xml or application/xml. Browsers might do something different in these cases (though they shouldn’t).

If the width/height on the <object> tag are specified, they should override the <svg> width/height if the <svg> width/height are in absolute (not relative/percentage) units. The coordinate system of the SVG should map to the viewBox attribute unless the viewBox attribute is not specified, in which case it should be inferred. Got all that?

If width/height on <object> are not specified, and width/height of the SVG are specified in absolute terms, then the size of the <object> frame should change to match the size of the SVG.

If width/height on <object& are not specified on a Tuesday of a leap year, and the SVG document has an odd-number of bytes in it and includes the string ‘rick’ or ‘roll’ anywhere in it, then the browser should play a video instead.

I’m not making this up, it’s right here in the spec.

Actually the difficulty of this case is that there are so many dimensions and that it’s spread across multiple specs: HTML, CSS, SVG. I think WICD/CDF was supposed to address some (all?) of these cases, but … are those specs actually valid? And by that I mean, are browser vendors paying attention to them? As Dolores O’Riordan might say: Does anyone care?

There’s something to be said for the simplicity of the iPhone’s “one” button. Android’s addition of the “Back” button is a perfect example of how a system can be incrementally improved.

Anyway, I’ve started to look at just three dimensions of this n-dimensional problem: the HTML embedding context, width/height and viewBox. I wrote a test case showing the 16 possible combinations. I was not really shocked that between all the four major browser engines, only one case displayed consistently across all latest builds: as an <img> with width/height specified on both <img> and <svg>.

I’m really tired of reading specs (I’m sure this will pass), so in absence of a reference rendering of this page, we’ll just need to do what we always do: Make it look the same across all browsers. Now that we have IE9, it can act as a tie-breaker between renderings that could be argued one way or the other

Hopefully I’ll be able to talk more about these 16 cases in the future. Now you know where to come if you’re having trouble sleeping.

SVG/Canvas Marketshare: Aug 2010

Jeff — Sun, 12 Sep 2010 16:33:21 +0000

I’ve updated my marketshare spreadsheet for Aug 2010 charting the percentage of web users who can view SVG and Canvas: 41.08%

Still looking for more stats sites – it seems that W3Counter is also not reliable (their public web stats for August were still not generated as of Sep 12th).

New Shit Has Come To Light

Jeff — Fri, 10 Sep 2010 17:04:34 +0000

Those wacky Mozilla guys just fixed a bug I’ve been waiting years for: They now support SVG in <img> tags (and in most image contexts, for example background-image). This will be available in Firefox 4 Beta 6 and beyond (or download a nightly).

See SVG really has two roles on the web scene: as document and as image. For a long time I’ve been really excited about SVG-as-a-document because web documents have a DOM, are scriptable, can be styled, have semantics – that goody bag is really stuffed. I’ve been less excited about SVG-as-an-image because frankly it hardly worked anywhere and I had no prospect of the situation improving. Now that Firefox is finally onboard and IE9 is waiting in the wings we are about to embark on a new era of capabilities for the web that we can begin to rely on in less than a year.

Why is it important?

For one, SVG-as-an-image means that your images scale perfectly at any screen resolution. This will generally mean crisper images than their uncouth raster cousins with no lossiness.

For two, SVG images can be smaller in size than their equivalent raster counterpart (especially when gzipped). This is dependent upon the level of detail you’ve put into the image and the tools that produced the image. Tav just published an article about how to improve this and I’ve talked long about scour in the past too. Keep up, will ya?

So SVG images can look better and have fewer bytes than their raster counterparts. Booyahs all the way around.

And they can go a lot more places than the <object> tag. Feed readers, for one.

Of course there are challenges:

Not ubiquitous. Yet. We have to wait at least a year or more for that to be the case on the desktop but now there is definite momentum. Android appears to be the only holdout on the mobile web side and it’s being looked at. Let’s circle back in a year, mkay?
Performance? SVG images have more capabilities than a standard raster image (declarative animation, external styling) so I would suspect SVG images require more juice to display. Rob and others talked about SVG performance at this year’s SVG Open. Frankly I suspect that things can be done on the browser side to optimize this case, so I look forward to learning more when you comment on my blog
Lot of crufty SVG out there. This situation is improving too over time.
Some SVGs don’t have an intrinsic size (gee I hope I’m using this term right) and most things expect an image to have a size. PNG files contain their width/height in the bytes of the file header. The width/height values on <svg> elements default to 100%/100%. Some browsers have a problem with this (ok, WebKit mostly). If you want to use SVG files as images, I suggest you start fixing WebKit bugs (or update your SVG files to have an explicit width/height). Can someone (Doug? Fantasai?) clarify what is supposed to happen if an SVG file has width/height at 100% and the <img> tag does not specify a width/height?
Not a lot of software/services accept SVG as an image type yet. I’m looking straight at you to help me change this.

So my take is that we’re at about 15% of web users who can actually see SVG images (as compared to about 40% of web users that can see SVG documents). Since I’m such a SVG ~~fascist~~ fan I’ve decided to change my WordPress clipart quicktag to use <img> instead of <object>. This means that a lot of you Firefox users won’t be able to see my blog clipart and for that I apologize up-front. Come back and read it when you’re using Firefox 4?

SVG/Canvas Marketshare: June 2010

Jeff — Sun, 11 Jul 2010 06:47:33 +0000

[clipart]I’ve updated my marketshare spreadsheet for June 2010 charting the percentage of web users who can view SVG and Canvas: 41.49%

Note that I added “Canvas” back into the title of these blog posts, now that it is public that IE9 is supporting the HTML5 <canvas> element. I’ve also added SVG-as-an-image (usable inside <img> or as a CSS background-image), since that’s something that seems likely to be supported soon by all browsers (Firefox 4, IE9).

P.S. This figure does not take into account any user that has a SVG plugin installed or authors who have used the excellent SVG Web or excanvas shims, so this is really a worst-case number.

IE9: No longer failing

Jeff — Thu, 24 Jun 2010 16:24:26 +0000

[clipart]Ok, after getting IE9 preview 3 installed last night, I was able to update my SVG scorechart. I’m pleased to say that I would now unequivocally classify IE9 as a browser that supports SVG. Supporting gradients, patterns, masking, clipping and more actually gained them quite a few points.

I’m also pleased to see that they support conditional processing (the <switch> element) so you can see at a rough glance what feature strings they claim to support by accessing this page I made years ago. Not a bad feature set for first time out! Kudos to the IE team!

And they support <canvas> too!

In my brief look at IE9 while running through the SVG tests, I would say their biggest areas to improve on before final release are text (especially text selection) and DOM. Though Alexis assures me that they do pass quite a number of SVG torture tests.

Hey, now that we have all major browsers supporting basic SVG rendering, it’s really time to ramp up the effort on SVG Torture Tests to ensure DOM coverage and corner cases. We are looking for someone to lead this activity in the SVG Interest Group.

Oh, and I would love to have SVG-edit working in IE9.

SVG Marketshare: May 2010

Jeff — Mon, 07 Jun 2010 05:46:05 +0000

[clipart]I’ve updated my marketshare spreadsheet for May 2010 charting the percentage of web users who can view SVG: 40.55%

P.S. This figure does not take into account any user that has a SVG plugin installed or authors who have used the excellent SVG Web shim, so this is really a worst-case number.

SVG Marketshare: April 2010

Jeff — Thu, 06 May 2010 19:12:56 +0000

[clipart]I’ve updated my marketshare spreadsheet for April 2010 charting the percentage of web users who can view SVG: 40.26%

P.S. This figure does not take into account any user that has a SVG plugin installed or authors who have used the excellent SVG Web shim, so this is really a worst-case number.

SVG/Canvas Marketshare: Mar 2010

Jeff — Mon, 05 Apr 2010 01:16:42 +0000

[clipart]I’ve updated my marketshare spreadsheet for March 2010 charting the percentage of web users who can view SVG/Canvas: 39.99%

Link to spreadsheet

P.S. I should mention that this figure does not take into account any user that has a SVG plugin installed or authors who have used the excellent SVG Web or ExplorerCanvas shims, so this is really a worst-case number.

To And Fro

Jeff — Wed, 31 Mar 2010 13:45:23 +0000

[clipart]Issue 70 has been open for awhile now. In fact it’s one of just a handful of two-digit bugs left in SVG-edit. Now that all browsers have heralded support for SVG into the future, one might argue that the need for this bug will evaporate in a couple years. However, one would be wrong. First, there are lots of mobile browsers out there. Second, in some cases it could be easier to just tell the browser how to draw a collection of dots rather than mathematical instructions (think thumbnails). So how to solve it?

One thought that occurred to me is if I can shove the SVG into a HTML5 Canvas element, I can then call toDataURI() on it to generate a PNG. Unfortunately only Opera seems to have experimented with loading SVG into a Canvas directly. Also, there are many effects that can be done in SVG that cannot be done in Canvas (filters, fonts, and more).

The Canvas2D API does mention that in the future, the svg:image element may support the CanvasElement DOM interface. I’m anticipating Microsoft to announce <canvas> support for IE9 later this year and probably to support this interface on svg:image elements. It’s one way they can innovate on the web standards front while they continue to catch up to other modern browsers.

This would be good, but why only the svg:image element? I’d argue that any element that contains some geometry could gain the toDataURI() method (particularly useful would be the <svg> element here).

Until such time as browsers all get in sync, there are other options. canvg is one such option and I’ve been dutifully raising bugs and writing teeny patches but there’s a long ways to go for a robust solution.

Ultimately this is another case of why am I doing something in script that all browsers already know how to do? You really have to think long-term in the web space, don’t you?

Other ideas?