Personal Blog of Eoin Kelly

Not Your Grandad’s Progressive Enhancement

TL;DR Progressive enhancement does not mean that everything has to make sense as a document.

I really enjoy The web ahead. In episode 65 Jen Simmons and Simon St. Laurent chat about the influx of new folks working on the web and voice their concerns about the values these new people bring. Jen has also blogged about this.

My perspective on this is as somebody with a foot in both camps here having started as a front-end dev, drifted over to the server and now alternating between both.

Back in the day, the web standards movement advocated for standards compliant, cross device, appropriately semantic way of styling and presenting content. Javascript existed but its role was peripheral, acting as a layer of optional niceness.

And they won. The tenets of web standards are now the accepted way to build websites. Now the success of the web as a publishing platform has opened a new frontier – that of the application development platform.

Progressive enhancement revisited

The central idea that the HTML document should make sense without anything else just doesn’t make sense to folks making web applications. The “job to be done” of a content based site is to get that content from the screen into the brains of readers. This is a job that HTML is capable of doing by itself (season with CSS and JS to taste).

Consider a “Photoshop” alike web application as indicative of the complex, ambitious things we are trying to build on the web now. The jobs to be done here might be:

  • cut this image up into 3 pieces
  • adjust the blue in this image to match our logo
  • combine this image with our logo and a message

These jobs cannot be satisified by HTML. HTML can certainly display an image on the screen but there is no version of “show the image on the screen” that is an acceptable fallback when you want to achieve one of the tasks above.

Progressive enhancement does not mean that everything has to make sense as a documment. That definition worked for us in the past but doesn’t help people making large, complex web applications. We cannot consider Javascript as “sugar on top” even if we wanted to.

What to do

There is an influx of new people working on the web. There are a whole new set of people who have yet to learn that, for all its technical limitations, web workers hold themselves to a high bar.

But also we need to be patient with the new folks. Application development on the web is immature and damn hard right now. It took us a long time to figure out how to put documents on the web so it seems reasonable that in learning to put applications on there, we will make mis-steps too.

Those of us who have been working on the web for long enough are responsible for communicating the values that are the best of the web. If we are to be successful in this then the 2014 web standards message can’t just be a cut & paste from 1998.

Time to find that old blue beanie again and get to learning & teaching.

A Semantic Kind of Blue

Reading MVCSS (by Drew Barontini and Nick Walsh)

… we definitely recommend two things when making use of Sass variables: prefix the variable with what it represents ($color-base, $color-highlight, $font-base) and make use of semantic names ($color-base rather than $color-blue).

prompted me to share my own adventures in naming SCSS colors.

Tl;dr

Colors on your website usually have multiple uses so choosing a variable name that describes them well is too hard. You are better off sticking with a variable name that describes what your eye will see. The most semantic name for #0000FF is blue.

“Semantic” Names

The standard best practice on color names in Sass goes something like this:

1
2
3
4
5
6
7
8
9
10
11
12
// Define a color palette
$color-base: rgb(0, 0, 240);
$color-highlight: rgb(250, 10, 10);

// Refer to color variables as required
.something {
  color: $color-base;
}

.something-important {
  color: $color-highlight;
}

This is generally thought of as creating “semantic” names for each color i.e. we associate a label with our color that communicates some extra, useful information about it. For example, $color-highlight tells us that this color is used as some sort of highlight on the site. So far, so best practice.

However in my experience, it is extremely rare for one color to have a single use-case on a website. Most websites have a small-ish (less than 10) color palette. The same color could be part of a gradient in the background as well as indicating the hover state of the largest buttons on the site. This makes choosing a name for your color that will communicate some useful extra meaning a lot harder. Let’s look at a more realistic example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$color-highlight: rgb(250, 10, 10);

.btn-large:hover {
  background-color: $color-highlight; // Good match. this is indeed a "highlight"
}

.page-banner {
  background-color: $color-highlight; // Hmmm not exactly a "highlight"
}

.btn-massive {
  border: 1px solid $color-highlight; // Oh dear, this isn't a highlight at all ...
}

.btn-massing:hover {
  border: none;
}

Being of sound mind, you dismiss $color-page-banner-bg-but-sometimes-btn-hover-too as a bad idea but you might (as I did) think that you can solve this by simply creating a separate “semantic” variable name for each use-case that will convey useful information to the reader.

1
2
3
4
5
$color-page-banner-bg: rgb(0, 0, 230);
$color-btn-massive-border: rgb(0, 0, 230);
$color-btn-large-hover: rgb(0, 0, 230);

// Hmmm we seem to be trying to re-invent CSS selectors in our variable names ...

Great. Except that you have now commited to creating a new variable for each and every use of a color on your site. Hope you like typing because on a medium/large site this will be a long list of single-use variables. Oh and unless your variable names are specific enough, they will create more confusion than they solve.

There are instances where this would be desirable behaviour e.g. you have a site that you wish to create a number of “themes” for – Shopify does something like this with it’s themes, allowing you to change all the colors in one place. However in most cases, this functionality is not required so all we have really done is insert another level of abstraction into our code.

Now let’s consider

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$color-blue: rgb(0,0,230); // I am a blue.

.btn-large:hover {
  background-color: $color-blue; // Reads nicely eh.
}

.page-banner {
  background-color: $color-blue; // Yep, also a blue
}

.btn-massive {
  border: 1px solid $color-blue; // No worries here either.
}

.btn-massing:hover {
  border: none;
}

This variable name makes no attempt to tell us where it is used – it simply declares that it is a color and it some sort of blue. If a new dev wants to change the look of a particular seciton of code, she finds the selectors that match and change the rules – she doesn’t have to figure out your variable naming scheme. Happy days.

As an added bonus, your color variables are named in the way that your team talks about them – teams speak of “our blue” or “the red” etc. You also don’t have any conceptual weirdness when you use the same color on a button highlight and a background.

And anyway, in what world is “blue” not semantic for that portion of the electromagnetic spectrum that the human eye percieves as blue?

But what if we need a drastic color change? Say the design team decides the blue should become red? Won’t I need to search & replace all instances of the variable? Yes. But it’s ok because that happens very rarely in my experience. What happens much more frequently during development is small changes to colors and these are not a problem – I’m pretty happy to continue calling it blue as long as it looks mostly blue.

Conclusion

Because designs re-use the same color in so many ways, coming up with variable names that describe how/where they are used is too hard and introduces an unnecessary and unhelpful level of abstraction. Simple FTW.

Am I wrong?

It’s happened before. Educate me in the comments.

Blog Reboot

Lake Matherson at dawn

This is the reboot of my blog. Message end.

Opening Links in a New Window Is a Bad Idea

I sometimes have discussions with clients about making the links on their website open in a new window website in the current one. Usually they have heard or read something along the lines of:

  • It will keep people on my website longer.
  • It will even improve my google rankings.

And who wouldn’t want more engaged users and better google rankings right? So at first glance it can seem like a good idea. However I think it’s a terrible idea and have outlined my reasoning below for you to make your own mind up.

What It Feels Like to Follow You on Twitter

Dear @you, Hi, I’m one of your twitter followers. Why? Well twitter is like a personal news site for me where I can aggregate news from many sources – official news outlets such as @nzherald and @rtenews as well as news from people & brands such as you. Basically I’m interested in what you have to say. Cool huh?

So I’m talking to you, the account that wants people to hear what you say – maybe you have an awesome product or service to sell or maybe you just want to the world to hear what you have to say – either way, you had me at “hello”.