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.

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.

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 “&”) 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¹.

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.

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!

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!).

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.

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.

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)