CodeDread Blog » Software

Binary Tools for JavaScript

Jeff — Mon, 19 Sep 2011 05:23:45 +0000

As promised, I have a tiny thing to announce here. I recently split off and refactored the code that deals binary data in kthoom into a new open source project: http://bitjs.googlecode.com/, Binary Tools for JavaScript.

The faster and faster JavaScript engines in modern browsers and the rise of new technologies like Typed Arrays, Web Workers, and the File APIs mean that browsers can actually be used to read in binary formats completely on the client-side (as long as native performance isn’t a requirement).

For now the library includes two main capabilities:

streams for reading in bits and bytes from a Typed Array
unarchiving zip, rar or tar files (that’s right, you can unzip and unrar in JavaScript now)

One step closer to image editing on Wikipedia

Jeff — Thu, 24 Feb 2011 04:44:59 +0000

Oh, I forgot to mention a cool thing that happened at the beginning of the year while I was so busy: Wikipedia inched a step closer to having an in-browser editing experience for its impressive collection of vector image files via an experimental MediaWiki Extension. The extension was put together by Brion Vibber of StatusNet and WikiMedia fame. Fingers crossed for this to one day appear in Wikipedia!

TypedArrays make me theoretically happy

Jeff — Wed, 23 Feb 2011 17:11:10 +0000

I’ve been busy at my day job not launching code, but over the weekend I had some fun converting kthoom‘s unzip/inflate algorithm from using binary strings to using Typed Arrays. Typed Arrays mean native binary data that is accessible to JavaScript in the browser, making operations like unzip much much faster (like 4x).

Unfortunately browser support is limited to WebKit nightlies (Chromium 11) and Firefox 4 at this time. To compound this, Firefox did not bother to implement FileReader.readAsArrayBuffer() which means you can’t use the File API to read in binary data yet… uh… WTF? So basically I no longer support Firefox in kthoom. Oh well, the performance benefits cannot be ignored and they’ll eventually get there. Bug.

That’s not to say WebKit is all peachy-keen. You currently can crash Chromium OSX nightlies by creating an ArrayBuffer of unusual size and there are some issues passing ArrayBuffers into web workers. This means that I disabled use of Workers in kthoom as a result and everything happens in a single thread. :-/

Oh, and you can’t easily convert bytes from TypedArrays into strings…

FML.

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%

Grooveshark rocking teh HTML5

Jeff — Sun, 05 Dec 2010 05:53:30 +0000

Grooveshark recently deployed an updated UI done in HTML5 instead of Flash. In a word, it’s awesome. Scrolling is smoother. Text is fully selectable. I like being able to resize the UI (I don’t think their previous Flash interface allowed zooming at all). I really hope Grooveshark can find a successful revenue model that will keep it alive.

But this just seems to be part of the overall growing trend towards sexy HTML5 user interfaces. Netflix is another one as described in their recent post.

The industry has been steadily shifting into the next phase of web development for a couple years – we’re nearly there now. Well since IE6 is no longer a concern (or hadn’t you heard – less than 5% of web users last month and still dropping), IE7 is quickly shuffling off the stage (~12% and steadily dropping), and IE9 is waiting in the wings.

Oh and IE8?

Yeah I don’t share in the pessimism of some who think that IE8 is the new IE6. And there are a lot of reasons I don’t:

Month-by-month, the total marketshare of all IE versions combined has been steadily dropping. From 95% six years ago to about 50% now. Any gains on this percentage will be with IE9, not anything older.
There are now more major modern browsers and platforms than ever before supported by companies with lots of cash and lots of push.
Unlike IE6 at the time, IE8 simply does not have the capabilities expected of the average web developer. Given the numbers in my first point, next year there will be more users supporting SVG, Canvas, HTML5 audio/video than don’t. It makes mathematical sense to target modern browsers first.
In a year and a half, Windows 7 went from nothing to a quarter of all desktops. At the end of next year, I predict XP users will be a minority among Microsoft desktops. Any Windows 7 users will be using IE9 in a year, not IE8.
Google’s Chrome Frame plugin can be used to target IE8- users if you can convince them to download/install it. Disclaimer: I work for Google.

As for my own responsibility as a web developer… well, I’ve been developing for IE9+ for about 5 years now. I just didn’t know it at the time

SVG/Canvas Marketshare: Oct 2010

Jeff — Tue, 09 Nov 2010 17:07:49 +0000

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

I also started tracking what percentage of web users can see SVG in an <img> tag: 18%

SVG/Canvas Marketshare: Sep 2010

Jeff — Sun, 10 Oct 2010 17:28:33 +0000

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

I also started tracking what percentage of web users can see SVG in an <img> tag. Currently that’s at about 16%, up from 8% a year ago. I expect that number to soar dramatically once Firefox 4 and IE9 are released.

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?