Tech info about the site
As you may have noticed, there are a number of subtle changes to this website. Of course, to make these changes, I had to re-write all the code… but I think it was worth it. I picked up a lot of CSS and JavaScript knowledge.
Testing
First of all, I’d really like to thank Nic for letting me access a Windoze box remotely for testing. There’s no way I could have done this development without access to IE 6 and Firefox.
Text Elements
One neat trick I did was to make up a few CSS files to allow switching between different font families and text sizes. For this site, I preferred Verdana for the main text, and Arial for the headers. Originally, I was using Lucidia Grande, but Windows renders it horribly. Speaking of which, I can’t believe just how crappy Windows font rendering is compared to the Mac’s. Text on the Mac is sooo smooth and pleasant to read, whereas Windows font rendering looks like a throwback to the ColecoVision gaming console of the ‘80s. Ugh. If you needed just one more reason to ditch windows, this is it.
Graphic Elements
I ended up wasting quite a number of hours trying to get the gradient effect to look balanced top and bottom. Originally, I had simply sized the elements to the final size, then added a reflected gradient fill, with a percent or two location for the transparency. I could never force it to look good – it always seemed to have an extra pixel or two on the top, and that made it look, well, crappy. Then I had a revelation: gradients are using floating point numbers for calculating the fill, and if all it has to work on is small dimensions, of course it’s going to be all jaggy and off. Next, I tried making the graphic elements around 10x the size, doing the fill, flattening the image, and resizing… and it worked! I just feel a little silly now for not clueing into this behaviour earlier. Another Photoshop notch in the ol’ belt.
Browser Wars
I cannot relate just how much I hate Internet Explorer 6. It’s soooo slow and buggy. The only reason it’s used so much is that it’s built-in to Windows. If it wasn’t for that, say, if those poor Windows users had a choice between IE and some other browser, I doubt IE would ever be used anymore. It’s like what happened with the Mac: once Safari was bundled with the OS, everyone droped Mac IE almost on the spot. It’s that slow and crappy.
And believe me – I spent more time sorting out how to “trick” IE into behaving to CSS standards that I could have redone my site design at least three times over. Safari and Firefox are so pleasant to write code for – they (mostly) behave according to CSS specifications. It’s a dream to read a spec, code it up, and it works as it should. No “huh?” moments, where you aren’t sure whether you understood the spec or if the browser is just broken. Good news is that it turns out that it’s typically IE’s fault. But… since a good third or more of the visitors to my site use IE, I can’t ignore the problem, and have to work out a solution to it. That sucks… IE be a black hole of millions of man-hours of wasted effort since it was introduced…
That rant aside, the most common problems I ran into were:
- Safari has text padding bug for the first line of text in a page (to the best I’ve been able to determine). In order to get the header of the site lined up properly, I ended up having to write a little Safari-specific JavaScript to find the second line, and reduce it’s padding by 10px.
- Safari requires that the DOCTYPE be set to Transitional for the drop shadows to work. Strict triggers a left/bottom padding bug.
- IE 6 can’t keep 3 <p> tags lined up, where the first is a left float and the third is a right float. I couldn’t figure out a way around this.
- IE (Mac and Win) just throws a hissy-fit if you try to create a dynamic table in JavaScript by using the DOM interface. By kludging up an “innerHTML” table, it does work. However, this isn’t the most flexible way, as it’s very sensitive to the source HTML (it’s using string searches and substitutions, which are easy to break).
- IE 6 has some bizarre sensitivities to whitespace in the HTML (again, with the drop shadows). This is annoying and difficult to track down… and quite wrong.
- IE 6 inexplicably can’t keep track of a pixel width. Again, for drop shadows, I needed to add a special hack to the IE code to subtract an extra pixel from the margin of the bottom left and bottom right corners. Otherwise, the shadow looked like somebody had taken a hole-punch to the corners. This was the longest lasting bug of them all…
- Firefox gets the alignment of the first cell of nested table wrong. This affected the drop shadows for the photo thumbnail pages (if you’re using Firefox, the shadows are a bit more primative – they are missing the extra left and right borders, and the four corners).
- And, I needed to (ugh) make a private copy of RapidWeaver’s Blog plugin so that I could change the DOCTYPE. Yuck. I hate doing that sort of thing. But… the good news is that I think RW will have a new Blog plugin that will do better styling for archive pages – that may sort out the problem (assuming that they will use the main index.html file… if not, it’s customization time again…)
Anyway, I’m making a more formal write-up of the drop shadows technique (including code snippets) that I’ll publish in the articles section. Stay tuned…
Leave a Reply