CodeDread Blog » RIA

kthoom!

Jeff — Mon, 12 Apr 2010 12:55:51 +0000

[clipart]Sometimes I get an idea and I just have to see it through to a point where it will let my brain go. At work Thursday we were all slobbering over Steve’s iPad and someone brought up how cool the Marvel app is. I had to admit it was much nicer than any piece of software I’d used for viewing comics before on my laptop.

In the meantime, I’ve been carefully watching WebKit creep closer and closer to implementing the W3C File API (Go Kinuko!). Something I’ve been eagerly waiting for more browsers to do so you can open up local files in SVG-edit.

And then it hit me.

Why not a comic book reader done directly in the browser?

In case you don’t know, comic book archive files are just ZIP or RAR files containing JPEG images. Browsers can handle images. Some browsers can now handle opening local files. Even binary ones. So theoretically you could write unzip/unrar in pure JavaScript, extract the JPEGs, turn them into data: URIs and shove them into an <image> element. You can even do the unzipping in a separate thread using Web Workers.

Theoretically.

kthoom was how far I was able to get in a weekend.

Some limitations:

Unzipping is slow. None of the code has been optimized yet and I’m probably doing a lot of really stupid things.
Only supports CBZ files, not CBR files at the moment – I am accepting patches
Unzipping is really slow. I need to provide visual progress reporting from the Web Worker thread, I know.
kthoom will crash Firefox 3.6 about half the time. Firefox nightly (3.7) seems to handle it just fine. I opened this bug.
Did I mention that unzipping is slow?

If I’m honest, this was really an exercise to see just how easy/hard it would be to do something like this in the browser – and to get some hands-on experience with Web Workers. And hey, I’m not the first or even second person to think of doing unzip/deflate in JavaScript either.

It was my first experience writing JavaScript to handle binary files. It was fun. It took a weekend.

Some essential tools: Firebug, a hex editor, pen & paper, a clear mind, patience.

Now swinging my attention back to stuff I should be working on…

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?

SVG-edit: The Secret Sauce

Jeff — Fri, 22 Jan 2010 03:26:05 +0000

[clipart]SVG-edit has far exceeded my expectations in the seven months since I’ve been working on it. The people I’ve met there have been amazing and it’s been really fun to watch the project grow both in members and in capabilities. Without the people working on it, people like Alexis (now the top contributor) and wormsxulla (whip-cracker on UI translations) and others, there wouldn’t be a project – that much is obvious. But would you like to know the secret sauce in the SVG-edit project? Of course you would.

[clipart]One of the surprising factors in SVG-edit has been using GoogleCode in combination with Subversion. Let me tell you why:

Linked Information

Everything is an issue in SVG-edit. This is the way we keep track of things to do. This is the way other people discover things they can work on. This is the way we prioritize features for a release. This is the way we identify good first bugs for new hackers to work on. This is the way we sort problems into browser-specific, usability, interoperability categories. This is even where we put requirements and design decisions.

Making almost everything an issue is good because GoogleCode has some magic that detects revision commit messages and message comments and inter-links the two. For instance, if I fix issue 436, I might do:

$ svn ci -m "Fix Issue 436: Fixed the foo thing"

This shows up in GoogleCode here and provides you a link to the issue.

Now in the issue itself, I can mark it as Fixed and mention the revision that fixed the issue:

Fixed in r1275

Once again, GoogleCode provides a link to the revision when you look at the bug.

This kind of tracking takes a little bit of discipline, but it’s not that bad and the payoff is worth it. It really helps other developers keep tabs on what’s been solved where and how.

Host It

Since SVG-edit is a 100% client-side application (i.e. everything happens in the browser, no server component), and since Subversion allows you to specify MIME types by setting properties on files, we can convince GoogleCode to host the entire project in runnable form for the purposes of demo-ing the code.

This applies to the trunk as well as any branches and tags. For instance, you can actually see the evolution of SVG-edit over time:

Or you can look at the latest trunk build.

Or you can host the file in a web page by using <iframe> element like I’ve talked about before.

The fact that GoogleCode servers host the repo and also support web serving the content is immensely powerful: it means we don’t have to administer a source code repository and we don’t have to pay for a dedicated server or bandwidth costs to demo the software. Furthermore, because it’s a browser-based app, users don’t have to download anything, they can try out the code right on the spot.

Incidentally this is also one of the strengths of a web app in the first place: Zero downloads.

Tracking Down A Regression

GoogleCode’s hosting of the svn repo doesn’t stop at branches/tags. In fact, you can look at ANY revision in the browser directly. Coupled with the fact that we don’t really require a build step means that it is very easy to track down a regression.

git has this cool feature called bisect that allows you to hunt down when a regression occurred by seeking forward/backward across revisions in increasingly smaller increments, building each revision and testing until you find the first revision in a branch that exhibited a problem.

We can do this much easier in SVG-edit using Subversion on GoogleCode. Let’s say one day we notice a problem in the trunk and we’re at r1200. Well, we might decide to try out the editor at revision 1000 to see if the problem existed then. If the problem did not exist, we hop ahead 100 revisions to r1100 – was the problem present then? If so, hop back 50 revisions to r1050. Repeat in the browser until you isolate the earliest revision where the problem occurred, then add a comment to the issue and go review that revision.

Totally amazing capability and no more difficult than changing a revision number in the browser location bar. I have to credit Narendra Sisodya, the project founder, with uncovering that little nugget.

Not a Nirvana

There are still some grips/nits I have with GoogleCode+Subversion:

Being able to serve gzipped JavaScript would be great
Being able to display the current revision number in SVG-edit
The wiki markup needs significant improvements

But this is free hosting and project management software, so I can’t complain too loudly.

Just Ship It!

Jeff — Mon, 11 Jan 2010 20:31:29 +0000

[clipart]So Alexis and wormsxulla and all the translators and anyone who opened a bug against SVG-edit should really just be proud, because SVG-edit 2.4, codenamed Arbelos, is now released. Try out the DEMO now.

For those who have more time to kill, here are a couple screencasts I tried to make that demonstrate the new features:

And there’s lots more coming in SVG-edit 2.5 (codenamed Bicorn) that we’ll be talking about in the future.

To celebrate, here’s another comic I made using SVG-edit (view full size):

Houston, the SMIL has landed

Jeff — Thu, 15 Jan 2009 06:38:53 +0000

This day was five-and-a-half years in the making: the initial patch to add SMIL support has landed on Mozilla trunk. SMIL is the Open Web way of doing declarative animation, I use it on my site here and there via FakeSmile. This Mozilla patch is partial support for SMIL within SVG only (not HTML). Note that SMIL support is disabled in the build by default, as roc says “we should enable it when we’ve got enough implemented that we wouldn’t feel embarrassed about shipping it. ” – but this is a significant step forward.

Thanks and congratulations go to Daniel, Brian and Robert! Also thanks to Erik and Ian for putting some SMIL tests into Acid3. Not that this had anything to do with it. Oh, no.

Opera has supported SMIL in SVG for a couple years now. Anyone want to place bets on who will be the second to release a browser that supports it? Mozilla? Apple? Google? Microsoft? What, did I say something funny?

Parameterizing SVG and HTML

Jeff — Fri, 25 Jul 2008 17:11:20 +0000

Hallvord R.M. Steen (an Opera employee and member of the HTML WG) was kind enough to create a bug regarding an issue I had raised a few months back. It is currently not possible inside an embedded SVG to determine the parameters sent in from HTML:object if the two documents are on different domains. This appears to be a hole in the HTML4 spec, which doesn’t really address cross-domain security concerns for the HTML:object element.

At the moment, the issue is dead in the water. Ian Hickson suggested that query parameters could solve this issue. However, query parameters are part of the URI. In my experiments with PHP, I found that query parameters are a good way to ensure the browser actually re-fetches a document and doesn’t rely on the document in the cache. This means that using query parameters would defeat one of the purposes of parameterizing the SVG in the first place (one document in the browser cache that could be used for many purposes).

It’s sad because plugins like Flash have the luxury of being able to pass parameters into their content, but we can’t do that for content the browser understands natively (like SVG and HTML). I failed to convince the benevolent dictator that this is an important capability that the open web stack lacks.

I think this would be a nice way to turn bits of HTML/SVG into simple components without requiring script on the embedding side and without requiring heavier technologies like XBL and/or waiting for browser support of postMessage(). For example, it seems like web page authors using things like Adsense could benefit from this by not having to include foreign script in their pages, but apparently Google has no interest in this.

Eric Meyer’s link-anywhere proposal inspired me to at least float this issue in my blog in case someone else thinks it important. For now, I’m tired. Hm, I wonder if I can use the window.name hack…

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.

Fake Smile

Jeff — Mon, 17 Mar 2008 04:10:43 +0000

David Leunen has released a new JavaScript library to fake SMIL for modern browsers that do not yet support declarative animation (Firefox 3.0- and Safari 3.0-). The nice thing about this is that it uses existing standards, so that when Mozilla and WebKit finally implement SMIL, this script will avoid executing. On that day, suddenly animations will become less processor-intensive. I’m all about progressive enhancement, but I’m also not above occasionally faking it a little to experiment with cool features.

As with all experiments of late, you need a cool browser like Opera, Firefox or Safari to see this stuff. I’d be interested to hear if Konqueror 4.0 supports it. Internet Explorer will just not do, I’m afraid.

I currently use SMIL in my menu above, in the leering FakeSmile icon to the right ~~(which I’ve inlined to see what happens when it gets aggregated in feed readers like Planet Venus)~~, and now in my comment box when you focus and blur it.

Yes, this is just shiggles and not very productive – but I’m not alone in experimenting with some advanced web features on my blog.

Yes, SMIL intermixes “presentational”-type markup with “content” markup – but SMIL Timesheets looks to me like an attempt by the SYMM Working Group to address this. Maybe something in the future for FakeSmile to support?

And yes, it’s kinda fun. SMIL is the blink tag of the new millenium…

Oh, and in case you missed it above, I’ve started using SMIL in my blog’s comment textarea – that’s XHTML, not SVG. The FakeSmile library supports a limited subset of SMIL functionality in not just SVG content but on any attribute in a XML-based language (provided you properly namespace where required, like in XHTML):

That’s what makes XHTML so attractive to me – the X is for eXtensibility. While I still support the effort, the current HTML 5 activity is mostly focused on SVG (and to a lesser extent MathML) integration with text/html. I hope they do address more flexible extensibility within HTML5 at a later date. It would be great if someone had already done HTML+SMIL so there was some basis off which to work. Snarkiness aside, I will admit to not understanding the ins-and-outs of namespaces within HTML and all the problems it poses, but I’m trying to learn in my spare time…

One semi-amusing footnote: You won’t see the textarea expand when you focus it in Opera. This is because Opera supports SMIL-in-SVG already, so the FakeSmile script is not executed (short-circuited). It would be great if Opera went ahead with XHTML+SMIL support. I’m not sure why that hasn’t happened yet…

[Update: David has fixed his library to allow Opera to use the library for XHTML+SMIL as well as interpolate between properties with units (i.e. 2em).]

Let the Web Hacker Wars Begin

Jeff — Tue, 19 Dec 2006 07:01:39 +0000

The Next Big Thing from Laszlo, OpenLaszlo 4 (OL4) codenamed “Legals”, is nearing completion and we should see a first Beta in January. This is the release of OpenLaszlo that will be able to compile to more than one runtime, allowing web developers to target either Flash or DHTML. In future versions of OL we might see more runtimes added to support Microsoft’s WPF/E and W3′s SVG and SMIL.

It will be interesting to see how web development will change in the coming year, as DHTML toolkits like Dojo, YUI, MochiKit, Google Web Toolkit, Microsoft Atlas continue to mature, Adobe’s Flex 2 continues making inroads and Microsoft’s WPF/E deployment gets underway in earnest. Meanwhile, the venerable Java Platform is still evolving, parts of it now open source and Jave SE 6 recently becoming available.

All of these are signs that seasoned web developers are finally ready to move up the tool-chain stack away from the simple text editor. I think key things to look for in differentiation between the various frameworks are:

Tool Support: What kind of developer tools are out there to support development in your framework/language(s) of choice? From what I understand, Adobe has always been good with developer tools. On the Java side, there’s NetBeans. On the DHTML side, there’s Eclipse’s wtp. Maybe it’s time I looked into IDEforLaszlo in the New Year. Do your tools allow you to quickly and easily test and debug your code?
Community Involvement: Not necessarily just an open source community, but a vibrant one with lots of energy and open participation. Of course, a transparent development process will help here.
Cross-Platform Support: You need to support all of the “high tier” browsers like Firefox, Opera and Safari and you need to support multiple operating systems equally. People are passionate about their browsers and operating systems. Projects need to be careful not to lose the next hot web developer to a more compatible framework.
Ease of Deployment: How easy is it to change one line of code and deploy that change? That was always one of the beauties of the early days of the web – simply update your HTML file and save it on the server
Beware Of Vendor Lock-In: This is going to sound very anti-corporate, but the truth is that when one company controls the toolkits and the standards, there is always the potential for that project to be shelved or neglected or dropped in favour of new ventures. This ends up taking its toll on the web developer. With open standards and open source toolkits, developers can shield themselves from the whims of corporations.

Needless to say, competition will engender a very exciting year, with the winners being the web community as projects vie for the hearts of hackers everywhere, sparking further innovation. I hereby dub 2007 as the year of the “Web Hacker Wars” – let the battle begin!