While we never got to the bottom of that issue (I couldn't reproduce it), it's worth backing up and examining font use on the web.

Fonts, unlike any other aspect of web browser rendering, depend on the platform, not the browser version.

The reason is simple: fonts are not bundled with the browser, but with the operating system, or installed with some creative applications.

If you select fonts based on how they look on your computer, they will look different on another computer with a different set of fonts installed. Also, fonts are matched by name in CSS, so when you write

font-family: "Helvetica", "Arial", sans-serif;

you are requesting a font named "Helvetica", then one named "Arial", then the default sans-serif fonts. This is a very common thing for people to write, because Helvetica is a popular choice on Mac, Arial is a popular choice on Windows, and sans-serif is a catch-all. The intention is to select a nice sans-serif font on each platform.

Unfortunately, "Helvetica" can exist on Windows and Linux as well as Mac. Helvetica has been around as a typeface since 1957, and there are different versions of it around – by what route, or with what degree of intellectual property infringement, I do not know. There are also a fair number of variants that your computer might also consider, if they are installed.

On Linux, Helvetica was historically an X bitmap font (ugly, impractical things that are now effectively dead). These days it is generally an fontconfig alias for a free sans-serif font, but renders with iffy hinting and kerning, perhaps to conform to the original font's metrics (ie. it has been shoehorned into exactly the same space, so that printed publications don't come out wrong). I actually find this font quite uncomfortable to read.

On Windows, you may occasionally find Helvetica exists, perhaps even as the same font, installed on its own, or with some software suite, but if you do you'll find several browsers on Windows render fonts with Microsoft's ClearType renderer optimised for legibility, not the Mac's quality-optimised renderer, also used in Safari 3 on Windows. Microsoft own fonts have been tweaked to work well with ClearType – others may not. Linux is (as ever) more flexible: it's possible to configure the amount of hinting to use through fontconfig, although most users will keep their distribution's defaults.

Ultimately it's an impenetrable picture – you cannot be sure that the fonts you list will give anything like the browsing experience you were expecting. The same overall picture applies with serif fonts and monospace fonts.

The best solution (unless you want to try downloadable fonts, which I wouldn't recommend for body fonts) is to side-step the specifics of fonts entirely and delegate to the user/browser/operating system. There are three suitable aliases for font families: sans-serif, serif, and monospace. These will reliably give you a good font of that category. There are two other aliases, cursive and fantasy which are too poorly defined – you could get practically anything.

Is this really the only option? If you're prepared to go to the enormous lengths required, can you not pick a list of named fonts, test broadly and claim it works? Well, yes, if you test broadly enough you can get say 99.9% coverage. Unfortunately, that's not always good enough.

The topic of a site turns out to significantly affect the statistics of users that visit it. For example, a site about Linux will get more Linux hits. A site about using Photoshop will get most hits from people with Adobe Creative Suites installed, and that comes with fonts. So as a theme designer, what was 99%+ for you could be 90% for some of the people who use your theme.

So, in summary, stick to the safe fonts: sans-serif, serif and monospace. Fonts that are ubiquitious and designed for the screen are also quite safe – Arial and Verdana. You might be able to find some other safe places by consulting statistics if you are feeling creatively hemmed in. But please, don't make font assumptions.

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.

On the web the situation is even more desperate. Bound by the available technology, and aiming towards intuitive and usable HCI, designers often draw on rounded rectangles to make functional layouts appear more friendly and personal. More than that, using rounded rectangles is perhaps the simplest way to design a site that isn't just boxy and dull.

In CSS, there are two well-known approaches. The fluid-width approach is to stick small graphics of rounded corners into each corner of a box – these cover up the box's corners and make it appear round. The fixed-width approach is to have top and bottom images that comprise the corners, and a tiling background to blend between the two. CSS3 offers an improved background model that will render these hacks unnecessary.

Of course, it's not necessary to stick to plain rectangles: using the above approaches, it's possible to decorate them with drop shadows, highlights, stripes, cutouts or whatever else you'd like to. These aren't just techniques for cutting corners – they generalise to techniques for decorating web-based boxes.

There are some caveats with nested rounded rectangles that you should watch out for. This is how nested boxes with rounded corners should appear.

The arcs for all the nested rounded boxes that share a corner should be arcs of concentric circles. In practice, this just means tweak the radii until they look right – so that they appear to focus on a point. Any square boxes should fall inside that focus.

Notice in the diagram below how square corners don't work unless they are inside the focus. Nesting rounded boxes inside square boxes is an absolute don't. A more common mistake is to use the same corner radius for an outer rounded rectangle as for a nested one. Most tools preserve the setting for corner radius, and that's not what you want. Notice how the outer box appears proud in the diagram below, right (cf. above, left)

Notice below how when the boxes don't share a corner, you can use the same corner radius, but the effect is slightly different. Using the above rule-of-thumb throughout will keep the design a little more down-to-earth.

Start with a high-quality vector graphics tool – I recommend Inkscape – and properly design the website. To represent where to put content use Lorem Ipsum or simply rectangles to represent individual paragraphs. Once you are satisfied with a design, recreate it in HTML, exporting any graphical elements you need from the mockup.

You can use this approach even for sites that don't need graphics; it is beneficial for choosing colours, fonts and layouts as well as for creating fully graphical sites.

Be careful though – you need to design a mockup that you can successfully convert to HTML. Graphics programs are WYSIWYG but the web is not and this places constraints on what you can successfully produce. Beware in particular of how the site changes as your browser window or text size changes.

It is common practice to test a web site in various web browsers, but this testing can give a false impression of the compatibility regarding different default settings. This is because almost all browsers have settled on a common out-of-the-box set of defaults. The user is allowed to override these defaults. Fail to anticipate this and your website risks visual problems for some users (perhaps 1% or so, to take a wild guess). Problems include:

• Character set issues, such as £ or the opposite, a broken character symbol (the question mark diamond in Firefox) rather than £.
• Specifying a font colour but not a background colour, causing clashes or even invisible text. Perhaps 10% of websites fail to specify a page background colour but assume that it will default to white.
• Linking images which are intended to composite onto white. This looks dreadful onto most other colours.
• Copy looking illegible due to tiny serif fonts (sans-serif is more legible on low-resolution screens).
• Body font clashing with image-based buttons and titles: serif and sans-serif fonts rarely mix.
• Pale-coloured boxouts. What appears pale is in fact a function of the background colour. A light pink box appears pale on a white background, but very bright on a black background, for which the corresponding effect would be a dark red box.

The browser defaults which you may want to change include

• Character set
• Background colour
• Text colour
• Font style
• Font size, although in theory you should avoid specifying this for accessibility reasons.

Misconfiguring a web browser is an art. It is perfectly acceptable to use the defaults a user specifies, as long as all of them are respected. While you should feel free to wholly b0rk a browser which you use purely for testing, it is more beneficial to misconfigure the web browser that you use for primary development. For me, this is the same web browser that I use for everything else, Firefox. Therefore the misconfiguration has to be something that isn't wholly unusable to me. More importantly, the new defaults have to be ones that I would be unlikely to use for a website, otherwise I could still rely on my defaults.

Because I tend to use sans-serif fonts, white backgrounds and black, grey or blue text, and UTF-8 character set, my browser is set to default to serif, coppery-orange text on a mid-grey background. I'm experimenting with ISO-8859-11 (Thai) as my default character set, because this isn't compatible with UTF-8 nor ISO-8859-15 for the most common problem area: £ and € symbols. It is compatible for ASCII-range symbols, so try UTF-16 if you are aiming for perfect incompatibility. I don't specify font-size but I Ctrl-roll my mousewheel on occasion to watch how the site changes at different font sizes.

So my default browser settings look like this. If I ever see these styles on a page, I know I've failed to specify something.

Calendars are so simple for me and – statistically – you that it's easy to forget that a server-generated calendar like this is actually not accessible at all. The issue here is linearisation: flattening out the days of the calendar to a script that can be read – aloud, in braille… or by a search engine. A calendar in this form linearises to a script that reads like this:

January. One. Two. Three. Four. Five. Six. Seven. Eight. Nine. Ten. Yawn. Zzz. Snore… February. One. Two…

And so on. It's not useful to read out 365 numbers (366 next year) and expect users to just wait to respond when the day of the year they are looking for comes up.

What is the accessible version? Well, the approach to take is to work out the linearisation we would like first. For example,

The following periods are currently available: the fifteenth of October to the twenty-ninth of November, then the eleventh of December to the seventeenth. Which date are you interested in?

Now, for a web page we might not expect to follow this pattern exactly, but the model is clear: list the calendar information, then query for a date. It looks something like this:

Periods Available

• 15th October – 29th November
• 11th – 17th December

What date are you interested in?

This is not bad even in a graphical user agent; describing calendars as schedules is not hard to visualise. Note that it would be perfectly possible to use Javascript to convert this calendar to a visual representation. Whether using Javascript in this way is accessible is open to debate. There is no reason screen readers can't execute Javascript. Some, I believe, already do. But there is a trend for graphical browsers to provide Javascript and for non-graphical browsers not to.

I'd suggest if you are willing to forgo an approach that caters ideally to non-visual users, it's possible to do better. We can cheat the system, almost, by using alt attributes in images and image maps to provide the schedule version as above, but for the images and maps to supply the visual layout. In my latest project, I'm also using line boxes full of images rather than a table. This allows a single <a> tag to span a whole month worth of dates. But what it saves on the semantics, it loses on file size. A cheaper approach might be client-side image maps, especially of the lesser-known form involving <a shape=""> tags rather than <area shape=""> elements, or similar features in SVG.

However, even with the approaches I've explored above, this is one area where I suspect there may not be a very solution that does equally well for visual and non-visual users. 365 dates worth of information is difficult to represent in a concise form. That's why we use calendars.

I had a strange bug with the Google Maps on the gallery which I found after a bit of searching was caused by Google Maps not supporting embedding within XHTML. But I'm pleased that the thumbnailing/unthumbnailing works so well. Previously the map enlarged and reduced; this is much less intrusive in either state.

I did have to disable all of K2's shiny Javascript features to make it work with my Javascript (for map markers) But they were a UI disaster anyway. One of the advantages to JS over Flash is that it allows us not to create horrific new UI paradigms. So going to great lengths to do so is missing the point.

The principle is this:

1. Register Javascript listeners which construct a list of events, particularly mouse, scroll and click events, along with the time that the event was fired.
2. Register an unload event which posts the information as XML with AJAX to a script on the server when the user leaves the page.
3. Browsing sessions can be collated on the server using cookies.
4. Create a player, which reads the events as XML and renders them using a DHTML 'cursor' and/or by firing events within the DOM. Could have a time slider and fast-forward controls, etc, depending on how complex you want to get.

Voila – see exactly what people are doing with your site. I have knocked up a test which implements the first two steps, for mousemove events, and that much works, so the whole concept would be workable. I can imagine it would break down if your site uses plugins (or Javascript navigation, depending on how easy it is to replay the events accurately) but that's a limitation you would have to live with.

There are obviously privacy concerns but this is relatively mild as no personal data would be recorded. Perhaps it could pop up a Javascript window.confirm() dialog asking if it's OK to record your behaviour. But it would be a very useful tool for examining site usage, especially for commercial sites. This is the way modern marketing works. I leave it up to your conscience as to whether it's ethical.

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