“A Front-End Developer’s Ode To Specifications” on Smashing Magazine the other day made me kinda mad. I’m all for having a final Front-end implementation that matches up with the designer’s vision, but I think that this idea of “correctly implemented design” and pixel perfection is a damaging way of thinking about web sites because it implies there is one correct, pixel perfect, version of the design.
Designs, by and large, are still created in applications that create fixed width, fixed fidelity, non-squishy, output. This works well with the idea of a specification: “this one version of the product is the correct version.” It doesn’t work well with web sites, which are by their nature, flexible and changeable. Trying to exert this kind of control and constraints on a web site just isn’t tenable in today’s world wide web, or the future’s.
Even something as simple as a font is very flexible. You can specify a base font and size exactly in a specification. But how do you adjust the font size (and line height) for larger screens? And what is the font stack: if the desired font isn’t available, or doesn’t load, what fonts should be tried next?
If the specs were all in percentages rather than pixels: that would be a good start. But then you still need to consider breakpoints and showing layout changes across them. The drift that the author discusses between the designer’s final version and the implementation feels wrong. The developer might get the site looking pixel perfect in the latest version of Chrome. But what about Firefox? And what about Safari on an iPad? And what about Internet Explorer 10 on a Windows machine? These will already look different from each other, even thought they're using the exact same implementation of the design. I think that that’s completely fine: but it won’t match the spec.
Front-end style guides, mentioned at the end of the article, are much more promising. They feel like a logical step into code from Style Tiles, the squishy design deliverable.