Return to Candy by James homepage

CSS3 @font-face browser support table 2012

It’s time to update the CSS3 @font-face browser sup­port table. It doc­u­ments spe­cific­ally how browsers act when either the whole font fam­ily is spe­cified (reg­u­lar, italic, bold, bold-italic & small-caps) or only the reg­u­lar ver­sion of the font is spe­cified. The test-case that this based on uses the ideal, easi­est (lazi­est) imple­ment­a­tion and can be found on its own page here.

This is a robust­ness test. What hap­pens if some font vari­ants don’t load? What if there’s only one vari­ant to begin with? Will inform­a­tion be lost? Those ques­tions can be answered with this test.

Here’s the res­ults of how browsers in 2012 render the test case, com­pared to the ref­er­ence ren­der­ing. Mobile browsers have been added too.

Can the browser pick up the style natively?

Firefox 14 Safari 5 Chrome 19 Opera 12 IE 10 cp
Normal (reg­u­lar) Yes Yes Yes Yes Yes
Italic Yes Yes Yes Yes Emulates
Bold Yes Yes Yes Yes Emulates
Bold-Italic Yes Yes Yes Yes Emulates
Small-Caps (reg­u­lar) Emulates Emulates Emulates Emulates Emulates
Small-Caps Italic Emulates Fallback to reg­u­lar Small-Caps Emulates Emulates [3] Emulates
Small-Caps Bold Emulates Fallback to reg­u­lar Small-Caps Emulates Emulates [3] Emulates
Small-Caps Bold-Italic Emulates Fallback to reg­u­lar Small-Caps Emulates Emulates [3] Emulates
Extras? Ligatures![1] - - Ligatures![1] Ligatures![1]

How are mobile browsers with nat­ive variants?

iOS 5.1.1 Opera Mobile 12 Google Nexus One (Android 2.1) Samsung Galaxy Tab (Android 2.2) HTC Evo 3D (Android 2.3)
Normal (reg­u­lar) Yes Yes Yes Yes Yes
Italic Yes Yes Yes Yes Yes
Bold Yes Yes Yes Yes Yes
Bold-Italic Yes Yes Yes Yes Yes
Small-Caps (reg­u­lar) Emulates Emulates Emulates Emulates Emulates
Small-Caps Italic Fallback to reg­u­lar Small-Caps Emulates Emulates Emulates Emulates
Small-Caps Bold Fallback to reg­u­lar Small-Caps Emulates Emulates Emulates Emulates
Small-Caps Bold-Italic Fallback to reg­u­lar Small-Caps Emulates Emulates Emulates Emulates

Conclusion: Many browsers (Chrome, Opera) have made tre­mend­ous pro­gress. Only Safari is still lack­ing in its imple­ment­a­tion, in the edge case where Small-Caps text has added emphasis. IE 10 goes the curi­ous route of emu­lat­ing all vari­ants and styles from the reg­u­lar version.

Can the browser emu­late from the reg­u­lar version?

Firefox 14 Safari 5 Chrome 19 Opera 12 IE 10 cp
Normal (Regular) (implied) (implied) (implied) (implied) (implied)
Italic Yes Fallback to regular-style Yes Yes Yes
Bold Yes Fallback to regular-style Yes Yes Yes
Bold-Italic Yes Fallback to regular-style Yes Yes Yes
Small-Caps (reg­u­lar) Yes Yes Yes Yes Yes
Small-Caps Italic Yes Fallback to reg­u­lar Small-Caps Yes Emulates [3] Yes
Small-Caps Bold Yes Fallback to reg­u­lar Small-Caps Yes Emulates [3] Yes
Small-Caps Bold-Italic Yes Fallback to reg­u­lar Small-Caps Yes Emulates [3] Yes
Extras? Ligatures![1+*] - - Ligatures![1+*] Ligatures![1+*]

Do mobile browsers emu­late properly?

iOS 5.1.1 Opera Mobile 12 Google Nexus One (Android 2.1) Samsung Galaxy Tab (Android 2.2) HTC Evo 3D (Android 2.3)
Normal (Regular) (implied) (implied) (implied) (implied) (implied)
Italic Fallback to regular-style Fallback to regular-style Yes Fallback to regular-style Fallback to reg­u­lar Small-Caps
Bold Fallback to regular-style Fallback to regular-style Yes Fallback to regular-style Fallback to reg­u­lar Small-Caps
Bold-Italic Fallback to regular-style Fallback to regular-style Yes Fallback to regular-style Fallback to reg­u­lar Small-Caps
Small-Caps (reg­u­lar) Yes Yes Yes Yes Yes
Small-Caps Italic Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps Yes Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps
Small-Caps Bold Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps Yes Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps
Small-Caps Bold-Italic Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps Yes Fallback to reg­u­lar Small-Caps Fallback to reg­u­lar Small-Caps

Conclusion: Safari and most mobile browsers still fall back to reg­u­lar style. This means web developers can not use web fonts for body text if they have only one (reg­u­lar) vari­ant nat­ively avail­able to them.

The most up to date sup­port table, with pretty col­ours, can always be found on its own page along­side the test case. It also has more notes on lig­at­ures and small-caps support.

Why is fall­ing back to reg­u­lar style so bad?

It makes sen­tences full of expres­sion look like sen­tences full of expres­sion. It removes part of the typo­graph­ical ele­ments of a text, which is ironic, given that @font-face is meant to embel­lish it typo­graph­ic­ally. At its core, fall­ing back to reg­u­lar style removes information.

So what does this mean we should do?

Browser developers:

  • Safari devs: please work on emu­lat­ing bold, italic, bold-italic, etc. when they’re not present. Browsers do this already when it comes to system-fonts, which means web developers expect this to work.
  • Also give some thought to pick­ing up “font-variant:small-caps;” in your @font-face code. It’s the only way to ensure proper fall-back. Emulating, (like Firefox & Opera you all now do!) is a step for­ward, but it’d be a pity to stop there.
  • If HTML 5 has taught us any­thing, it’s that browsers should be more bul­let­proof, not web designer’s code. Also: ask­ing web developers to spe­cify as little as pos­sible is a better.

Web design­ers:

CSS3 @font-face browser support table 2010

Update: Have a look at the browser sup­port table for 2012 here.

It’s time for a CSS3 @font-face browser sup­port table. One that doc­u­ments spe­cific­ally how browsers act when either the whole font fam­ily is spe­cified (reg­u­lar, italic, bold, bold-italic & small-caps) or only the reg­u­lar ver­sion of the font is spe­cified. The test-case that this based on uses the ideal, easi­est (lazi­est) imple­ment­a­tion and can be found on its own page here.

Here’s the res­ults of how cur­rent browsers render the test case, com­pared to the ref­er­ence rendering.

Can the browser pick up the style natively?

Firefox 3.6 Safari 4 Chrome 5 Opera 10.5a
Regular (Normal) Yes Yes Yes Yes
Italic Yes Yes Yes Yes
Bold Yes Yes Yes Yes
Bold-Italic Yes Yes Yes Yes
Small-Caps Emulates Fallback system-font Fallback system-font Emulates
Extras? Ligatures! - - Ligatures!

Can the browser emu­late from the reg­u­lar version?

Firefox 3.6 Safari 4 Chrome 5 Opera 10.5a
Regular (Normal) (implied) (implied) (implied) (implied)
Italic Yes Fallback to regular-style Fallback to regular-style Fallback to regular-style
Bold Yes Fallback to regular-style Fallback to regular-style Fallback to regular-style
Bold-Italic Yes Fallback to regular-style Fallback to regular-style Fallback to regular-style
Small-Caps Yes Fallback system-font Fallback system-font Yes
Extras? Ligatures! - - Ligatures!

The most up to date sup­port table, with pretty col­ours, can always be found on its own page along­side the test case. It also has more notes on lig­at­ures and small-caps support.

Why is fall­ing back to reg­u­lar style so bad?

It makes sen­tences full of expres­sion look like sen­tences full of expres­sion. Thus remov­ing part of the typo­graph­ical ele­ments of a text, whereas @font-face is meant to embel­lish it typographically.

So what does this mean we should do?

Browser developers:

  • Please work on emu­lat­ing bold, italic, bold-italic, etc. when they’re not present. Browsers already do this for system-fonts, which means web developers expect this to work. Falling back to the reg­u­lar style (i.e. font-style:normal) is hor­rible as you lose all styling.
  • Also give some thought to pick­ing up “font-variant:small-caps;” in your @font-face code. It’s the only way to ensure proper fall-back. Emulating, like Firefox & Opera do, is a step for­ward, but it’d be a pity to stop there.
  • If HTML 5 has taught us any­thing, it’s that browsers should be more bul­let­proof, not web designer’s code. Also: ask­ing web developers to spe­cify as little as pos­sible is better.

Web design­ers:

  • Using @font-face when you only have the reg­u­lar ver­sion of a font at your dis­posal is not a good idea. Especially for body text.
  • If you use small-caps text, chances are vis­it­ors will see the fall­back system-font. So make sure you spe­cify a system-font that matches your @font-face font nicely when rendered as small-caps. (The test-case uses an espe­cially jar­ring one on purpose.)
  • Use a (less lazy, less prac­tical) more bul­let­proof way of spe­cify­ing your @font-face fonts is recom­men­ded (alas) for now.

Vertically centring in css (without hacks and multi-line enabled)

Chris Coyier over at css-tricks.com had a great example of a css conun­drum: how to centre, both ver­tic­ally and hori­zont­ally, mul­tiple lines of text. He some good code (using table-cell) but his code for IE relied on some (script)expressions which can have the unfor­tu­nate habbit of slow­ing down a page.

[update: to get a bit more back­ground on abso­lute & rel­at­ive pos­i­tion­ing, and how to cen­ter hori­zont­ally, read:  On Horizontal CSS Centering using Absolute Positioning or how Relative Positioning can rock your css.]

The reg­u­lar way of ver­tic­ally cent­ring in css has been doc­u­mented by Dušan Janovský back in 2004. It needs an extra div for its IE solu­tion, but it doesn’t require any expres­sions, only reg­u­lar (fast!) css. Because a div-tag is semantic­ally empty (like the span-tag), it doesn’t add any wrong semantic mean­ing (like a table-tag would).

The .area div isn’t stricly neces­sary, but it was in the ori­ginal prob­lem posed in the css-tricks.com art­icle. I have how­ever edited out the super­flu­ous back­ground declar­a­tion, as it doesn’t have any­thing to do with positioning.

I’ve updated the example to use con­di­tional com­ments instead of hacks. The html (in your page) becomes:

<div class="area" id="two">
<div class="bubble">
<div>
<p>Doing this may not be as easy or obvious as we would hope.</p>
</div>
</div>
</div>

The css (in your stylesheet) becomes:

.area {width:300px; height:300px; position:relative; float:left; }
.bubble {position:absolute; left:93px; top:21px; width:135px; height:84px; display:table; }
.bubble div {display:table-cell; vertical-align:middle; text-align:center;}

The IE spe­cific css (in your html-page) becomes:

<!--[if lt IE 8]>
<style>
.bubble div {position:absolute; top:50%;}
.bubble div p {position:relative; top:-50%}
</style>
<![endif]–>

Have a look at the demo to see what you should end up with. Questions welcome!

CSS3 Fonts: The ideal implementation

This series of art­icles is about the chal­lenges that arise when using @font-face. Font licens­ing is one (that many oth­ers have writ­ten about) and the file-size of included font-files is another, but this art­icle is about browser imple­ment­a­tion eccent­ri­cit­ies. I’ll start off by show­ing the ideal @font-face imple­ment­a­tion in this art­icle, before mov­ing on to show­ing cur­rent browser defi­cien­cies and the imple­ment­a­tion I settled on for includ­ing a full font-family which works in the here and now.

update: For an over­view of cur­rent browser sup­port for CSS3’s @font-face see the browser sup­port tables.

Ideally, design­ers would spe­cify the font-file they wanted to use for reg­u­lar text, and then one for each vari­ation they had at their dis­posal (so, one for Bold, Italic, Bold Italic, Small Caps, Light, Ultra Condensed, etc.) – all using the same font-family name, so that all vari­ations would be picked up auto­mat­ic­ally for body text, and, if @font-face isn’t sup­por­ted by the browser,  all text will still dis­play in the proper font-variant.

To do that, your css would look some­thing like this:

/* A font by Jos Buivenga (exljbris) -> www.exljbris.nl */
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_R_45b.otf) format("opentype");
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_B_45b.otf) format("opentype");
font-weight: bold;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_I_45b.otf) format("opentype");
font-style: italic;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_BI_45b.otf) format("opentype");
font-style: italic;
font-weight: bold;
}
@font-face {font-family: "Fontin Sans";
src: url(fonts/Fontin_Sans_SC_45b.otf) format("opentype");
font-variant: small-caps;
}

This would ensure proper fall-back in browsers that don’t sup­port @font-face (or only part of it) and com­pat­ib­il­ity with cur­rent stylesheets, mak­ing @font-face imple­ment­a­tion for design­ers plug-&-play.

The ideal @font-face ren­der­ing (on the left) and fall-back ren­der­ing (on the right) would look a little like this (notice the fi-ligature!):

ideal-fallback

You’ll have guessed by now that browsers haven’t reached this ideal imple­ment­a­tion yet. You can find the test-case and CSS3 @font-face browser sup­port tables here.

Information in this series was acquired while work­ing on the design and css for the site of Standards.next and sub­sequent tests after­wards. The Fontface used in this example is Fontin Sans by Exljbris (Jos Buivenga).

Improve your WordPress: related posts for 404’s

Second in a series of art­icles about tinker­ing with improv­ing your WordPress install­a­tion, we return to cus­tom 404 error pages; adding a list of pos­sibly related posts when vis­it­ors have fol­lowed an out­dated link. Other 404 error page improve­ments can be found in the first art­icle of this series.

One of the most use­ful things on a 404 page is a dir­ect link to the page vis­it­ors were try­ing to get to. Now we can’t read minds, but we do know the URI (explained in the third para­graph of the pre­vi­ous art­icle) and that’s good enough. The fol­low­ing code is adap­ted from this archGFX art­icle. The method used to trans­form the URI into a search query is very simple. If you would like a more advanced please refer to “A bet­ter 404 — Redux” at Urban Mainframe, where Jonathan Hollin expounds on his (down­load­able!) 404 page code.

There are two parts to this “related posts” code. The first part makes it pos­sible to get from “/wrong/link.html” (the URI) to “wrong link” (the search query). Read the rest…

Improve your WordPress: the 404 error page

First in a series of art­icles about tinker­ing with improv­ing your word­press install­a­tion, today we tackle cus­tom 404 error pages; the page every­one dreads get­ting when they’ve fol­lowed an out­dated link.

Four-Oh-Fours are hot again! Just recently came a across the art­icle A Better 404. I remem­ber read­ing the A List Apart art­icle “A Perfect 404″ ages ago, but had never done any­thing about it. Time to improve.

First some quick vocab: the part after your .com (or .co.uk) is called the URI, so if www.google.com/analytics/provision/ is the address,  /analytics/provision/ would be the URI. The URI is the part that’s wrong when someone’s fol­lowed an out­dated link. This means we can use the URI to cre­ate a more help­ful 404 page. To cre­ate a 404 page for your WordPress theme just cre­ate a 404.php file in the dir­ect­ory of your theme (/wp-content/themes/default/ is the default). Read the rest…

Inserting pages into category archives in wordpress

Wouldn’t it be handy if you could have a little story at the top of your archive pages (or other tem­plates), explain­ing exactly what’s what? And wouldn’t it be handy if that little story was fully wysi­wyg edit­able? I thought so.

Sites in WordPress (WP) have “posts” which go into cat­egor­ies and “pages”, which are inde­pend­ent. My cun­ning plan was to name pages exactly the same as the cat­egor­ies I wanted them to describe, and then insert them into the archive page. It has been quite a search to get all the right code, even though the end res­ult looks quite simple!

The first thing you do, is cre­ate a cat­egory (”One & One”) and cre­ate a page (with the title “One & One”). Secondly, you open up your archive.php tem­plate file.

You should see some­thing like the fol­low­ing in it:

<?php if (have_posts()) : ?>

And also, fur­ther along:

<?php while (have_posts()) : the_post(); ?>

Read the rest…

Bye bye liquid layouts!

Yes, I am pre­dict­ing the death of liquid lay­out of web pages. Not all mind you, some web apps will still be liquid, but for the rest of the web: liquid is dead. This is a nat­ural next step after declar­ing elastic lay­outs dead, so no sur­prises here.

There are three main ways to define your lay­out in web design: fixed, elastic & liquid. Having writ­ten about the dif­fer­ences between them before, I’ll suf­fice with stat­ing that fixed lay­outs are defined in “px” (pixels) and liquid ones in “%” (percentages).

Using a fixed lay­out means your web page is the same width irre­spect­ive of the view­ers’ screen width, like so:

Fixed layout.

Using a liquid lay­out how­ever, means your web page scales along with the view­ers’ screen width, like so:

Liquid layout.

Liquid lay­outs used to have an edge over pixel lay­outs in the sense that they increased use of the screen real estate, thus provid­ing more room if the viewer increased their text-size. Line-lengths are hard to con­trol with liquid lay­outs, because of vary­ing screen-sizes obvi­ously, but also when the viewer increases (just) the text-size. Jason Kottke pos­ted a good warn­ing about line-lengths in liquid lay­outs a while back:

Attention liquid design­ers: take a gander at this por­tion of an ancient Egyptian parch­ment on papyrus from the Louvre. Even the ancient Egyptians knew not to make columns of text too wide.

Now, how­ever, most browsers have adop­ted full-page zoom­ing over text-size zoom­ing. Most provide both, but full-page zoom­ing is the new default. Full-page zoom­ing gives users with a wider screen (for example) the chance to increase the size of text and images, while still pre­serving the ratios of fixed lay­out pages, like so:

Fixed design with full zoom.

As you can see, full-page zoom­ing means fixed lay­outs also provide increased use of screen real estate, but only when needed. In addi­tion fixed lay­outs keep line-lengths rel­at­ively stable, and are easy to work with as they are based on pixels, just like images, videos and other objects you may have on your web page.

Px vs Em: Is it still relevant?

You used to have to choose. Choose between an easy, but inflex­ible, px-based lay­out or a hard to con­trol, but flex­ible, em-based layout.

Now with full-page zoom being imple­men­ted (as default!) in Internet Explorer 7, Firefox 3 and Opera 9*, it’s a dif­fer­ent story. Full-page zoom­ing means your easy px-based lay­out will be fully flex­ible. Even more flex­ible than most em-based lay­outs in fact, as images will scale along too.

So I’m ask­ing myself, why bother with hard-to-keep-from-breaking em-based layouts?

[update] I don’t think liquid lay­outs are rel­ev­ant any­more either.

[update 2] * And now Safari too! That’s all of the major browsers.

PS. This still leaves percentage-based lay­outs of course, but they max­im­ise screen real estate. Which is very dif­fer­ent from max­im­ising read­ab­il­ity (line-lengths and all that jazz). As far as I can see, %-based lay­outs are good for some web-apps (like gmail) but aren’t optimal for other uses.

No business benefits for microformats

Over the past year there’s been a lot of atten­tion (in cer­tain circles) for “micro­formats”. Essentially, micro­formats are stand­ard­isa­tions of class-values to use in html. The implied bene­fit is that any 3rd party (be it a browser or another site) could eas­ily gain access to that inform­a­tion and be able to do some­thing use­ful with it.

However, aside from a few prac­tical issues, micro­formats are a fun­da­ment­ally flawed idea.

Microformats are an attempt at cli­ent side innov­a­tion. Looking at the his­tory of (x)html, javas­cript and css (the three main cli­ent side tech­no­lo­gies), you can see it’s rife with incom­pat­ib­il­it­ies. The stand­ard­ised ver­sions of said tech­no­lo­gies have also had (and con­tinue to have) very long mar­ket pen­et­ra­tion times (the time it takes for the sup­port of a tech­no­logy to spread among end users).

The funny thing is that these prob­lems can be mit­ig­ated by some­thing very simple; server side innov­a­tion! It’d have a couple of huge advant­ages. First-off, it’d give more con­trol over the user exper­i­ence. Since micro­formats don’t define how they should be handled by User Agents (UA’s, like browsers or mail cli­ents), you have no way of know­ing how your code will exactly be inter­preted by them.

Secondly, it allows you to use more com­pat­ible tech­no­logy on the cli­ent side (html, css, vCards, pdf, you name it). This means it would work, right now, for every­one. Also, espe­cially for sites that use a CMS (sys­tem to man­age a sites’ con­tent), server side solu­tions are a lot easier to implement.

A few examples of micro­formats, and an explan­a­tion why they don’t provide any (busi­ness) benefits:

hCard — Have extra mark-up so you can point to an external site which pro­duces a vCard? Mark-up which might force you to deal with UA’s which may mess up the res­ult­ing vCard because they inter­pret hCards dif­fer­ently? Why not just upload a vCard or have your CMS gen­er­ate a vCard automatically?

hAtom — Making the page itself it’s own feed? So the full, heavy, page can be pinged by feed read­ers all the time, using far more band­width and mess­ing up stats? Are you kid­ding me?

So yes, I do think that micro­formats are not worth imple­ment­ing yourself.

Why I use HTML (instead of xHTML)

Sean of Elementary Group Standards asked me, as part of a CSS Spring Reboot 2006 ques­tion­naire, why I used HTML 4. Was using HTML instead of xHTML a con­cious choice on my part? Absolutely.

While the other people who were ques­tioned man­aged to keep it nice and con­cise, I man­aged to write up a whole bucket load of words about it. As oth­ers asked me why I made sure Bite Size Standards is HTML 4, I’ve decided to post my answer here too.

As pub­lished on Elementary Group Standards:

“I’ve used xHTML for 5 years, from 2001 til 2006. My ori­ginal reason for using it was that it is sup­posed to be the future. It would have bene­fits like in-line SVG and MathML. It was presen­ted as TheThingToUse™ with CSS.

There are two things about xHTML which make it a poor choice for (pub­lic) sites. Both of them have to do with xHTML’s mime-types. In short, xHTML can be sent with text/html or application/xhtml+xml as the mime-type. On the web xHTML is usu­ally sent as text/html, as Internet Explorer (which has 83+% mar­ket share) doesn’t sup­port the other mime-type. Both mime-types are valid for xHTML 1.0, but (sup­port­ing) browsers do handle them differently.

It’s the hand­ling of the same code dif­fer­ently where xHTML’s prob­lem lies. When xHTML 1.0 is sent as text/html, it is handled as HTML. This means that it has zero user bene­fits over HTML 4.01.

When sent as application/xhtml+xml, you could use MathML — but — the browsers will also apply dra­conian error hand­ling. This way users vis­it­ing the site will be pun­ished (by not being able to see the site) for mis­takes by the cre­ator (which could be the developer, the CMS, the per­son updat­ing the text or indeed the user her/himself just writ­ing some­thing). Simple things like a mis­placed “&” on a page (instead of “&amp;”) will com­pletely shut off a page from its users.

So not only are there no bene­fits over HTML 4.01 because you have to send Internet Explorer text/html — you do get user-punishing error hand­ling from other browsers if you decide to send to them the application/xhtml+xml mimetype.

No bene­fits but increased head­aches? Mwa, count me out.

Some people might say ‘but xHTML is the future!’ This may well be, but is of little con­sequence. The future ver­sions of xHTML (1.1 and 2.0) are not back­wards com­pat­ible with xHTML 1.0, so writ­ing xHTML now gains you little in the future. Furthermore HTML 5 is com­ing. Who says that can’t be the future?

My recom­mend­a­tions for writ­ing HTML? Use the doc­type ‘HTML 4.01 Strict’ and write your code as xHTML com­pat­ible as pos­sible. This means self-closing tags in the body, but not in the head.*

*Little known fact: It’s actu­ally in the spec that you’re not allowed to self-close the meta or link tags. Quite silly in prac­tical terms, and I would sug­gest to the HTML 5 people that they change that[1. And lo and behold they did! In HTML 5 it’s com­pletely up to you whether you self-close tags or not.].

I hope this answers all the ques­tions people have, but if you have any more (or dare to ques­tion my argu­ments!) don’t hes­it­ate to use the com­ment form accom­pa­ny­ing this journal entry.

How to fix your WordPress 2.0.1 feeds

If, like me, you waited to update your WordPress install­a­tion until 2.0.1 came out, you might have noticed that your art­icle feed turned into a com­ment feed. Which, as we can see from the fol­low­ing pic­ture, is rather det­ri­mental to your vis­itor figures:

It’s worth not­ing this doesn’t hap­pen to every­one — just to people who have index.php in front of their permalinks. The fix for this prob­lem is included in 2.0.2, but it’s a bit silly to have to wait until it comes out. Luckily there’s an easy two-step solu­tion to the problem:

1) As per the instruc­tions at Trac Bug Ticket 2379 :

Open the file ‘classes.php’ in your wp-includes/ folder. Find line num­ber 1321; it should look like this:

// Root
(blah blah)

// Comments
$comments_rewrite = $this->generate_rewrite_rules($this->root . $this->comments_base, true, true, true);
$comments_rewrite = apply_filters(‘comments_rewrite_rules’, $comments_rewrite);

That first line in the com­ments sec­tion (in bold) needs another ‘, false’ behind it. That means it should end up like so:

// Comments
$comments_rewrite = $this->generate_rewrite_rules($this->root . $this->comments_base, true, true, true, false);

2) Now go to your ‘Options’ panel in your WordPress admin centre. Click on the ‘permalinks’ tab. If you’ve chosen the 4th option, copy your cus­tom struc­ture to clip­board (ctrl+c). Select the 1st option. Click ‘update permalink struc­ture’. Now select your ori­ginal option again. If it the 4th, put your cus­tom struc­ture back in again. Click ‘update permalink struc­ture’ again. Or, because an image speaks a thou­sand words:

That’s all there is to it!

Update: WP 2.0.2 is out, and the fix is indeed included. Remember to use the spe­cial upgrade pro­ced­ure — it’s a quick delete/move & upload this time!

Elastic, Liquid, Pixel: Explained.

In ‘mod­ern’ web design (as in, the last five years versus the five years before) there are three main ways to define your design.

Also called ‘fixed’, the first and most used method uses pixel meas­ure­ments to define the width (& height) of ele­ments on a page. The most obvi­ous advant­age to this method — and the reason it’s the easi­est to get your head around — is that you get pixel per­fect res­ults with it. Photos and other fixed ele­ments on your page will always fit, another huge advant­age. That’s also its down­fall how­ever, as it doesn’t increase in size as text scales, mak­ing the defin­ing of a good line-length quite difficult.

Which brings us to the next, most recent, method dubbed ‘elastic’. The crux of this method revolves around using ‘em’ to define (mainly) widths instead of ‘px’. You’ve already guessed of course that ‘px’ stands of pixel — but how is ‘em’ exactly defined? Well, an ‘em’ is the width a nor­mal ‘m’ takes up on the screen. This method has the advant­age of scal­ing along with the text. That means your line-length will always be exactly as you defined it, but, if an included pic­ture were to take up more width than the cur­rent line-length, it’d stick out.

Liquid has been going in and out of fash­ion for a couple of years now. It uses per­cent­ages (defined with ‘%’ in one’s code of course) to define the width of ele­ments. I think it was cre­ated with the inten­tion of not squan­der­ing pre­cious screen real estate, and while it does max­im­ise the use of the screen, it has sev­eral flaws. Given that screen sizes can vary a great deal, a designer can never be cer­tain the line-length is any­where near cor­rect and whether or not pho­tos actu­ally fit (push­ing them­selves off the screen, or worse, push­ing the design off the screen!).

In my next art­icle (not neces­sar­ily the next post!) I’ll talk more about hand­ling the down­sides of the meth­ods and how a mix of them is often the most effect­ive (and laden with browser flow errors — yikes!).

Using tables may cause bodily harm

Go to site. Look at design. Not bad is it? Quite alright. Model’s quite alright too and doesn’t dis­tract from the products too much.

Bodily Harm

Now increase text size. (use ctrl + plus or ctrl + scroll wheel up) Ignoring the fact that most of the text remains at exactly the same size, look what it’s done to the model!

So beware: using tables may cause bod­ily harm.

CSS selectors explained properly

Looking for a good and simple explan­a­tion of the cur­rently usable (and a few more) CSS select­ors? Roger Johansson has taken the time to com­pile them all into a 3 part art­icle. I can thor­oughly recom­mend it to people want­ing a nice over­view of what tools are avail­able to them in Cascading Style Sheets or just want to know what the heck “.new + #import­ant > a:focus:first-letter” means. An oldie but a goody.

Roger Johansson’s art­icle over at 456 Bereastreet on CSS 2.1 Selectors (part 1)

Knowledge will bring enlightenment.

Rather than shun those who don’t seem like their “get­ting it,” take the time to re-educate them.
~ Brian Veloso over on Avalonstar.

I feel that spread­ing the know­ledge is more import­ant than spread­ing the mes­sage, as the ‘web stand­ards’ people have been doing these couple of years. This is because I feel that enlight­en­ment will fol­low know­ledge anyway.

It’s also a darned sight easier to get people ‘on board’ that way too.

On the slagging of buzzwords

Since the September that never ended (the point where the unwashed masses — us — got on the inter­net), the web has been rife with buzzwords. New buzzwords came and old buzzwords went, or worse, kept on linger­ing wait­ing to be revived (I’m look­ing at you Web 1.964beta). Amongst all this mad­ness some people, try­ing to put some sub­stance into the buzz, have tried to redefine them.

A recent example of this is Cameron Moll’s recent art­icle on A List Apart. I must note here that rede­fin­ing wasn’t really the point of the art­icle, but some (read: quite a lot of) people (mis)took it as such. In this art­icle Cameron talks about re-alignment versus redesign of web­sites, explain­ing that an incre­mental approach to design­ing an exist­ing site is quite a good thing. You can think of it as evol­u­tion versus revolu­tion; the former might seem slower, but it does bring a lot more refine­ment than the latter.

Good advice right? Well I’d say so, but cer­tain people got hung up on the use of re-align, say­ing it brought a new word with new buzz, thus cre­at­ing con­fu­sion. People, get over it. New ways of using words to express ones ideas bet­ter are being cre­ated all the time. It’s the way lan­guage works. Just say­ing that restyl­ing vs. redesign already means redesign vs. re-align is ridicu­lous. Redesign used to be a broad term, being used for little tweaks as well as full-blown new designs of an exist­ing site. However, as time passed, redesign became syn­onym­ous with the full-blown new design of an exist­ing site. The May 1st Reboot and CSS Reboot events have pretty much cemen­ted this into the col­lect­ive mind of the web (no I’m not going to say blogosphere..yuk!). Ironically, this slag­ging of re-align only increases it’s expos­ure as a buzzword so I really feel they’re shoot­ing them­selves in the foot. Others have dif­fer­ent reas­ons for call­ing it harm­ful.

That same Anne (who I had the pleas­ure of meet­ing at the last Happy Clog meet­ing) men­tioned in the a former post that xHTML has quite a num­ber of down­sides. As these include for­ward and back­wards com­pat­ib­il­ity, they’re quite hefty. The upsides how­ever seem to be zilch at present (except­ing, maybe, search engine optim­isa­tion). HTML, on the other hand, seems to be get­ting a proper spec, writ­ten with the web in mind. I myself have half a mind to change over to HTML 5 once the spec’s fin­ished. Note that this is simply a recon­sidered pos­i­tion and has noth­ing to do with inflam­mat­ory dead horses.

Moving on to the curi­ous post on SimpleBits about using ‘CSS patch’ instead of ‘CSS hack’ to get rid of the neg­at­ive con­nota­tion that’s asso­ci­ated with the term ‘hack’ (even though it has noble begin­nings, one can’t deny that due to server crack­ers being known hack­ers, hack has a neg­at­ive mean­ing now). Thus it’s handy to use another term when you’re explain­ing your hacks to Pointy Haired Bosses. This doesn’t mean that CSS hacks should be endorsed or encour­aged, in my eyes it’s still a last resort.

So do I dis­agree with everything in those twin-posts? Nah, Web 2.0 is just as mean­ing­less as three (or was it four?) years ago. After see­ing the OSCON key­note by Dick Hardt on Identity 2.0 I have some hope that server-side client-focussed (i.e. stuff requires noth­ing extra of the user but does make life easier for them) innov­a­tions like Identity 2.0 seems to be get as much atten­tion as the client-side stuff (like remote JavaScript).

That’s another thing. JavaScript has become cool, nay, accept­able again! After the night­mare that was DHTML, we’ve now got a foot­balling cleans­ing acronym for ‘cool JavaScript stuff’ called AJAX. (Thanks Adaptive Path!) Even though they saw it as ‘a new approach to web applic­a­tions’ it seems that everything con­nec­ted to JavaScript has the tend­ency to over hype bey­ond belief. Compared to DHTML (Dynamic HTML) AJAX does have one sav­ing grace. It provides a method of shov­ing more heavy lift­ing to the server-side where, in my mind, it belongs (cer­tainly if the mobile web ever takes off).

So are there any buzzwords worth slag­ging hard? Absolutely.

On Horizontal CSS Centering using Absolute Positioning or how Relative Positioning can rock your css.

In Joen’s daily work, he needs to centre a div hori­zont­ally. Usually this is easy. It gets a little trick­ier when using abso­lute posi­tioned elements.

[update: read how to do it ver­tic­ally in: ver­tic­ally cent­ring in css (without hacks and multi-line enabled).]

The method I use is to have a wrap­per div with the fol­low­ing css:

.wrapper {
position:relative;
margin:0 auto;
text-align:left;

width:whatever;
}

For good meas­ure, you’ll need to apply the IE fix:
body { text-align:center; }
And yes indeed, the “text-align:left” of the wrap­per makes sure the text aligns to the left again.

Now you’re free to abso­lutely pos­i­tion the con­tent using the wrap­per as ref­er­ence point. This is due to the fact that an ele­ment with position:relative applied to it forces every ele­ment inside it (the so called child ele­ment) to use the par­ent as ref­er­ence, not the view­port (the part of the browser in which a web page is dis­played). You could say it resets the ref­er­ence point of it’s chil­dren elements.

This means you can still use abso­lute pos­i­tion­ing while cent­ring the whole page, like so:

.content {
position: absolute;
left: whatever;
top: whatever;

width: whatever;
}

In this spe­cific case, he needed a div to be placed over some Flash con­tent. Good news: It works like a charm for pos­i­tion­ing some­thing over Flash!

So there you have it, cross browser cent­ring of abso­lute & rel­at­ive posi­tioned divs work­ing in mod­ern browsers such as Mozilla Firefox, Opera & Safari as well as the ye olde Internet Explorer. Hope this lil’ art­icle has been use­ful to you.

Shortstat Everywhere

Ever wanted to include lots of files in your stats but the CMS doesn’t play nice with PHP in your tem­plates? Do you cry with agony when you think of the pro­spect of adding the same line over and over and over again to your static site?

Well, I didn’t do the lat­ter, but the former did bug me, so I found a way around it: Including the shortstat line by util­ising Apache’s .htac­cess possibilities.

Read the rest…

James John Malcolm MMXIV