CodeDread Blog » SVG

SVG-edit: One Year Old

Jeff — Sat, 06 Feb 2010 16:49:41 +0000

[clipart]One year ago today, Narendra Sisodiya started a tiny project called SVG-edit, with the very first check-in. He was trying to build a white-boarding application that could be used to facilitate online education.

Wow.

My kids couldn’t even talk at the age of one! Slackers…

It’s pretty amazing to think that this:

Can turn into this:

over the course of just one year, built in a lot of people’s spare time – but here we are!

I can’t wait to see what SVG-edit looks like on its 2nd birthday!

SVG 2.0 Wishlist

Jeff — Fri, 29 Jan 2010 13:20:31 +0000

[clipart]Robin Berjon posted about what his SVG 2.0 Wishlist would be. I think he used the hatchet a little too much, so I thought I’d give some feedback. Since he doesn’t support comments (boo!) here we go.

Chopping defs

This was probably my biggest annoyance/concern since, to my knowledge, the <defs> elements causes zero problems. Why would <head> or <g style=”display:none”> be preferable to <defs>? The defs elements provides semantics to a SVG document. Specifically, it acts like Flash IDE’s “stage”, where graphical editors can store and find the re-usable elements in a drawing. I don’t see any benefit to getting rid of <defs> nor do I see a problem that it causes. Why are you using <section> elements when <div> will do just fine on your blog, Robin?

Chopping SMIL

I think chopping SMIL at this point would be a bad idea, considering that all native SVG browsers are just coming online with this stuff now. Yes, SMIL is vastly underused, but frankly SMIL has not had a chance to prove itself – both in user agents and in graphical editors. I’d say now that it’s been (being) finally implemented, give SMIL a chance and drop it in SVG 3.0 (or whatever comes next) if it is still too under-used.

Your alternatives to SMIL are CSS3 Animations for simple cases (sounds good) and JS+DOM for complex cases. I disagree with the latter as the only way to animate complex SVG. I think that SMIL still has good uses there. Out of curiosity Robin, what do you think of SMIL Timesheets?

What we do need to solve is the DOM interface for SMIL. I agree baseVal and animVal are truly hated. In general, I think declarative animations make sense for SMIL, but I don’t know about the mixture of SMIL + DOM – that never quite made sense to me.

Maybe move SVG+SMIL out into its own SVG 2.0 Module and see how it fares and provide SVG DOM Core 2.0 that’s leaner, meaner and leaves out the SMIL?

Attributes and CSS Properties

What’s the migration strategy? If the SVG 2.0-capable browser encounters an attribute that was present in SVG 1.1 and not present in 2.0 – what should it do? Ignore? <circle fill=”blue” /> becomes black?

Not all editors universally love inline style attributes (though the popular ones do). Inline style attributes are another layer of parsing, another micro-syntax for hand authors, and can actually bloat the markup – unless you have more than 3 presentational attributes

I think removing the CSS properties as attributes will actually end up confusing authors further (what? i can set the radius of the circle using XML but not the stroke-width?). I think the decision to make presentational attributes was a conscious one based on the fact that SVG is such a visual language.

I guess I don’t have a better solution for CSS properties as XML attributes, because I admit that it is confusing as it stands, but I’m not convinced that simply removing them is the answer.

Slicing – not Chopping

[clipart]I hope that SVG 2.0 does become leaner. I just think that now that browsers are seemingly rallied around 1.1 Full and people are actually starting to use SVG that we need take a more cautious approach with changes. To me, carefully and iteratively shaving is a better approach than swinging a hacksaw and see what you end up with. Sorry to mix up so many blades in my analogies.

Here are some things I wouldn’t be upset about if they went away:

<symbol> – hardly needed if <use>-referenced elements could have a viewBox, I don’t think they add considerable semantics like defs does
<tref> – sure, I’ve never used it
<view> – agree with your comments
<audio>, <video> – agreed that HTML5’s versions are the future
<switch> – never lived up to its potential, unfortunately (though I guess this leaves server-side or JS as solutions for localization?
<font> and related – I agree with your idea to move it out of the ‘core’ spec. Put it into a module and see what happens with WOFF, etc
<foreignObject> – I agree that this shouldn’t be necessary to mix HTML in SVG. If inline HTML can somehow show up directly inline with SVG then we could also do away with <textArea> and others
version and baseProfile – I think I agree with you on this one, they could be dropped. But if this is done, we need a good way of marking features non-conforming and obsolete going forward. HTML5 still has spec text for the <font> element.

My Wishlist

I liked your “Better HTML Inlining” idea. I think it has merit.

You seem to be extremely focused on paring down the language so that implementers can reduce their “SVG code footprint”. While this is definitely a concern for me as well, I think your proposals for removal do not pay enough attention to authors, tool-makers and existing content.

Personally, I think the major focus for SVG 2.0 should be on one thing:

Making the DOM Suck Less

This alone could seriously help reduce the SVG code footprint in the long run (though I still don’t understand how browsers could easily obsolete their SVG 1.1 DOM code yet). I hope to see the SVG WG hosting a DOM Summit as mentioned by shepazu. I look forward to reading/seeing concrete examples and spec proposals from attendees there.

Once the SVG DOM is improved and we have interoperable implementations of SVG well-deployed around the web, then I would think about seeing what else needs to be cut in the next-next version of SVG.

SVG Marketshare: Dec 2009

Jeff — Tue, 26 Jan 2010 13:25:53 +0000

[clipart]I decided to start publishing the percentage of web users who can view SVG/Canvas, starting with December 2009: 35.62%

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.

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.

MIX 10k Code Challenge += SVG

Jeff — Thu, 14 Jan 2010 15:56:59 +0000

[clipart]I came across the MIX 10k Coding Challenge on the weekend, and on a whim I decided to submit one of my old SVG demos to the contest. The 10k challenge’s tagline is “What could you create for the Web if you had only 10 kilobytes of code?”. The rules didn’t explicitly say I could use pure SVG, they mention SVG/Canvas in the context of HTML5 only, but I thought I’d give it a shot. It’s in the spirit of the contest, after all. At the very least it would encourage Microsoft to clarify the rules and at the very best it would be accepted and the rules updated to allow pure SVG applications. Looks like it was my lucky day.

I decided to go with my Solitaire demo because it was the most complete, didn’t infringe on any copyrights (looking at you Tetris), and most visually recognizable. It’s not the most innovative, but then again the point of this is not necessarily to win any prizes. It’s really about increasing awareness.

Unfortunately, the SVG (26kb) and JavaScript (16kb + 21kb) totaled 63kb. I did some cleanup of the SVG, minified the JS and then put the script inline with the SVG and then gzipped it. The result was a .svgz file that was 9kb. Perfect!

I then got an email from a friendly marketing/evangelism person at Microsoft who said that the engineers did not know how to open the svgz file to review the code to ensure it was under 10k. Woops! I explained to her that I thought it would be ok for the SVG to be gzipped, much as PNG/GIF files use compression and sent her the uncompressed SVG file for them to review. After all, SVG is just an image format, right?

Was I following the rules? Did Microsoft give me a fair shake? See for yourself. Who knows, maybe this is the first time a Microsoft admin had to figure out how to serve SVG on a Microsoft web server.

Out of curiosity, I later tried to see how far I was able to get down the Solitaire game: 5811 bytes. Not bad for a complete game that has scalable graphics. I’d be curios to see the equivalent SWF file.

I don’t expect you to vote for my entry, but what I do expect you to do is now go out and submit .SVGZ entries to the MIX 10k challenge. That one SVG entry is looking pretty lonely. If I can get Solitaire down to 5811 bytes, surely you can do better?

Thanks a lot to Amy, the evangelist/marketing person who really was quite patient with me.

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

Merry Christmas 2009!

Jeff — Fri, 25 Dec 2009 00:02:23 +0000

[clipart]Turned on the Christmas CSS and released SVG-edit 2.4 Beta. That should be enough

Happy Holidays to all the folks out there and talk to you next year!

Now We Have A Party

Jeff — Sun, 20 Sep 2009 19:59:22 +0000

With the announcement of Microsoft sponsoring the SVG Open 2009 conference – we now have almost every browser manufacturer participating in some way with the conference. That’s a pretty awesome achievement!

I think you should do your best to make it to this conference. It’s Oct 2-4 in Mountain View, California (at the Google Crittenden Campus). So just register already. You don’t have much time.

We’ve got keynotes by Brad Neuberg of Google talking about the SVG Web project, Erik Dahsltröm of Opera and Sam Ruby. We’ve got talks on Raphaël, AmpleSDK, and dojo.gfx.

There will be panel discussions with Implementors (Mozilla, WebKit, Opera, and many others) and the SVG Working Group. There are separate sessions on SVG in Opera, in Mozilla, in Android.

There are talks about SVG usage in important web projects like Wikipedia and OpenStreetMap as well as talks from tool makers such as Inkscape and OpenOffice.

If you have an extra day, consider attending the Workshops on the Monday to get some hands-on experience with toolkits (the afore-mentioned Raphaël and Dojo.gfx), tools (Inkscape) and animation (SMIL) among others.

And oh yeah, in case you missed it up top, I’ll say it again: Microsoft is sponsoring and will be attending! Microsoft has long been the sole hold-out among desktop browsers in supporting SVG. So while Opera, Mozilla and others have long been supporters of SVG – it’s Microsoft’s sponsorship and attendance that might be seen as an eyebrow-raising event. Let’s keep the speculation to a minimum, shall we?

Busy Busy Busy

Jeff — Thu, 30 Jul 2009 22:52:20 +0000

There’s something comforting about coming back to your blog after spending so much time on Twitter and the like. Twitter is great for learning about new things and sharing links quickly, but writing this entry in WordPress and not having to worry about a character limit feels… cozy. I thought I’d come back to the blog and try to give an update on what I’ve been doing lately.

Despite the silence on the blog, I’ve actually been really busy with all sorts of different projects. I think I’ve got my fingers in too many pies now. And all of them happen to be related to Scalable Vector Graphics. How did this happen?

SVG-edit

As mentioned earlier on my blog, in my spare time I’ve been hacking a little at SVG-edit and its child project jGraduate. It’s now at a point on the SVG-edit trunk where you can actually pick a gradient for your stroke/fill, which is a pretty cool thing to see.

Other than myself, the list of active contributors to the project has dried up lately. This is to be expected on open source projects. So I’m looking for fresh blood to come into the project and implement some of the features we have planned for the 2.3 release. The Align tool would be a good place to start.

Scour

I’ve also been continuing to plug at Scour development, releasing version 0.16 of the script yesterday. It’s starting to feel like diminishing returns lately on that front (i.e. a lot more number crunching and code going in and only marginal improvements to SVG file sizes). This is expected. I think the majority of features related to sane SVG reduction have been implemented. There are a couple big features I want to get to:

Removing duplicate gradients (Done in 0.17)
Removing redundant path segments after precision adjustment
Parsing CSS/style elements

After that I’m expecting scour to go into a mostly bug-fix mode. If you want to propose additional features, file bugs or write some unit tests, please feel free to contribute!

SVG Open 2009

Earlier this year I volunteered to help out with the SVG Open Conference. Through some nice serendipity, we were able to get Google to host the event at their campus in Mountain View, California. The theme is “SVG Coming of Age”. There are some really cool talks and workshops planned for this October and maybe a couple of surprises so I hope to see you there. I’ll be the tall guy pulling out what remains of his gray hair.

Planet SVG

One of the things I’ll be talking about at the SVG Open is the SVG community website that some of us have been poking at for what seems like forever. The site is ‘live’ but there are many ongoing improvements I want to make to the site. One of the recent updates was that a web-based version of Scour was added. It’s not pretty yet, but it is functional.

So what are you working on?

Oh The Things You’ll Learn

Jeff — Sat, 27 Jun 2009 14:35:25 +0000

I was playing around with a new project recently and wanted to figure out the complementary color of a given color. All you need for this are the RGB values of the color for which you want to find the complement.

There are lots of ways of specifying a color on the Open Web:

rgb(255,0,0)
rgb(100%,0,0)
#FF0000
#F00
“red”

And it’s not just the 17 CSS color names, there are 147 cool-sounding extended color names like papayawhip. So given that a user can input a color in all sorts of ways, what’s the right way to do this?

The Hard Way

You can build a parser that determines the color format, parses hex and rgb strings and has a table that maps 147 strings to rgb triplets. It turns out there are a lot of JavaScript libraries that already do this. Here’s one.

But then I thought: why am I including yet another JavaScript library to do this parsing when the browser must already know how to map from hex, rgb or color name to an RGB triplet (or equivalent) in order to render the color in the first place? Surely there’s a way to extract this directly out of the DOM?

The DOM Way

It turns out there is. It’s called the CSS DOM and I always seem to forget about this document. Piecing together information from the SVG DOM and the CSS DOM, this is how you would get the red value of a fill attribute on a circle:

var red = someCircle.getPresentationAttribute("fill").rgbColor.red.getFloatValue(1);

That’s just a bit perverse, but at least it’s possible.

In testing this I was delighted to discover that Opera and WebKit let me do it. Sadly, Firefox does not.

The Best-Laid Plans…

Here’s where the plot thickens. Seems like the CSS Working Group was chartered to produce a new version of the CSS DOM to make the interfaces less clunky. Seems like the CSS WG sent out a notice strongly warning browsers not to implement certain DOM interfaces in the CSS DOM. Seems like it’s six years later and there’s no new document.

Unfortunately this is where my sad little tale ends. Erik of Opera suggests that the SVGT 1.2 uDOM is really the right way to do this. It doesn’t matter that I agree with him because I don’t think Webkit or Mozilla have any interest in implementing this any time soon.

It seems kind of sad that folks have to write JavaScript libraries to do color parsing when the browsers already do this natively. It also seems really weird that the SVG DOM interfaces extend obsolete CSS DOM interfaces (SVGColor extends CSSValue which Bert Bos mentions in his email).

#DOMFAIL ?