CodeDread Blog » Web

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%

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?

Moving Right Along

Jeff — Fri, 07 May 2010 22:28:37 +0000

[clipart]When I started programming it was on the Commodore 64 (uh oh, you know this is going to be a long story – go take a piss first). I started with Basic and then eventually moved to assembly language to try and write a Bard’s Tale clone with a friend. We got pretty far. I just came across the notebooks where I had scribbled all those assembly routines too – great times! But by the time we got close to having something we could call a game, Commodore had lost the battle and the IBM PC clone market was taking off. Different instruction set, different hardware and capabilities. Doh!

[clipart]My next foray into the world of programming was DOS-based in C/C++ using Borland’s Graphics Interface (BGI). I even wrote an Expanded Memory manager at one point when 640kb of RAM just wasn’t enough. Borland had a great compiler for students of C/C++, everyone was using it and it was affordable, so I didn’t really think twice about using Borland’s technologies. Plus, it was all I had.

[clipart]When it became obvious that DOS had lost the battle and the world was moving to Microsoft Windows, I moved on again. First with Borland’s long-forgotten Object Windows Library (OWL) and then, when it was clear that Borland itself had lost the battle, I moved on to to the Microsoft Foundation Classes (MFC) and then just straight access to the Win32 API. At that time I had Microsoft Visual Studio 6 – what an awesome IDE.

[clipart]Windows GDI lacked power so I eventually moved on to Microsoft’s DirectX (DirectDraw and then Direct3D). This was at a time when the entire known computing world was using Microsoft Windows. I barely thought twice about using Microsoft technologies. You go where the technology can be accessed.

[clipart]Along the way, I picked up a little of Sun’s Java at work because the entire known computing world was predicting how big it would be. Not too soon after that IE6 plateau’d and Microsoft had started really losing developers to Java, Flash and the web. Microsoft needed to “invigorate” their platform. I think “invigorate” is another word for “developers are way sick of the Win32 API, how can we win them back?” Markup alongside managed code was to be the future. They introduced C# and started work on Avalon which became Windows Presentation Foundation (WPF) and Silverlight.

Except this time I didn’t go along for that ride. I kind of got tired of learning some new technology in my spare time, becoming proficient enough to write non-trivial software and then having the ecosystem replaced by something else. I had also started getting interested in open source and cross-platform capabilities because Linux was getting a lot of nerd-love and Microsoft distrust was so high.

[clipart]Sadly, my learned skills in the Win32 API, GDI, MFC are now completely useless to me. DirectX is becoming less and less relevant with the rise of alternative platforms. Even supposedly cross-platform frameworks like Qt, Java and SDL mean that you are locked out of some mobile platforms.

So what’s the point of my illustrious technology roll call and rambling history above? I wasn’t trying to put you to sleep there, promise.

Why do I have to keep learning technologies only to have them killed or moved around or not accessible on major platforms? I’d rather take already-learned skills and apply them to a new area. And putting all your eggs in one company’s basket just doesn’t seem like a good idea to me. I don’t care if that company is Commodore, Borland, Sun, Oracle, Trolltech, Nokia, Microsoft, Apple, Google or <insert name here>.

And that’s why I believe the Web will eventually win as The Platform: No one company controls it – they all contribute. JavaScript and DOM and CSS skills can now be applied to graphics as well as hyper-text. Fonts. 3D graphics. Video. Audio. Access to the file system. New APIs for accessing device capabilities (like touch screens, accelerometers, webcams). And remarkably, all browsers seem to be generally moving in the same direction, with innovations being fed back into stream.

No device ships without a browser – it would be suicide. The Web is universal. As is HTML (where HTML = a collection of web technologies).

[clipart]What we have here is a platform that is continuously and incrementally evolving, has loosely-coupled technologies, that no one company controls, requires zero install from the user and is ubiquitous. And it grew from just these tiny little seeds sown in the previous decade. That’s poetry.

Me like.

Scrubs

Jeff — Sun, 17 May 2009 19:59:40 +0000

SVG is a pretty flexible format. Vector graphic editors often inject a lot of extraneous data to make their job easier. Unfortunately this excess data is just ignored by browsers and from that perspective just looks like bloat. In my opinion, output from editors such as Inkscape or Adobe Illustrator are not quite ready for the web, especially for purposes like clip-art. It’s not at all rare to find files up on Open ClipArt with large chunks of the file that are not even used (extraneous gradients, filters, etc). I had an itching to learn a little Python so I used this as an excuse to create a script that would tidy up SVG files: Scour.

The SVG Posse, Doug Schepers, attended the Libre Graphics Meeting this month in Montreal and gave a quick 5-minute talk on the script, which was kind of fun for me to watch.

Note that the purpose of this script is to make the SVG documents ready for web browsers – it shouldn’t be used on files that have already been manually edited. The script strives to maintain a visually identical image, but it does not preserve all semantics (for instance, it might collapse groups). I provide switches to turn off some features, but not all. In addition, it doesn’t handle external CSS or <style> elements yet.

Anyway, time to start using the script. Download it. Ask questions. Open bugs. Request features. Send me patches.

Happy AdaLovelace Day

Jeff — Tue, 24 Mar 2009 18:33:40 +0000

Happy AdaLoveLace Day to Shelley Powers. I happened to be browsing through some blogger’s archives marveling at how many posts are just no longer intelligible (this and this are good examples). It’s a shame that many of her older writings are no longer around (or are they?). Shelley’s had an interesting life so far. I look forward to continuing to learn from her.

First Post!!1!

Jeff — Mon, 01 Dec 2008 08:40:28 +0000

To help kick off the new SVG community site, I thought I’d write up a tutorial and post it there. It’s a quickie and it’s maybe a couple years out of style, but it’s got some pretty pictures: Gelcap Buttons in SVG. (Some people call these ‘aqua buttons’).

Disclaimer: The PlanetSVG website is still largely under construction, so please be gentle. Rob is working on a Drupal theme and we still have to plan out the overall flow of the site.

Painting the Web, Having Fun

Jeff — Sun, 17 Aug 2008 20:07:01 +0000

I received a copy of Shelley Powers‘ new book, Painting the Web about a month ago. Sadly I was pretty busy with work and other projects so I wasn’t able to devour it as quickly as I’d hoped – though I did take a moment to squee over the fact that my SVG Support page is in the book. Ok, this review might be biased

The first thing that struck me about the book was how thick it was – clocking in at over 600 pages. I had expected the book to be something I could take with me on the train to work each day. However, I prefer my vertebrae unfused, so I had to be happy with reading it at night. Maybe I should have investigated the eBook side of things…

The second thing I noticed: Every image in the book is full color. I don’t think I’ve ever seen a tech book do this, though I haven’t bought a tech book in a couple years. Usually there will be a few glossy pages in the middle of the book that show some color plates, but not every image. It’s a delightful surprise that must have been costly for O’Reilly. Yet the book is actually reasonably priced at $45 USD at Border’s – even cheaper on Amazon.

Ok, moving on to actual content… I’m actually only just a little over 1/3 of the way through the book and only have just begun reading the vector portions (beginning of Chapter 7). But here are some notes/thoughts so far:

I like that Ms. Powers has made it a point that the contents of this book should be accessible to everyone – even those that have no budget for graphics tools. The focus of the book is that the web graphic artist must have fun. In fact, this is the title of the first chapter.
Photography and photo manipulation are not big parts of my personal web experience, but it certainly is a wildly popular thing for a lot of people. Chapters 3 and 4 contain a lot of info about color profiles, curves/levels, image formats, photo editors, online photo galleries (including an introduction to Gallery2) and more.
Some interesting bits about web design in Chapter 4. I actually did not realize that Opera comes with a ‘mobile emulator’. Now that I actually have a mobile data plan, I’ve begun to realize how important this is. For example, my site will not currently load up on my mobile browser, though I wouldn’t exactly call my mobile browser ‘modern’. My next theme redesign will definitely take into account the mobile web.
Chapter 5 discusses lots of really interesting effects (3D and aqua buttons, reflections). By describing how these effects are generated using layers, gradients, blurs, and masks, one starts to visualize how these individual techniques can be combined to produce other effects seen on the web.
Chapter 6 gives us a good introduction to some vector graphic formats, including a glimpse at VRML and X3D. I would have liked to learn a little bit more of X3D, maybe I should find some time to do that.

All in all, it’s been an interesting read. Now on to what I’m most interested in: Vectors. More to come…

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.

Web Apps: The Critical Difference

Jeff — Tue, 22 Apr 2008 04:58:31 +0000

One reason I think Web Applications (as opposed to the now watered-down term of Rich Internet Applications) are great for users and developers, is because they do not need to be installed directly on the user’s computer. This is one thing I think Adobe has misunderstood about the ‘RIA’ revolution with AIR.

Caveat: I’ll be the first to admit I have zero experience with AIR (or Mozilla Prism for that matter), so if anyone can educate me, please feel free below.

If I’m a desktop application developer, I’ve got to decide on a language and framework. Is it easier to build an application using HTML+CSS+DOM+JavaScript (+SVG+XUL) or to use Flex+ActionScript or to use C#+CLR or to use Java+JDK or to use C++ with Qt/Gnome?

I think Adobe is right that picking from the “Open Web” stack is a slightly easier in-road to application development due to the declarative nature of the markup and the lack of a compilation step. But I don’t think it’s why web applications are seeing such an upsurge. To me, the answer is the complete lack of a need to worry about deployment (web app developer) or installation (web browser user). The fact that the web app developer does not have to maintain older legacy code is also a huge win. Once a new version of your application is released, no one in the world is using your older code, it’s instantly retired.

Here’s a snip from AIR’s own documentation where it states:

“On Mac OS, to install an updated version of an application, the user must have adequate system privileges to install to the application directory. On Windows, a user must have administrative privileges.

If the updated version of the application requires an updated version of the runtime, the new runtime version is installed. To update the runtime, a user must have administrative privileges for the computer.”

To me, the bits about the runtime sounds like the same sort of mess that Java and .NET application deployment have with mismatched JREs and CLRs for the past decade. Hopefully changes to the underlying platform are kept minimally disruptive – but the developer really has no control over that.

It does sound like Adobe is trying to make it easier for application developers to employ auto-update functionality (incidentally, so is Sun). It just sucks that each developer has to worry about this individually still.

To me, the sweet spot with these Light-weight Offline Application Frameworks (LOAFs?) will be when enabling auto-update is as easy as it is with Firefox extension development. But that still doesn’t solve the problem of every user having to first download the runtime to ‘bootstrap’ him/herself.

And yes I’m aware that there are some big down-sides to Web Applications. Lessee, differing behavior of platforms (user agents) is the biggest cost. Lack of local storage (which may change in a decade with HTML5) and the cost of a server are also biggies.