Life is too short for Internet Explorer in my opinion, and, since I use MathML on this site, it seems sensible to drop IE users by the wayside. (It is possible to get MathML working on IE, but since you have to install another piece of software to do this, MathPlayer, most people will just upgrade their browser instead.) Having done this, you realise that there are loads of very nice tecniques just around the corner, which will make life far easier for web developers. Some, like multiple backgrounds, get wide coverage. I present here a couple, some used on this site, which are less often seen:

1. Data URIs (references: RFC 2397)

   The idea with these is very simple: you link to a resource in your HTML or CSS, but inline the data right there so that there is no need for another HTTP request. In theory, you can do this for any resource, but IE8 has incomprehesibly limited it to just images.

   You should be able to embed other HTML documents within the current one, which would allow for very cool offline style effects:

   ..."/>]]>

   Unfortunately, unless the IE team does another volte-face, we will probably be left with using this for images only for some time.

   The basic syntax of the data URI is very simple: you just put data: as the scheme, then an optional mimetype (defaults to text/plain). You can then put in semicolon delimited options, like charset=utf-8. One option in particular is useful: you will want to have base64 set for binary data like images, otherwise you need to use % escaped data as in a URI normally. The start of the data is marked by a comma.

   A complete example would be something like the one given above, and these are supported in CSS too:

   This is an extremely fruitful use: my page here has all its thirty-odd images inlined in this way using some PHP tricks: I serve all the CSS with PHP, then inline the images and serve the whole thing gzipped (and then cache it, so it is only regenerated when the base CSS file is updated). The base64 encoding enlarges the images by about a third, but the gzipping more than compensates, so we actually reduce the total page size as well as getting rid of 93% of HTTP requests! The complete run-down of this technique could easily follow in another article if people are interested. Using some very basic browser sniffing, we can send the original file to IE.

2. Correct implementation of ::before (references: CSS3GENCON)

   There are several nice effects on the site which are only achievable by using the ::before and ::after elements. (These are actully pseudo-elements, which do not exist in the DOM directly, but look as if they are part of the object, so .note::before {content: "Note " counter(note) ": "} places “Note 1: ” before the note, inside the first note element.)

   You can see that this is very useful, because one of the perennial problems with semantic markup is the lack of enough hooks for styling. With ::before , we can also set content: url(mybackground.png);. The one fly in the ointment is that only Opera currently supports possibly the most useful feature here. We should be able to position these pseudo-elements absolutely, and use them to put the extra image wherever we want. Whenever Firefox, and others, jump on board, we should see this used to make some very nice effects soon.

3. innerHTML standardised (references: HTML5 Working Draft)

   At the moment, when we want to write out data to the DOM with Javascript, in an XML content (i.e. using XHTML) we are forced to resort to using the DOM functions in Javascript if we want to be standards compliant. This is very slow, since the code is all interpreted, and webapps often need the speed given by using the optimised methods in the browser (though Mozilla is working on JIT compiled Javascript, using Tamarin. However, there is an attribute innerHTML which we can use to set all the contents of any tag in one fell swoop:

   A link
   ";]]>

   This worries people, because it is far too reminiscant of document.write(), which could be used to insert improperly formed markup. However, done correctly, there are no issues. The haters of innerHTML usually forget one vital thing: There is no need to be afraid, because we do it all the time!

   In fact, every single XHTML document is rendered by parsing a serialised tree. The correct way to handle it to pass the string straight back to the browser, which will use the same parser to validate and insert the new nodes. This is in fact what browsers are starting to do, and it is in the spec. for HTML5. We can only hope, given the usefulness of this attribute, that the XHTML 2.0 group will be equally sensible.

   Now, using innerHTML is a little more involved, since we have to collect together all namespaces and namespace prefixes, and pass these down onto the new nodes, and there have been concerns about memory leaks if the nodes being dumped are not correctly disposed. These are not insurmountable, and a lot of designers look forward to using this when HTML5 support is wider.