Preface: In my original post about all the things I think you shouldn’t do when writing CSS, I condemned nesting, using pixel units, fragmenting into multiple files and responsive design that isn’t responsive. All in all, I was a bit of a Negative Nancy. Despite the post title, this time I’m going to talk about all the lovely things you should want to embrace and nurture in CSS.
Only kidding! It’s just me losing my shit again.
Photography
How does your UI design process begin? How do you embark on translating UX research into manifest assets? I tend to play with colour palettes and typefaces, iconography and basic interaction prototypes. From these initial ideas, I start to construct a semiology; an interface lexicon. The stage at which I start trawling the Creative Commons for photographs of people standing around wearing nice clothes is the stage at which I’ve stopped giving a fuck.
How many times have you seen the website for a new service and it just has a vague strap-line like “the new social is now”, a little button that says “sign up” (which is really a link) and a massive fuck-off photo of someone sitting in front of a computer positioned behind the aforementioned text, making it almost impossible to read? “I sit in front of computers,” you think. “In fact — fuck me — I’m sitting in front of one right now. THEY GET ME.” Except you don’t think that, because you’re not a fool. You think, “this photograph has piss all to do with anything and it’s probably about 200K.” It’s not. It’s 500K.
“This background image is way too many K.”
“Okay, I’ll compress it right down and see what savings we get.”
“Hold on — won’t that make it look nasty?”
“True.”
“Hey, why don’t I blur the image first, so the compression artefacts aren’t so obvious?”
“I see no problem with this. My eyes thank you in advance.”
Photography is unavoidable in some cases. Just off the top of my head: websites that advertise physical products or — I dunno — photography blogs. But that photography is content and it belongs in <img> tags where it can be made accessible and content can flow around it properly. Decorative photography is a costly mistake. Weight issues aside, a photograph is a record of something that exists outside of your interface. It has no place as part of that interface’s design language.
Summary: A picture paints a thousand words. Most of those words are just incoherent mumbles and repetitions of the statement “I don’t give a shit about your data allowance.” SVG for charts, diagrams and icons; typography and CSS for everything else.
Giving anything a set height ever
The simple elegance with which web content assumes the spaces in which we put it brings a tear to my eye sometimes. To reproduce:
- Put some text in a wide box
- Make that box narrower
- Observe the box getting taller to compensate, continuing to occupy a similar area
3D transforms and all that shit are nice, but this? This is the foundation of contemporary democracy. And the best thing of all is that you don’t have to do anything, it just —
“Excuse me!”
“Er… yes?”
“Hey, I’ve got these three adjacent ‘calls to action’. They each have a picture, some text and a button (well, a link). The trouble is, the text is different for each, so the buttons don’t quite line up horizontally.”
“Okay.”
“Well, I mean it doesn’t look right. Is there a way you could fix it?”
“Well, technically I could set the same height for each call-to-action (leaving enough room for the tallest), then position each button absolutely along the bottom line of their container. But I wouldn’t — “
“That sounds great, do that!”
“Well, have you actually finalized the copy, because — “
“THAT SOUNDS GREAT, DO THAT!”
“But, when you reduce the viewport, the text will wrap and — “
“THAT. SOUNDS. GREAT. DO. THAT.”
The problem here is that my friend has spotted a problem and decided it needs fixing without considering the wider implications. I know that “fixing” the layout for this one, very specific scenario will either break it badly in other, numerous scenarios, or necessitate writing a mass of redundant CSS to achieve the same effect at various breakpoints. This is something I like to call “the legacy of pixel perfection”.
Summary: Nobody fucking cares if those buttons line up exactly or not. Vain, pointless frippery that doesn’t make anything any more useful or appealing or your product more successful.
Calling it “semantic”
The thing about the word “semantic” is it means different things in different contexts. That’s kind of how logical semantics work actually, but let’s not get too bogged down with that. The point is, on the web, the term semantic — as in “semantic HTML” — has a very particular meaning. It means interoperably actionable by the browser, not “sounds good to me, the developer”.
Take the <button> element: The fact that the element is named “button” is semantic in the broader sense because we can relate back to analog buttons and suppose similar behaviour. But what makes it semantic in the pertinent sense is that it acts as a machine readable cipher, invoking those button-like behaviours at the browser’s say-so.
By using a <button> element, the browser knows you are asking for an element cast from the HTMLButtonElement interface, with all of the peculiar behaviours, properties and signifiers that one of those offers. Button elements can be identified, focused, pressed, clicked and disabled in ways that are reliable and accessible without having to fuck around with any redundant WAI-ARIA or javascript.
So, what does a class attribute with a value of “button” (class=”button”) do? Well, a browser would pick up the sequence of characters, “b u t t o n”, and check any available stylesheets if a matching sequence (except prefixed with a dot, of course) is present. If so, it would honour any styles declared in association with this string and alter the element’s appearance. This has literally fuck all to do with what buttons are or how they behave. The browser does not think “this is a button” just because you’ve given it a shitty gradient, and nothing is actionable except the superficial. That is why the following is not and will never be “semantic”. That is why it is broken.
<div class="button">Activate</div>Far be it for me to tell you how to use words and when, but whenever the term “semantic” is used in relation to web technology and describes internal style naming conventions rather than accessible interface elements, a bag of kittens gets thumbed into the company sausage grinder.
Summary: There’s more to something having meaning than just sticking a label on it. This applies to the web, language systems and culture in general.
Making it just about the code
Since I wrote the first instalment of Things To Avoid When Writing CSS, I’ve had a lot of feedback, including but not limited to, “100% wrong”, “utter trash” and “you’re obnoxious”. A lot of this feedback comes from an angry contingent working in “large teams” for “big companies” who claim that some of my advice would not suit their setting — a setting in which several people work on the same CSS code base simultaneously and indefinitely.
I concede that an agile, expressive approach to CSS possibly would not befit this scenario well. But however you write — or are encouraged to write — CSS within your organisation, I think it’s worth considering what this reflects about the organisation’s culture, and what it says about the product you’re making.
If you make it possible to work on the appearance of different parts of a product in isolation, how do you maintain a conceptual relationship between those parts? If it’s desirable to “modularize” your styling so that one part of the interface does not influence another, is this a symptom that you’re creating a fragmented or complex UX? Is the UX actually perfectly seamless and consistent and, if so, isn’t this a rather piecemeal and inefficient way to construct it? Is your team really working on seven different products at the same time but you’re the only one who’s realised this and everyone else seems to be on drugs?
Well, don’t look at me.
Yes, OOCSS (Object Oriented CSS) et al probably do make the lives of many a developer easier, and I’m sure we all deserve that. But at what cost? Sometimes, just sometimes, I think the way we choose to manage our code buttresses a toxic design culture, persisting a dysfunctional and disconnected way of working. That can’t be good news for the product or, therefore, the user. What can you do to make this better?
Summary: We should invest in the maintainability of our code, unless it’s not worth maintaining.
A11y Rocks
If you haven’t picked up a copy yet, A11Y ROCKS is a compilation of songs from the Web Accessibility Community™. All proceeds go to two really good causes.
