Fuddland
As Phil noticed, I’ve added a bit of shading to the entry and comment bodies, to make them look a little less flat; however, as I said in my reply, this is only visible to newer, non-IE browsers due to the use of transparent PNGs.
I could have used transparent GIFs, but I dislike the fact you have to create different ones depending on the background colour of the region they’re in front of. To see how much nicer PNG transparency is, compare what happens when you make the browser window so small that the background image goes behind the title banner, firstly in IE 6 in Win XP and secondly in a browser that supports transparent PNGs [Opera, in this case].
In the first image, that jagged outline effect around the letters is because I tell IE Win to use a transparent GIF banner image in my CSS; the GIF was created using the colour of the background as its “matte” colour to anti-alias the edges of the letters. PNGs needs no such information, and hence work in front of any background, so browsers that support them are told to load that image instead.
Sending a GIF to IE Win and a PNG to all other browsers is achieved using the child selector hack:
/*IE Win */
h1#banner{
background: URL(image.gif)
}
/* Non-IE Win */
/* Use child selector > to make it invisible to IE Win */
HTML>body h1#banner{
background: url(image.png)
}
/* End hack */
Whilst I’m at it, here’s a quick summary of other things you might not see in the browser you’re currently using.
Dropdown menus
Internet Explorer
Sadly IE 6 users don’t get to use them at all. Sorry about that — perhaps the next incarnation will offer wider :hover support. Everything that is accessible from the dropdown menus is also linked-to on, or available via, the home page — no content is “hidden” from IE, it’s just harder to get to it directly.
Opera
Newer browsers such as Opera do support :hover, which means we can toggle display: none and display: block depending on where the mouse pointer is.
The arrows that indicate submenus are CSS content-generated; they are not part of the markup because they don’t make sense if the CSS is turned off.
content: "\21D3" gives ⇓
content: "\21D2" gives ⇒
I found a list of every HTML entity going; to use them in your CSS, read off the code from second column, but without the &#x or the semi-colon, and put a forward-slash [\] at the front. [It’s actually back-slash, but I always call it a forward-slash because when you write it, the pen moves forwards, i.e. in the direction of the text. To write a / you need go backwards along the page. Well, whatever you want to call it, use a \ in front of the entity code.]
[You need to use the Unicode code because Firebird and Mozilla will not parse content: "⇓" — although Opera does allow it.]
Mozilla, Firebird, and probably Netscape too [untested]
Those transparent menus that mrtn likes are visible in Mozilla and Firebird, which reminds me: they’ve changed the opacity levels! Compare a screengrab of exactly the same page in Firebird 0.7 [20031007] with one from Mozilla 1.6 [20040113].
See how the Mozilla [second image] transparency setting appears to be a lot higher than Firebird’s [first image], even though the level in the CSS is unaltered? Apparently this is a new “feature”:
“The opacity implementation was completely revamped to properly change the opacity of all descendants as a group.”
That’s all very well but it’s slightly buggered everyone who has used the old opacity levels. I downloaded the latest nightly build of Firebird and sure enough, the same thing has been done. Will everyone who has used transparency have to alter their levels to achieve the same effects they had before?
Safari
Safari supports its own version of transparency, via background-color: rgba(39,78,119,0.8); [the first three numbers control the colour, the last is the level of opacity]. Notice two Safari bugs here: firstly, it doesn’t support font-variant: small-caps [this has apparently been fixed as of version 1.2]. But what’s that square doing there instead of the ⇓? It copes fine with the ⇒ — after messing around with the charset attribute for a while, and then exchanging a few emails with bsag, I’ve decided it must be a bug. bsag kindly submitted it to Safari’s bug report database, so I’ll just have to see if it gets fixed in some future version.
Headers
In order to make up for the lack of small-caps and dodgy HTML-entity support, Safari is [I think] the only browser to allow the use of text-shadow, which I’ve added to the main headings. I wish other browsers supported it without the need for extra code and markup — it’s like an instant “professional touch” attribute [so long as you don’t apply it to all text!].
Buttons
Non-IE browsers allow styling of the different input types, in particular: form buttons. I added some borders, colour and shading to get them more in tune with the rest of the site. This is how they appear in Firebird — Opera ignores the small-caps styling on buttons for some reason.
Relative links
Lastly, some more CSS content generates the arrows on the archives’ relative links. I could have put these in the markup itself, because [unlike the dropdown menu arrows] “Up” is still up even if there’s no CSS, but it looked a bit strange having the arrows in the plain-view list of relative links, so I opted to keep them as CSS-generated.
