CodeDread Blog » browsers

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%

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).

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.

Canvas/SVG Marketshare: Feb 2010

Jeff — Fri, 05 Mar 2010 01:44:03 +0000

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

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.

The Next Next Browser War

Jeff — Tue, 05 May 2009 01:38:30 +0000

I think the next next browser war will be about how to integrate online services into the browser itself – search plugins were only the beginning. As more and more people rely on things like GMail, Google Docs, Google Reader, and Google Maps it will only be natural for Google to integrate its online services into its Chrome browser. The question will be whether this is anticompetitive at all in the sense that the “hidden” APIs in Windows were considered anti-competitive. I do think Google will make its server-side hooks open and transparent (because it benefits by having other browsers integrate their services).

SVG Support Tables Updated

Jeff — Sun, 18 Jan 2009 22:15:44 +0000

Before we head out for vacation here, I decided to update my SVG Support Tables for a variety of implementations:

Opera 10 Alpha
Firefox 3.1 Nightly + SMIL Enabled
Safari 3.2
Chrome 1.0 (Windows only)
WebKit Nightly (r39960)
Corel SVG Viewer 2.1 Plugin (Windows only)

More About Chrome

Jeff — Wed, 03 Sep 2008 01:41:14 +0000

Things I Learned:

They borrowed some UI concepts from Opera and IE (controls and address bar inside the tabs, speed dial, paste-and-go) but I think they’ve done some things better. For instance: the default home page requires zero user interaction, the status bar is only present when you hover over a link, tab cycling makes sense and requires zero thought.
They really didn’t want to introduce another rendering engine for developers – so Google is simply using WebKit, it won’t be a fork
No tie-ins to Google Services installed by default
They’ve been working on it for two years
V8 will eventually make its way into Android
They haven’t made very many contributions to Webkit, but are fully committed to doing so. Their plan is to build Chrome off the WebKit tip
Extensibility – though they obviously support traditional browser plugins and they have plans for a richer extension API – it won’t be in the Beta.
UA String is: “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13″ =>Google, please work to shorten the UA string, not lengthen it (is there really any valid reason for “Safari/…” to be there?)
The browser is fast. Transition is seemless. I like that the default home page requires no user interaction to generate. Ctrl+L, Ctrl+K, Alt+D, Ctrl+T all work as I expected.
They are using an older version of WebKit (older than Safari 3.1 it looks like) as there are two SVG-related rendering problems with my site that I thought were long gone
They have a sense of humour (open up the Chrome Task manager and see the link at the bottom)

Further Exploration:

I’m curious how browsers like IE and Chrome are ensuring that access to the browser cache is shared efficiently across all processes?
I’d like to learn more about the ‘cross-platform’ graphics library that they are using, does it support hardware acceleration?
Are other browser vendors worried that the editor of the HTML5 spec is now an employee of a browser vendor?
What are Google Chrome’s plans for feeds? At the moment, there isn’t even any auto-discovery

Web Stats: Now With “MarketShare”

Jeff — Fri, 11 Jul 2008 06:07:08 +0000

I took 20 minutes and added a feature request to my SVG Web Stats web application tonight: Now you can switch the timeline graph from Traffic mode to Distribution mode, which shows the share of each browser on my site as a percentage of the total.

Continuing with the navel-gazing theme, some points I noted in my stats:

Opera and Safari now amount to 7-10% of my total unique visits
Since its release last month, Firefox 3 has about the same share as IE7, which was released over a year and a half ago (20% total)
IE has lost roughly 5% of total share on my site since I’ve started recording these statistics (this is my third year)
IE6 is still the browser version with the largest single share (roughly 30%). Give Firefox 3 a few more months though…
Virtually no one is using IE8 Beta 1, released over four months ago. I mean, way more people are using Firefox 3.1 pre-Alpha-1! I see at most one or two hits a week from IE8. Which makes sense because you can’t install multiple copies of IE and there aren’t very many cool things you can do with IE anyway.

UEB: Putting The U In Web

Jeff — Fri, 20 Jun 2008 18:41:43 +0000

Via Dion’s twitter, this article about a Universal Edit Button (UEB), the discussion has started to make the rounds. The idea is to make editability as discoverable as syndicatability. Whoof, those are some mouthfuls. Ok, you know that orange feed button you see when a page has a feed? Well this will maybe add a green button for those pages that can be edited, like wikis.

What is a little concerning to me is that browser extensions and wikis are already modifying their code to make this discoverable, yet no decision has been firmly made on how it should be represented on websites. This is a recipe for pain and confusion. Personally, I prefer the <link rel=”edit”> suggestion (NOTE: That’s a wiki so it’s subject to change). I hate that rel=”alternate” is so overloaded. I also disagree with the idea that a ‘wiki’ should be a separate MIME type – to me, the MIME type describes the format of the media (HTML, SVG XML, Atom XML), not its use. But who knows, I may get shouted down…

Another interesting thing – once we’ve standardized on a way of advertising that a web page is editable, it will be an open invitation to every spammer out there to take advantage of it. I’m sure they already know how to recognize the most popular wiki software, but perhaps this will pose a threat to somebody trying to implement their own little wiki. Personally I think the benefits do outweigh the drawbacks, so I say ‘into the breach’.

Go join the discussion over at unversaleditbutton.org.

Anyway, once that’s all been decided, then I would expect to see this link present in wikimedia and on other sites throughout the web. I also expect that browsers will adopt it – but it will be interesting to see how they do so. The address bars are already pretty cluttered – Firefox 3 has the favicon, the address, a star, a feed link, a pull-down arrow and now folks want to add a little pencil… Of course not all such images need be present for every site, but I’m just saying that browser makers are pretty sensitive to outsiders trying to impose chrome changes.