Web Design and Build

Experiments with @font-face Last updated:29 October 2010

I’ve previously been a fan of Cufon for rendering web fonts, but this morning I thought I’d have a play around with @font-face. I tried it, of course, in Firefox first, and it worked. Hurrah. But IE uses its own proprietary font format .eot, created, or so I thought, by Microsoft’s own product WEFT. I’d heard the WEFT tool was unpleasant to use, but this still hadn’t prepared me for the grim reality….

However, via this excellent article I found Font Squirrel which does all the work for you.

Internet Explorer continues to be a pain, however, and applying the necessary css for IE needs some novel css construction – see the article for details. Having overcome this…

…you should see this text in a NASA-like font…

…unless you’re viewing in Opera 9, which doesn’t support @font-face. Otherwise, nice.

EDIT THE NEXT MORNING: After further experimentation I’m slightly put off by the “flash of unstyled text” which is noticeable in Firefox at least. There are some javascript hacks to try and address this, but if I’ve got to use javascript I think I’ll stick to Cufon for now.

Problems with From and BCC headers in PHP mail() Last updated:29 October 2010

Had a funny one this week. My wife discovered that nobody on her mailing list had received any emails since we swapped hosting packages back in May. Before the swap things were fine in a Windows server, now clearly not fine on Linux. On further investigation, I spotted that the From: and Bcc: headers weren’t being split out properly, and hence we were getting the Bcc was included in the From: field like this:

From:mail@mydomain.com Bcc: mail1@test.com, mail2@test.com etc etc

This was my original code:

$headers  = 'MIME-Version: 1.0' . "\n";
$headers .= "Content-type: text/html; charset=utf-8" . "\n";
$headers .= "From: Sender <sender@mydomain.co.uk>"."\n ";
$headers .= "Bcc:".$bcc."\n";

mail($to, $subject, $message,$headers)

Same result replacing \n with \r\n. No joy even on Coding Forums, but after a lot of Googling I found the solution, which was to replace the newline characters with the PHP constant PHP_EOL:

$headers  = 'MIME-Version: 1.0' . PHP_EOL;
$headers .= 'Content-type: text/html; charset=utf-8' . PHP_EOL;
$headers .= "From: Sender <sender@mydomain.co.uk>".PHP_EOL;
$headers .= "Bcc:".$bcc.PHP_EOL;

mail($to, $subject, $message,$headers)

Glad to say this did the trick. PHP version 5.2.13 if anyone’s interested.

Cross-browser consistency Last updated:29 October 2010

Once upon a time there was a business that wanted a very simple website. So I built one as a small project. It had a few pictures and some text. I looked at it in IE7 and it looked OK. It was a first step into the web world for the business. The client was happy.

A year passed. The website started looking a bit tired. It needed some more pictures. So I rebuilt it, added more pages and a lot more pictures. I looked at it in IE7. It looked OK. I looked at it in Firefox as well. It looked OK. It didn’t look quite the same as it did in IE7. I found that if I used tables in the design, some (but not all) of the differences between IE7 and Firefox 3 went away. (Don’t start shouting until you’ve read the rest of this page….) I decided I could live with the differences. I didn’t understand why Firefox was getting it wrong though. The new website went live about 2 months ago. The client was happy. So were his customers.

For other purposes, for another website, I’d been learning a bit about “Cascading Style Sheets” – css to the initiated.

I happened to show the website to someone I was working with. Having previously been quite proud of it, I was a bit embarrassed – the site navigation looked a bit naff. So I made the navigation look like buttons. It was quite easy to do this using the css I’d learnt. So I extracted all the style into a separate css file. The page looked quite a bit better with the buttons. The client was happy. It still didn’t look quite the same in IE7 as it did in Firefox 3. I decided I couldn’t live with this any longer. I spent hours trying to understand this. As a result of this I learnt a lot about css. Every time I looked at the html or css I spotted something that could be done better, so I changed it. This became a fascinating journey into the world of modern web applications, or as my wife called it, an obsession. Where I could get it to work, I got rid of the tables I’d used. I got rid of some of the differences between IE7 and Firefox. I started to realise it was IE7 that was doing the unexpected things, not Firefox. I started viewing what I built in Firefox first not IE7 first.

I made the mistake of posting a question on a discussion board. In line with all website discussion boards everywhere, I didn’t quite get the answer to the question I asked, but I did get some comments about how the website was built, using lots of absolute positioning. I rebuilt the website using some suggested code off the discussion board to use floats and margins instead. It still looked pretty much the same to the untrained eye…..(not someone comparing using a pixel ruler).

Getting curious, I had a look at the website in Chrome as well. It looked the same as in Firefox. Hurrah. Then I looked in Opera. Boo.  All the text was cut off on the right (EDIT: which I now realise was this problem, and nothing to do with margins at all). I took all the floats and margins back out. It looked OK in Opera then. I went to bed…..

In the morning I started again. I got rid of all the absolute positioning again. I did it in a slightly different way and it seemed a lot easier. I got rid of an extra line showing up in IE that was at the top of every page. The Home page looked identical in IE7, Firefox, Chrome and Opera. It was wrong in IE6 however. I fixed that. Now it looked the same in all of them. I centred the page and put a nice swirly background on. I looked through all the rest of the site. I noticed that the spacing around the horizontal lines was different in IE than all the rest. I fixed that as well. To do this I had to write a “hack” in the css so that IE would read one bit of css and everything else would read the rest.

Then I had a look at the page in IE5.5. Why? Because from the logs I could see one user using IE5.5. This turned out to be the client….. What a mess in IE5.5. Font sizes all too big. Like being shouted at. I found another hack that fixed this.

Finally, had a look at the site through Safari. And it looked…….fine! So, the site looked the same in all the likely browsers, and the unlikely ones as well. (I know, I haven’t tried IE8 yet.)

OK, here’s the moral of this story. The client likes the new swirly borders, although he won’t see them using IE5.5 and a screen resolution of 800 by 600. Otherwise the site looks pretty much the same as it did 2 months ago despite being completely rewritten. Nobody but me has looked at the site in Chrome or Opera. It’s probably still got some issues I haven’t understood yet. I know a LOT more about css and html. The web pages have still got some tables on them, which are debatably holding tabular data.

The client is still happy…

If you’re looking for some hints and tips on browser consistency then I’ve pulled together some more details on this page.

The lifespan of IE6 Last updated:29 October 2010

Read an interesting article this morning about the use of Internet Explorer. Specifically, the article suggests that now that IE8 is launched, users will migrate from IE7, but many who are still using IE6 will remain, to the point that IE6 will become more popular than IE7. Sound mad? Not really, because many corporate web applications were designed for IE6 when it was effectively the only browser available, and they won’t work with IE7. Larger companies tend to be intrinsically risk-averse anyway, upgrading a browser is low priority – my own experience certainly supports the argument.

A couple of sets of web stats highlight the issue. Looking at some stats from a large public sector website, 80% of visitors are using IE, of which 40% use IE6. This website will be frequently accessed by people at work. By contrast, one of the sites I run, which tends towards consumer usage, has only 60% IE users, of which only 15% use IE6

So the bad news is IE6 may live a lot longer than we might like…

Integrating WordPress into your website Last updated:29 October 2010

In the last couple of weeks I have incorporated WordPress blogs into two sites, applying the existing site style to the WordPress pages.  You’re looking at one of these right now…

I didn’t particularly want to replace all my existing pages with WordPress pages, I just wanted to use the WordPress functionality to power the blog element. Pretty common requirement I’d have thought. I found this article a useful starting point.

So, if you have an existing site with its own css file and you follow this tutorial exactly then you will end up with two similar css files, your original one and one just for WordPress files called style.css. So then you have to make changes in two places…I didn’t want this so additionally amended header.php to point at my “main” css file. The downside of this is that you can’t update your css file through the WordPress admin module, but that wasn’t at all an issue for me.

It’s pretty much guaranteed that this will break the display of at least some of the wordpress pages, as chances are you won’t have entries in your css file corresponding to the html markup that WordPress generates. The same things will happen of course, if you replace the contents of style.css with your own css.

For example, my main site uses #header and #footer as id names, just as WordPress does, so no changes required here, but I used #maintext instead of #content for the main page content. So you can either amend the html so the WordPress files use #maintext, or add #content to your css.

In this case, you can identify #content just by viewing the various .php files – but some classes and ids are directly generated “on the fly” and don’t appear.  I found the easiest way to do this was to view the actual pages using Firebug, and make additions to my css file accordingly.

This isn’t quite as painful as it sounds as WordPress is pretty consistent about the markup.

I’d guess it took a couple of hours in total to do, including actually amending the contents of sidebar.php. Worth it as all my styling sits in one file.