Category: Opinion

Prompted by the announcement on 37Signals that their next platform update would not support IE7 or IE8 (or many other older browsers), a vigorous debate took place on Twitter around the subject of for how long we should support browsers which don’t have the most modern features. For all its many positives, Twitter is no place for nuanced argument, so this article is for me to try to frame my opinion a little better.

Read the full article

I think it’s been a really exciting year for our industry; the explosion of web browsing away from the desktop, HTML5 beginning to prove itself as the best option for cross-platform development, the newly-resurgent Microsoft making good browsers again… if you make your living from building the web you can’t fail to be heartened by this flourish of new life. There’s been a great appetite for discovery of new browser features, with lots of demos being made using cutting-edge and experimental CSS, HTML and JavaScript, so the curious amongst us have had plenty to satisfy us.

Part of my contribution to tutsplus.com’s experts(!) review of 2011.

Henri Sivonen has written a fantastically well-considered post called Vendor Prefixes Are Hurting The Web which I urge you to read in full, as I’m about to discuss it. I think some of his points are absolutely right, but I disagree on the final conclusion. The points that I think he nails are:

• Demos that work in one browser/engine only and aren’t updated even when other browsers implement the new features, are harmful.
• Using prefixed features as a way of actively excluding other browsers is lazy and anti-competitive.
• Including an unprefixed property in anticipation of eventual standardisation works against the principle of using prefixes
• When browsers have working, largely compatible, implementations of properties (like transform) they should remove the prefix even if the spec hasn’t reached the stage required by the W3C.

However, I still think using prefixed properties is the right approach. If we do as Henri suggests and leave experimental features in experimental builds (an eminently sensible suggestion, I might add), the pace of progress will be much slower. I believe that having these features out there and getting people using them encourages competition (and collaboration) between browser makers, and the benefits of that competition are given to us, the developers, and passed on to the audiences of the sites we build.

That doesn’t mean that the current situation is ideal; far from it. But improving things will involve more effort from us, the developers and writers, the community in general. Chief responsibilities will be:

• Commit to supporting old demos that we have made.
• Always make sure we plan our designs and builds in a way that they are not reliant on prefixed features, but degrade gracefully.
• Don’t use an unprefixed property before standardisation has happened unless we can have reasonable confidence that it is safe.
• Make sure we stress that the things we use and teach are experimental and subject to change.

As an author and writer I’m guilty of some of the faults that are pointed out in his article, and I promise to do better in the future.

In closing, I want to congratulate Henri on writing this thought-provoking post. I was ready to dismiss it as one of the lazy articles criticising prefixes that occur regularly, but the argument was very well thought and well made, and made me change my mind a few times while I was writing this post.

I recently wrote a feature for .net Magazine, The Future of CSS Layouts, which took a look at several proposed CSS modules intended to provide more flexibility for laying out websites. One of those modules, Grid Layout, has been experimentally implemented in IE10 Platform Preview, and it prompted Mark Boulton to propose an alternative approach in his article Rethinking CSS Grids.

While I think the alternative syntax is pretty robust, I did detect a couple of flaws in it which I promised Mark I would write about, and that’s what I’ll do in this article. Before I get to that, I just want to quickly address one of the key points from his proposal.

Read the full article

The Latin phrase used in the title of this post, primum non nocere, translates as:

First do no harm.

It’s often said that this is part of the Hippocratic Oath, from the code of ethics followed by medical professionals. While that’s not correct, it’s a rule that’s generally considered important to follow: do good, or at least do no harm.

Although what we do is not as critical to society as the role of a doctor, I think we need to start considering an oath like this for working on the web. Let me explain why.

This week I’ve seen two ‘HTML5’ websites which feature rich interactions and animations; like Flash used to be, but now using open web technologies. This is a very good thing. However, visit them with JavaScript disabled and you get a very different experience: that is, nothing, or next-to-nothing. Literally. On one site I saw a logo and a message telling me I needed JavaScript; on the other, a blank screen.

If all of your content is in HTML, and styled with CSS, but you’re requiring people to use JavaScript before they can see it: you’re doing it wrong.

In order to ensure that we make websites available to everyone, regardless of browser type or capability, I would suggest we come up with our own oath — perhaps something like this:

First make your content accessible.

This isn’t new, of course; this is basic stuff. But so keen are many of us to rush to take advantage of all the shiny newness of devices and features, we’re forgetting to do the fundamentals. We’re doing harm.

I’m not a blind Microsoft-basher, neither am I an MS fanboy (in fact, I think the whole idea of aligning yourself with any single technology or brand is pretty narrow-minded). I think MS do some things well, and some things poorly. I am going to have a bit of a pop at them at the end of this article, but I’m going to start by defending them.

Read the full article