It’s time for a CSS3 @font-face browser support table. One that documents specifically how browsers act when either the whole font family is specified (regular, italic, bold, bold-italic & small-caps) or only the regular version of the font is specified. The test-case that this based on uses the ideal, easiest (laziest) implementation and can be found on its own page here.
Chris Coyier over at css-tricks.com had a great example of a css conundrum: how to centre, both vertically and horizontally, multiple lines of text. He some good code (using table-cell) but his code for IE relied on some (script)expressions which can have the unfortunate habbit of slowing down a page.
This series of articles is about the challenges that arise when using @font-face. Font licensing is one (that many others have written about) and the file-size of included font-files is another, but this article is about browser implementation eccentricities. I’ll start off by showing the ideal @font-face implementation in this article, before moving on to showing current browser deficiencies and the implementation I settled on for including a full font-family which works in the here and now.
Second in a series of articles about tinkering with improving your WordPress installation, we return to custom 404 error pages; adding a list of possibly related posts when visitors have followed an outdated link. Other 404 error page improvements can be found in the first article of this series.
First in a series of articles about tinkering with improving your wordpress installation, today we tackle custom 404 error pages; the page everyone dreads getting when they’ve followed an outdated link.
Wouldn’t it be handy if you could have a little story at the top of your archive pages (or other templates), explaining exactly what’s what? And wouldn’t it be handy if that little story was fully wysiwyg editable? I thought so.
You used to have to choose. Choose between an easy, but inflexible, px-based layout or a hard to control, but flexible, em-based layout.
Over the past year there’s been a lot of attention (in certain circles) for “microformats”. Essentially, microformats are standardisations of class-values to use in html. The implied benefit is that any 3rd party (be it a browser or another site) could easily gain access to that information and be able to do something useful with it.
Sean of Elementary Group Standards asked me, as part of a CSS Spring Reboot 2006 questionnaire, why I used HTML 4. Was using HTML instead of xHTML a concious choice on my part? Absolutely.
If, like me, you waited to update your WordPress installation until 2.0.1 came out, you might have noticed that your article feed turned into a comment feed. Which, as we can see from the following picture, is rather detrimental to your visitor figures: