The Designer’s Guide to the Galaxy… (of Code) E04
Among the thousands of stars in the milky way of UX articles, one story will froth up above all others — “Should designers learn how to code?”
In case you were wondering… this is still, not that story.
If you glimpse at most of the web nowadays it is easy to forget that when HTML was introduced, styling was an illusion and the cascading style sheet was doubly so.
That is because when HTML sprung to cyber-spatial life in 1989, there was next to no way to change the way your page looked. The text sizes and spacing were defined almost exclusively by the browser you used to access the web, and short of using images and employing creative hacks, it wasn’t possible to put your stamp on them.
We would have to wait nearly half a decade to get a proposal that would muster enough support, to actually be implemented by most browsers. In 1994, Håkon Wium Lie, a co-worker of Tim Berners-Lee at CERN, would conceptualize a styling language that collided perfectly with HTML. 🤓
It was known as Cascading Style Sheets, or CSS.
Contrary to its competing proposals, it did not require almost any changes to the logic behind the know widely used Hypertext Markup Language, it could be written on a separate file(s), further separating style from content and just like HTML it was human readable, easy to learn and highly forgiving.
A cascade of growing pains
If you have shared enough time with a real developer™, you will hear plenty of complaining and whining about it, and a lot of them would gladly avoid writing it if they could. Don’t panic!
Unfortunately the flexible nature of the language, as helpful as it is when you finally grasp the way it is meant to be used™, also brings with it a plethora of problems.
Even though CSS was officially adopted as a standard by the W3C in 1997, browser support for it ranged from incomplete to downright buggy, with missing features and even proprietary CSS properties that only worked for a specific browser.
We would have to wait for 2002, for full CSS level 1 support on Internet Explorer 5. Mozilla Firefox which released in 2004 and Google Chrome that came only in 2008, started a trend of better standard adherence that made styling the web much more reliable.
Nowadays, unless you are doing sites or apps for big companies users, that somehow still have Internet Explorer 9 on their yellowing (or greying) computers, you can use most of the new and shiny CSS3 features.
And you have much better tools, like Can I Use… where you can find which browsers support that new feature you want to use and tools that you will add necessary vendor prefixes for those older browsers that still stubbornly implemented features their own way.
What a time to be alive and even better one to start CSSing 😅
One skeleton with a thousand skins
You might be wondering why on earth a language that had so many support issues and head-scratching cross-browser bugs, is still around and stronger than ever… 🤔
You can sum it up to one word, flexibility.
We are not talking about, the stereotypical dozen ways to get the same result kind, this is the “you can get hundreds of different looking pages with the same HTML” kind!
That is exactly what the CSS Zen Garden project endeavored to prove, putting to rest most of the doubts of CSS skeptics around the world. The challenge, which was opened in 2003 and is still open and active to this day, is simple… take the same HTML document and create an entirely different looking page with just CSS. As I write these words for you, there are 218 unique designs listed 😱
Show me the CSS already
I shall give you a little peak right now my patience tested young padwan!
This little snippet of CSS selects (thus the name) the body tag of our HTML document and change the following:
- Remove the default margin and add a 40px padding (white-space counting from the borders of the HTML element).
- Make the background black (since the
bodywraps the entire visible document we make the entire page black).#000000is the hexadecimal color code for pure black (0 as absence of light). - Set the text color to a very light gray (
#ffffffwould be white). - Declare the default page font to be Titilium Web (wow, much spacey 🚀).
CSS has its own syntax, so instead of the HTML “angle brackets” for tags , it requires “curly brackets” to open and close selectors. The property is separated from it’s value with a colon, and after value you add a semicolon, closing the declaration.
Choosing selectors
Selectors are the way for our CSS properties to affect only the desired elements of an HTML page. With them you can change the background color of only a specific tag marked with an id, color all elements with an certain class, or even change the appearance of a disabled button.
Let’s look at some examples of HTML elements and how we can select them via CSS…
In appearance order we have:
- Getting an
articlethat hasid="article-01". - Selecting the
asideelement with the sidebar class. - Target only
inputtags that have atype="text"attribute. - Style
buttoninstances that have the:disabledpseudo-class.
As you might have noticed, id selectors can be easily recognized because they start with a cardinal (#) and classes will always start with a dot (.). Tag attributes are surrounded by “square brackets” and their values can be declared after an equal sing (=), with or without quotes (both ways are valid but I always prefer to type less for the same result).
Pseudo-classes are easy to get but tough to fully grasp (specially when JavaScript comes into the mix). They are states that can apply to specific HTML elements, like :hover and :active, which can be applied to almost all tags, or something as :checked that is meant for checkboxes and radios.
These are only some of the available CSS selectors, if you are curious enough you can check the MDN CSS Selectors reference page.
And with that my sideral companion, we wrap this chapter of our guide… I wish you a well deserved post-orbital rest and bid you adeus 🇵🇹, goodbye 🇬🇧, adieu 🇫🇷, hejdo 🇸🇪 and sayonara 🇯🇵!
So long, and thanks for all the claps 👏
