If you were around at the dawn of dynamic HTML you will probably have stumbled across amateur websites who thought it was really rather stylish to add a Javascript snow or bubble effect over the top of the page content.

Fortunately, those days are gone. By and large, it seems that amateur webmasters today know that just a nice colour scheme and a consistent, simple style trump a jumble of styles, javascript effects and stock animated GIFs that we all remember too well. Nice graphic design is done for you if you just install a blog and browse existing themes. Some may not even remember effects like this (Warning: Not safe for work or indeed any other time you require functioning eyeballs).

It's well-known that animations draw the user's attention in webpages. That doesn't mean we always want to avoid them: sometimes we want to direct the user's attention in one direction or another, particularly when the page is being updated dynamically with Javascript. This is not one of those special cases. Since the goal of this experiment is to build a fully-animated webpage, we will have to ignore that inconvenient little fact. However, this suggests we need to keep the animation as unintrusive as possible. Keeping it nice and slow may help, and it should certainly be in the background and not the foreground.

SVG is useful for this kind of effect because it has a feature (<svg:use>) for manipulating independent clones of a symbol. It is therefore simple to draw the original shape using an SVG editor, and the Javascript merely needs to manage instances of the clones.

Using Inkscape, I drew up a bubble looks like this:

There's a certain knack to drawing bubbles like this, of course. Air bubbles in water are colourless, but they are reflective due to total internal reflection. The amount of reflection increases as the angle of incidence increases, up to the critical angle, at which all light is reflected. At a water-air boundary the critical angle is 48.6° so actually the bubble should appear totally reflective from about 75% of the radius.

If this sends you into a bit of a panic as you struggle to remember your school physics lessons, don't worry. I'm not recommending a mathematically accurate implementation of Fresnel's Equations. With a lot of art (not just on computers), an appreciation of the physics can go a long way towards adding realism. But a 100% accurate simulation is not necessary for an effect to seem convincing – trial and error is much easier. The gradient as I've drawn it is not accurate but looks alright. Similarly, bubbles have two specular highlights corresponding to the water-air boundary and the air-water boundary.

As an aside, one day it may be possibly to depict fully reflective and refractive bubbles. Using SVG's incredible feDisplacementMap filter, you could distort the background using a pre-computed "lens" image. But that is unlikely to run at interactive speeds today, even if the filters required were fully and accurately supported, which they are not. The bubbles I've drawn are intended to be a compromise between rendering simplicity and attractiveness.

The bubble system (really just the SVG on its own) animates 20 clones of the bubble symbol. Again, this is based on some physical principles. The smaller bubbles are subject to less drag so have a higher terminal velocity, bubbles grow slightly as they rise and the pressure decreases and so on. One of the most effective things is that the bubbles drift with a random walk: they can randomly drift to one side or the other. They don't go straight up nor do they oscillate sinusoidally like the classic DynamicDrive script. For the most effective animation, bubbles would drift with the currents but this is simpler and reasonably effective.

I am quite pleased with the results. To really rid ourselves of the legacy of Javascript-animated GIF images, it would be important for this effect to tie in with the graphic design of the page, which I haven't shown.

I don't think this is realistically ready for production websites: Internet Explorer cannot display SVG, for one thing, and the intensive CPU requirement is also a problem. But I do think that sharp SVG graphics allow us to produce a wholly better standard of animation than what was possible before. With this, I think it's possible to make a bubble animation complement rather than detract from a web page.

Using images for buttons is a much more pragmatic approach than attempting to style buttons with CSS, at least until widespread support for CSS3's draft-but-stable border-image property is available.

Up until a couple of years ago, I had generally created buttons using a PHP script that glued them together:

This was a useful when working with XSL, allowing me to simply call a template to include an arbitrary button text, rather than linking to a static button image.

Because I now use Django for most of my sites, this technique is no longer relevant. Because I'm not now producing templates to transform an arbitrary XML model, but producing templates to render specific models, I know when writing the template what buttons it will require. A typical button, designed for editing convenience, would look like this:

This button is a rounded rectangle with a gradient. The label is typed twice to give it a slightly inset look. Even though you have to retype the label twice to change a button, it takes only a few seconds to change the label and adjust the width of the rectangle to fit.

Inkscape 0.46 provided access to a wide range of SVG filters, making the process even simpler. Buttons are now never more complicated than a rectangle, a label, and the SVG filters to make them look pretty and three-dimensional:

Changing a button is as simple as it can be. Or is it?

I sometimes like to connect adjacent buttons into one strip, something which will be familiar to Mac OS X users:

SVG filters can make this a doddle too. By using SVG filters to create all of the graphical effects, including the rounded corners, these buttons can be dragged together and automatically connect with one another. The filter is applied to the layer, and the above buttons are editable simply as rectangles.

Try it: Download the SVG (Inkscape 0.46+ recommended).

It's actually possible to create a similar effect using SVG filters:

The field is created using Gaussian-blurred circles. Where these soft edges overlap, the alpha channels are composited and this creates the necking effect which is key to blobby shapes like this.

The thresholding is done using a high-contrast filter on the alpha channel. The specular highlight was added just to emphasise the gooey, ketchup-y effect.

If you have a copy of Inkscape, it's fun to play with dragging the circles. Feel free to download the SVG.

What this entails is that it's possibly to take very simple vector shapes, bung on a filter, and get some very pretty artwork which can still be edited as paths.

Inkscape's 0.45 release saw the implementation of its first filter: Gaussian blur. On its own, Gaussian blur was an incredible useful filter, offering soft edges and powerful shading techniques. But with the collection of other filters provided, it also provides a building block for constructing some very complicated and useful graphical operations that could previously only be done with a raster tool like The Gimp.

Unfortunately, you will need a fairly deep knowledge of 2D image processing to make use of SVG filters. Fortunately I have one of these. Allow me to walk you through creating a filter in Inkscape 0.46.

I want to start with an example of a graphic I created way way back with Inkscape 0.38.

I created this graphic by drawing a blob, adding some text (in a font called "Balcony Angels") and then painstakingly drawing out the highlights (specular lighting) as partially-transparent white paths. It's also got a drop shadow.

Let's start again in Inkscape 0.46. I'm using the star tool with a bit of randomness to start me out with a blob. The wording is just normal text but I've tweaked the kerning a little this time. Also notice the gradient. Depending on how you wire up your filters you can preserve the colours and using a bit of gradient will always help to give a word-art logo like this a bit more richness.

To add lighting, you need a height map. The simplest way to create a height map is by applying a gaussian blur. SVG uses the alpha channel to represent the height map. Without a blur you can imagine that the height is 0% outside the shape and 100% inside – like a cliff or a plateau. With a blur you have a partially transparent edge, so it smoothly rises from the 0 to the 100%, like rolling hills. I usually apply the blur to the alpha channel as the colour channels aren't relevant.

You can only see a 3D shape appear when we wire up a lighting filter. Specular lighting is what we're shooting for. The output of specular lighting is just the highlights so make sure the document background is set to opaque black before you start experimenting.

Specular lighting is very sensitive to some of the settings you're using.

• Surface scale – here's where we say what the 100% height of the height map actually is. Generally you should stick to small positive numbers. Try 10. The gradient of the bumpy edges can be thought of as this number over the blur radius. If you've got 10px of blur, and a surface scale of 10, your bumpy edges should have a 1:1 gradient.
• Constant – this number combines two ideas: how bright the light source is, and how much light the object reflects. 0 means that the light is off, so that's not what you want. Numbers between 0 and 1 mean the object reflects a fraction of the light, or the light is dim. Numbers over 1 mean that the light is brighter. It's all relative, obviously.
• Exponent – this is the glossiness of the surface. The higher the exponent, the tighter the highlights. Metals have quite low exponents – say 10. 30ish gives a soft plastic. Higher gives the effect of ceramics and polished surfaces.
• Light Source – start with distant light, azimuth 225, elevation 25 and experiment from there. That will give you the kind of lighting from the top-left that mimics the user interface of most computers.

The outer halo, if you're wondering, is where the light catches off the bottom of the slope. We can clip that away at the same time as we apply it to the shape. To do this, we use an atop filter. The top input is the highlights, the bottom is the source graphic. Atop draws the highlights only over the source graphic. This is equivalent to (specular in source alpha) over source grahic.

We can also add the outline from the original. If we added it before the filtering, it would have also been shaded because the outline would be part of the alpha channel that we bumpmapped. We need a raster outline. We can do this using the morphology filter.

We dilate the source alpha channel and composite the original over the top. Voila:

And then there's a slight drop shadow. Gaussian blur the same morphology filter, add a couple of pixels of offset. Then composite the previous stage back on top of it.

If the shadow – or indeed the highlights are too bright, you can make them slightly transparent with a colour matrix filter. The fourth row of the colour matrix is the alpha channel, and the fourth column of that row is how much of the alpha channel to pass through. Change it to any number between 0 and 1 to make it partially transparent.

I've got one last trick up my sleeve, and it's the most complicated one.

I'm going to decrease the exponent on the specular filter a little to give me bigger highlights. Then I want to increase the contrast on the alpha channel. This can be done with a colour matrix filter. I set the last row to (0, 0, 0, 4.0, -1.5). This means that the alpha channel will be mapped a -> 4a – 1.5. This will to some extent remove the partial shades in the specular highlight and give me a more cartoon effect:

This is how the final filter is wired:

Enjoy!

I did have to install some nicer ttf fonts as there weren't any installed apart from Lucida in the JRE, but simply using aptitude to install an xfonts package worked.

It was a little slower than I had hoped, unfortunately, even for these very simple graphs, which means that working with this in web apps won't be quite as straightforward. It was much faster doing batches than individual graphs.

Anyway, server-side rasterisation is one obstacle to SVG adoption which happily proves relatively simple to overcome.

Program assets are a different beast to standalone artworks because you start to have to recombine artistic elements in new ways programmatically.

Most of the time, when web programming, you don't really need to generate completely original artwork on the fly, but you often need to composite some selection of pre-drawn assets. There are a variety of ways to do this, but Inkscape doesn't seem to make any of them very easy for me.

Composition of minimal PNGs

Export PNGs from Inkscape and composite them elsewhere, using external data or hard-coding to get them all to composite in the right place. This involves working out offsets, either by trial and error or trying to read them off the rulers in Inkscape. But, madly, the rulers and coordinates in Inkscape have the y-axis inverted.

You also have to build the document in Inkscape so that the various elements can be exported with the alpha channel – independently of shapes above and below the one you're trying to export. This means everything has to either be cloned off the page, or drawn on a seperate layer so that it can be independently hidden.

If you're actually attempting to composite PNGs client-side in IE, you need to use the PNG alpha hack, which isn't universally applicable.

Composition of padded PNGs

Export PNGs that are padded such that they can all be composited using one origin. This can be done in Inkscape, but it still isn't easy, because Inkscape only has the option to export the selection. The trick is to create completely transparent bounding rectangles and use these to store Inkscape's export settings. The resulting graphics are larger in filesize than they might otherwise be, and composition could also be slower.

This DHTML clock I wrote a while back mainly uses this method.

Export SVG

Export SVG and write a program to import, modify/compose and potentially rasterise. Rasterisation is still tricky. It will be really useful when browsers get more widespread support for SVG.

Still, this method requires painstaking care making sure that all the symbols are easy to recombine. It often means using a lot of svg:use elements (clones in Inkscape lingo), or, more easily, rewriting the xlink:href attribute to repoint the link to a different symbol. Doing it this way preserves the affine transform, but creating your own transforms (for a newly created clone, say) is still tricky.

The SVG Cities interface I mentioned recently uses this method.

Draw out all the permutations

Generate lots and lots of permutations using Inkscape, perhaps using a script to accelerate exporting them. This only works if the number of permutations is small, if it's possible to use only a subset of them, or if they can be generated en masse using Inkscape's excellent Tile Clones tool.

This is the approach I'm about to take with this DHTML dice widget I'm working on. First I've drawn out my base dice, then I've cloned one face onto the sides of one die.

Now I can align the 5 currently unused faces over the 5-side, then modify the links using Inkscape's XML editor:

Some of the problems I've come across in Inkscape when used for this kind of work include:

1. As mentioned, the y coordinates are all wrong so any coordinates you read off the UI have to be mapped y -> (document height – y)
2. Inkscape doesn't offer any way to make symbols more invariant. Ungrouping and regrouping works, but is time-consuming.
3. There isn't an easy way to manage which clones link where, or re-link clones on mass. In fact the only way to re-link clones is with the rather dire XML editor.
4. Inkscape doesn't let you group 1 primitive, even though this is both valid and useful.
5. Inkscape doesn't let you create offscreen symbols for use with clones.
6. Inkscape doesn't make it easy to set IDs for things.
7. All IDs generated by Inkscape are meaningless alphanumeric strings. Clones, for example, don't inherit any part of their parent symbol's ID.
8. Inkscape has a "label" as well as IDs. Label overrides ID in all of Inkscape's UI, even though they are also meaningless alphanumeric strings, useless in the programming, and they must be set independently of the ID.
]]> http://blog.mauveweb.co.uk/2006/09/25/construction-in-inkscape/feed/ 4 http://blog.mauveweb.co.uk/2006/09/18/svg-cities-with-greasemonkey/ http://blog.mauveweb.co.uk/2006/09/18/svg-cities-with-greasemonkey/#comments Mon, 18 Sep 2006 18:55:41 +0000 mauve http://blog.mauveweb.co.uk/?p=11 I've been experimenting with using Greasemonkey to rewrite the interface to a game I've been playing recently called Cities. I was trying this because I wanted to test how well a native SVG interface to a web application might work, and it was much easier to work with an existing web application – one that I use – than developing one as I go.

Here's a screenshot of the standard Cities viewport (with CSS styles by Bebe):



And this the current status of my viewport implementation:



Cities is a browser-based MMO. It's a slightly off-beat fantasy game with some humourous elements and not very many quests. Many of the rules are based on alignment, which is one of the four classical elements: earth, air, fire and water. It's alright, and quite fun when you get a couple of the alignment quests under your belt and the game starts to open up a bit, but the design isn't very polished and much of the world is fairly large, boring and featureless.

Anyway, it's quite well developed as a web application, and I play a little bit daily, so it's a good candidate for my experiments.I decided to use Greasemonkey after trying some of the Greasemonkey scripts other people have written to add the features they wanted to Cities. The approach I wanted to use was to replace the viewport with an SVG OBJECT on my server, and configure the OBJECT with Javascript by parsing the data out of the standard viewport's DOM tree. However, Firefox's Javascript sandbox prevented me from accessing the OBJECT's .contentDocument property because the SVG was loaded from a different domain. This is to prevent cross-site scripting vulnerabilities.

The first thing that occurred to me as a workaround would be to host the SVG on the Cities Wikimedia Wiki. Then by assigning a value to document.domain (this is allowed iff you're generalising from a subdomain, which the wiki is) you can permit the XSS.

But in fact I didn't try this because this would require me to update the version on the Wiki every time I wanted to test a page load. So in fact the approach I took was to load the entire SVG with a Greasemonkey AJAX request (has to be a GM AJAX – the vanilla kind also has XSS security) and import the SVG DOM into the HTML DOM. Firefox in fact renders this combination better than it renders an SVG OBJECT, because it can use the native dimensions of the SVG from the SVG documentElement rather than you having to respecify them as attributes of the OBJECT element.

For the parsing of the DOM tree, I would have liked to have used E4X, but it doesn't appear to work. This could just be a Greasemonkey limitation, because Greasemonkey uses XPCNativeWrapper for security reasons, or it might be that E4X doesn't interoperate well with DOM yet. It didn't occur to me at the time that I could have used XSLT, but there was quite a bit of processing involved in configuring the SVG DOM tree, so although this might help it would only be of real use in reading the state of the view from the source source DOM. This would be easier than writing DOM javascript to do it, but not as easy as E4X.

Reconfiguring the DOM was mainly rewriting and adding elements to link to symbols defined within the SVG file. No SVG paths were constructed in the Javascript, only a few elements.

I've got relatively far but the thing that has halted my progress is the problem of perspective on the viewport. I could make the view isometric, but I could have done that with a collection of absolutely-positioned transparent PNGs.

I could encode some 3D information in XML and use that to lay out the artwork in the tiles with perspective correction, but that is a lot of work for what is basically an experiment.

]]> http://blog.mauveweb.co.uk/2006/09/18/svg-cities-with-greasemonkey/feed/ 1 http://blog.mauveweb.co.uk/2006/09/18/svg-kubrick-source/ http://blog.mauveweb.co.uk/2006/09/18/svg-kubrick-source/#comments Mon, 18 Sep 2006 18:01:43 +0000 mauve http://blog.mauveweb.co.uk/?p=8 One of the first things I wanted to do with Oli's blog was start making minor alterations to the default Kubrick theme (which I really like, incidentally) in my favourite vector graphics editor, Inkscape. However, after searching the web for the source, I eventually found that the original source was a Photoshop file – one that the GIMP couldn't open.

Frankly, I don't think this is a very good show for an application which purports to be open-source. Anyway, as a result I pulled Wordpress's assets into Inkscape and reconstructed the graphics, as closely as I could, tracing the originals.

The result is an SVG file and a shell script to extract the assets. The assets should all be replaced together because the match isn't quite pixel perfect, but if you do replace them you shouldn't notice the difference.

]]> http://blog.mauveweb.co.uk/2006/09/18/svg-kubrick-source/feed/ 0