This instructive post by Jonathan Snook on using the new(-ish) CSS3 rem unit for font sizing is nearly a year old. Since then, the browsers that support it (including IE9) have amassed enough collective market share to represent most users.

So can you use it now? Yes, although personally I wouldn’t use it for actual font sizing. A good use case is margins and padding, though — as you set the font size for different elements and classes, you often want to set the margins and/or padding as well, so you have to work out the right em value to use based on the font-size you’re setting. In this example, I want paragraphs and all headings to have the same margin-bottom as the body font size:

body	{ font-size: 75% }
p	{ margin-bottom: 2em }
h1	{ font-size: 2.5em; margin-bottom: .8em }
h2	{ font-size: 1.75em; margin-bottom: 1.14em }
h3	{ font-size: 1.25em; margin-bottom: 1.6em }

Using rem for the margins is much easier, looks neater, and needs less code:

body		{ font-size: 75% }
h1 		{ font-size: 2.5em }
h2 		{ font-size: 1.75em }
h3 		{ font-size: 1.25em }
p, h1, h2, h3	{ margin-bottom: 2rem }

And what about the 10-20% of users whose browsers don’t support rem? Well, the leading will be wrong in some places. If you can live with that, there’s no reason not to do it.

John Allsopp, responding beautifully to Aral Balkan’s well-written but (in my opinion) ill-conceived piece:

So, don’t ignore the latest and greatest. But don’t forget the other six billion.

He’s right. Developing for users of legacy browsers is difficult (especially when building complex interactive environments, as Aral correctly said) and is certainly no fun. All professions have something like this — part of the job that is dreaded but necessary. Working with legacy browsers is the dreaded necessity of web development.

As responsible practitioners, we have to do it. We have to make sure the things we build work for users who don’t have the latest browser, or JavaScript, or a mouse, or vision. It’s our job.

I picked this up six months late, but it’s every bit as relevant now as it was when it was written, and probably will be for ages.

Mark Perkins, following up on his tweet about how content management systems should leave the markup to you:

…a CMS should exist to provide a nice way to store structured data, map URLs to some kind of template/page and give you access to the data stored within it via some sort of templating language.

Yes. Companies who make CMS products should have that quote painted in metre-high letters on the walls of their offices. They shouldn’t even think about adding clever features until they get these things working really well.

Serious question: does anyone make a product that just does what Mark is describing? No admin interface, no templates, no themes, no widgets, just a good API and good documentation to back it up?

The White House has sent this response to me and everyone else who signed the anti-SOPA petition I mentioned recently. It’s one of those long statements that doesn’t actually say all that much. Except:

Any effort to combat online piracy must guard against the risk of online censorship of lawful activity and must not inhibit innovation by our dynamic businesses large and small.

So that must mean the administration won’t support SOPA? I don’t think so — if that was the case, they would have said “we won’t support SOPA”. There’s no commitment to anything here.

The public editor of The New York Times asking readers if, when public figures like politicians tell out-and-out lies, Times articles should call them on their bullshit. The response in the comments and on Twitter is best exemplified thus:

Following the NYT’s bold lead, I’ve decided to consider writing code that works on websites…The joke is that writing code that works on websites is my goddamned job. Are you even kidding me with this.

@wilto

Most newspapers in the UK have an agenda of some sort, and routinely publish news articles (not just columns) that are clearly biased — i.e. it’s pretty obvious to the reader that the writer has picked a side. It seems strange that in the US, which despite all the jokes is so similar to the UK in so many ways, newspapers have gone the other way, so desperate to avoid accusations of bias that they literally just “report” what happens and what’s said. That’s not what most people would call “journalism”.

A particularly good episode of Build & Analyze this week, including a little section about code comments during which I found myself nodding in agreement with Marco — well-written code generally won’t need commenting. Looking back at some code I’ve written this week, all of the comments are not stating what the code does, but why it does it.

Jeremy Keith outlining a technique thought up by Luke Wroblewski for dealing with some new HTML input types:

That was an angle I hadn’t thought of. Usually when I’m implementing new HTML5 input types (like input type="number") I put the new type in the markup and then try to come up with JavaScript polyfills for older non-supporting browsers. In this case though, the old-fashioned way is what goes in the markup and JavaScript does the enhancing for newer browsers.

It’s a great idea, particularly with date-based inputs which would be barely usable as standard text inputs, but I actually disagree with the cited example, which is using <input type="month" /> for the card expiry date field on an ecommerce payment page. I’ve been working on just such a thing recently, and come to a very different decision about how to get the input.

When you ask the user for the card expiry date, they’ll look at their card and see, for example, “05/15″. You’re then asking them to parse and translate that value so they can select it in your form as “May 2015″. Instead of making them think, I’d keep it to a standard text input, but with maxlength and placeholder attributes to help them get it right:

<input id="expiry" type="text" maxlength="5" placeholder="MM/YY" />

Better yet, I could also put a regular expression in a pattern attribute, which the browser (or some JavaScript) could use for client side validation.

Remember the iOS scale bug? That hero Scott Jehl has cracked it.

This fix works by listening to the device’s accelerometer to detect when an orientation change is about to occur. When it deems an orientation change imminent, the script disables user zooming, allowing the orientation change to occur properly, with zooming disabled. The script restores zoom again once the device is either oriented close to upright, or after its orientation has changed. This way, user zooming is never disabled while the page is in use.

The script is less than 1KB minified (if you’re already using jQuery or another library, you could probably shrink it further). I’ve linked to the blog post, but you can jump straight to the source on GitHub.