Oliver Joseph Ash

Comment Your CSS: Relationships

Thu, 20 Nov 2014 00:00:00 +0100

In this post, I will demonstrate situations in which we create relationships between rules in our CSS, before arguing for more discipline when authoring CSS to make such relationships explicit in our code.

Resets

A DOM element can have multiple rules as the result of four different design patterns:

When the HTML is configured, classes can be composed together on a single element, or the way the HTML is configured to create a DOM tree could result in elements inheriting styles from rules applied to parents.
At runtime, media queries can augment elements with additional rules.
When the CSS is authored, class inheritance results in an element having multiple rules.

When an element has multiple rules, conflicting style declarations between these rules can result in style resets. The following examples demonstrate how style resets can occur when an element is rendered with multiple rules.

Class composition

.widget {
    border: 1px solid black;
    padding: 1rem;
}

.widget--alt {
    border: initial;
}

<div class="widget widget--alt"></div>

In this example, when these classes are composed together on an element, .widget-alt resets border back to its initial value, initial. Thus, there is a relationship between .widget and .widget--alt.

(I have used BEM as an example of class composition because it is a realistic example given the best practices of the day.)

Style inheritance

body {
    text-align: center;
}

.widget {
    border: 1px solid black;
    padding: 1rem;
}

<body>
    <div class="widget"></div>
</body>

Style inheritance means that elements can inherit some styles from rules applied to parent elements. In this example, the div.widget element will inherit a text-align style from the parent body element.

In many ways, style inheritance is a powerful feature of CSS because it allows you to easily scope styles. For example, we could use style inheritance to give the whole page a font-family.

If we don’t want to inherit a style that is by default inherited, we must opt-out. In the following example, .widget resets text-align back to its initial value, initial. Thus, there is a relationship between the .widget and body rules.

.widget {
    border: 1px solid black;
    padding: 1rem;
    text-align: initial;
}

Because of style inheritance, .widget could be penetrated with other styles depending on the DOM configuration, forgoing any hope of encapsulation. Why should .widget care about styles that it might inherit if it is used in a specific position in the DOM (in this case, a child of the body element)? With the addition of the text-align reset, .widget makes assumptions about what styles will appear on a parent somewhere. A truly ecanspulated class would not have to care about its environment. Our CSS shouldn’t need to know about how the HTML will be configured, because classes should be work whereever they reside in the DOM hierachy.

Fortunately, the forthcoming Shadow DOM features real encapsulation for CSS, requiring explicit opt-in to style inheritance (instead of having to explicitly opt-out like we do today).

Media queries

.widget {
    border: 1px solid black;
    padding: 1rem;
}

@media (min-width: 500px) {
    .widget {
        border: initial;
    }
}

Media queries can augment elements with additional rules at runtime. In this example, .widget resets border back to its initial value, initial. Thus, there is a relationship between the two .widget rules.

Class inheritance

.heading-1 {
    font-size: 2rem;
    text-decoration: underline;
}

.page-title {
    @extend .heading-1;
    text-decoration: initial;
}

<body>
    <div class="page-title">Home</div>
</body>

Many CSS pre-processors enable fake class inheritance with the help of some sugar syntax. (I’m using Sass here; others may differ slightly in syntax.) Our pre-processor transpiles this by extending the .heading-1 ruleset to add the .page-title selector. For reference, the output CSS we are really interested in looks like this:

.heading-1,
.page-title {
    font-size: 2rem;
    text-decoration: underline;
}

.page-title {
    text-decoration: initial;
}

<body>
    <div class="page-title">Home</div>
</body>

As a result of class inheritance, subclasses are given two rules in the CSS. In this example, the .page-title subclass resets text-decoration back to its initial value, initial. Thus, there is a relationship between the two .page-title rules.

Positioning

Relationships can also occur between elements when a parent element creates a new positioning context or stacking context. This happens when you use a value of relative or absolute for the position style.

.hero-image {
    background-image: url(…);
    position: relative;
}

.hero-image__text {
    position: absolute;
    bottom: 0;
    left: 0;
}

<div class="hero-image">
    <div class="hero-image__text">Some text on top of the hero image</div>
</div>

In this example, .hero-image__text positions itself at the absolute bottom left of its current positioning context, which is defined by the parent .hero-image. Thus, there is a relationship between .hero-image and .hero-image__text.

Likewise, any child of a relative or absolutely positioned element that has a z-index will also have a relationship because this position setting creates a new stacking context.

Comment Your CSS

If we model these relationships in our head when we author CSS, why don’t we model them in our code? We’re likely to forget these relationships exist at all if they are not documented.

.widget {
    /* border: 1px solid black; */
    padding: 1rem;
}

.widget--alt {
    border: initial;
}

<div class="widget widget--alt"></div>

Imagine you revisit a BEM “block class” (in this example, .widget) to remove its border (now commented out). In this example, a relationship has been broken between .widget and .widget--alt. Previously the BEM “modifier class” reset the border style back to its initial value. It’s easy to see that we can now remove the border declaration from .widget--alt.

In a large codebase, it could be difficult to see when you have broken relationships. Furthermore, and as we have seen, relationships can exist in several other forms, which could be manifested like spaghetti across your codebase. In my experience, this can lead to stray CSS. Any change you make in CSS could deem other styles redundant.

CSS is write only. You need to know every possible configuration of HTML you will ever render to know when it’s safe to delete a rule or style.

– Pete Hunt

The big problem with stray CSS is that, if left undocumented, it can self-perpetuate: you overcome the stray CSS with a quick fix by resetting it, yet resets were the problem that lead to stray CSS in the first place. Alternatively, you can manually challenge each style to test its prevailing relevance given the current usage, but this can only be done by CSS experts. I call this phenomenon “reset culture”, whereby resets are constantly hacked into the codebase as a quick fix.

When I look at my CSS, I want to know why styles exist so I know what’s safe to delete or change. Developer tools can show us how our CSS plays together, but we can’t see it in our codebase.

I have long wished for an IDE to show me the result of my CSS in the same way browser developer tools do. For now, I’ve resorted to discipline in the form of commenting all relationships.

.widget {
    border: 1px solid black;
    padding: 1rem;
}

.widget--alt {
    // Reset: .widget
    border: initial;
}

<div class="widget widget--alt"></div>

If a relationship is broken in a future version of this CSS and the author forgets to clean up, anyone who does revisit the redundant style will see, because of the comment, that it is no longer needed. If the stray CSS was left undocumented, it would likely never be removed (unless manually challenged), adding bloat to the codebase and creating a culture of fear in the CSS whereby the solution is to always override unusual looking styles. The same is true for all the other relationships I demonstrated previously.

Ultimately, resets are a side effect of the cascade. We should ask ourselves whether the cascade works for or against us for the sort of websites (or web apps, rather) that we build today. I hope we will see more research into the relevance of CSS today.

Postscript

In the resets section I used the initial and inherit keywords. This could be improved by using the unset keyword, which evaluates to inherit for styles that are inherited by default, and initial for all other styles. Unfortunately, unset was not widely supported at the time of writing.
We will see more relationships between our rules as we begin to use CSS flexbox.
Disclaimer: the CSS for this site is very old.

Hybrid Creatives

Thu, 13 Mar 2014 00:00:00 +0100

A common attitude I’ve noticed amongst “people who code” is that the code is “just a means to an end.” I can sympathise with this attitude. Personally, I am far more interested in great products than I am in code.

With this attitude, I think one is perceiving them-self to be less of a programmer and more of a designer. “If I take the shortest path to getting the job done, I can free up more time to think of the bigger picture!”

Whoever has to maintain your code next could well share your philosophy. Unfortunately for them, however, their job is going to take longer because your code is not easy to maintain.

If you’re touching a codebase, you should be fully committed to sustaining that codebase’s maintainability. Positioning yourself above programmers — because, for you, the code is “just a means to an end” — is not too different from shooting yourself in the foot. By jeopardising the codebase, you’re making the job harder for the next programmer (and that could be you).

Whether you’re a designer, a niche programmer, or anything else, I believe you should always give your best effort when engineering. Soon you will turn over faster and cleaner software in less time, and you will free up more time to think of the bigger picture. By giving our most, we can meld great programming with great design. We can be great creatives.

These thoughts are provoked by my attempts to steer away from becoming someone who is just a code monkey, and towards someone who makes great products through the marriage of design and development.

IMG_4953

Sat, 09 Mar 2013 00:00:00 +0100

There Is No Path

Thu, 07 Mar 2013 00:00:00 +0100

When I think about the skills I have acquired to date, I realise that they all came about unexpectedly, without making conscious learning decisions.

I’ve learnt everything by mistake. I know they say, “you learn with mistakes,” but quite literally, everything in web development that I’ve learnt to date has been by mistake.

Humans like to think that we have control. Choose your path. If you do x then you’ll end up at y. But my career so far in web development has taught me that you can’t have control. In this world, curiosity replaces control. Fulfil it, and you’ll end up somewhere you never expected, but it will inevitably be in the right direction, because that’s the essence of curiosity.

I wanted to learn how to make awesome web apps. Many Google searches, Stack Overflow issues, IRC pester sessions, and iterations later, and wow, much to my surprise, I know how to: build and design a REST API in Node.js, write scalable and maintainable CSS at over 10,000 LOC, build Backbone.js applications, and so much more.

I killed my curiosity, and I accidentally learnt a set of new technologies and tools. Instead of worrying about learning the right things… do.

(This is a lesson for myself as much as it is for anyone else.)

IMG_2386

Tue, 08 Jan 2013 00:00:00 +0100

2012 in Review

Fri, 04 Jan 2013 00:00:00 +0100

Looking back on 2012, I:

built my first computer (with thanks to Mike);
got an acoustic guitar, and learned how to make it talk (sort of; with thanks to Mike, again);
worked in my first proper role as a web developer at Clock
… during which I worked on two of my biggest projects, which involved conquering OOCSS and, finally, Backbone;
travelled to Paris, Berlin, the Lake District, and many UK towns and cities – some I forget, and the others are too many to list;
got my first personal website online;
got fairly comfortable with Vim, and much more comfortable with the command line, shell scripting, Git, etc.;
dauntingly, yet contentedly, continued to realise how much I actually do not know (and maybe never will);
sadly lost my best friend – our Irish Setter, Claudia (aged 12);
met and acquainted with Paddy, our new rescued Irish Setter, and also now my father’s best friend.

My New Year’s resolution will be to discover, try, and like at least four things I never thought I would try. (Music, outdoor activities… whatever!)

In memory of Claudia.

IMG_4751

Mon, 10 Dec 2012 00:00:00 +0100

CSS Exceptions: Object Modifiers or Extensions?

Fri, 23 Nov 2012 00:00:00 +0100

Harry Roberts recently published his thoughts on code that smells. In this article, Harry included a section on undoing styles:

Any CSS that unsets styles (apart from in a reset) should start ringing alarm bells right away. The very nature of CSS is that things will, well, cascade and inherit from things defined previously. Rulesets should only ever inherit and add to previous ones, never undo.

This made me think about my own practices for undoing styles. In this article, I will look at methods for coding CSS exceptions with undoing styles, and then without undoing styles, to see what is the better method with regards to OOCSS.

Introduction

Imagine we have a widget object. Our widget has a border, some padding, and some font sizing:

/* Object */
.widget {
  border: 1px solid #ccc;
  padding: 0.5em;
  font-size: 12px;
}

Let’s just say that widget object is used four times on the page. Our design also has another kind of widget, which has all the same properties as widget, but no padding or border. This widget, however, only appears one time on the page.

Using Object Modifiers

What we could do is add an object modifier for the exception (that, remember, only appears once on the page). Let’s call ours widget-secondary.

/* Object */
.widget {
  border: 1px solid #ccc;
  padding: 0.5em;
  font-size: 12px;
}

/* Object modifier (Exception) */
.widget-secondary {
  /* unset */
  border: none;
  /* unset */
  padding: 0;
  font-size: 12px;
}

Our object, widget, assumes that all widgets will have a border and padding. Our object modifier, widget-secondary, just unsets the properties that are not needed for the exception.

This method requires the developer to analyse the design and decide on defaults. For instance, here we recognised that 4/5 widgets had a padding and border, so the widget object inherited those styles, whereas widget-secondary opts-out of those styles to create the exceptions.

By creating a modifier for the exception, we only have to concatenate additional classes in our HTML for the exceptions:

<div class="widget">…</div>
<div class="widget">…</div>
<div class="widget">…</div>
<div class="widget">…</div>
<!-- Exception -->
<div class="widget widget-secondary">…</div>

Using Object Extensions

Going back to Harry’s argument that CSS which unsets properties is smelly code, Harry instead argues that ‘rulesets should only ever inherit and add to previous ones, never undo’. To adhere to this principle, we must replace our object modifier with an object extension. In this example, we will call it widget-primary:

/* Object (Exception) */
.widget {
  font-size: 12px;
}

/* Object extension */
.widget-primary {
  border: 1px solid #ccc;
  padding: 0.5em;
}

Here we are not undoing any styles, so our CSS is shorter. Maintenance is easier because we don’t have to remember that any styles we add to widget also need to be undone by a modifier. But because we now have to opt-in for even the most common styles (border and padding), we have more classes in our HTML:

<div class="widget widget-primary">…</div>
<div class="widget widget-primary">…</div>
<div class="widget widget-primary">…</div>
<div class="widget widget-primary">…</div>
<!-- Exception -->
<div class="widget">…</div>

Conclusion

In conclusion, it seems that by analysing the design to decide on defaults, and undoing styles for any exceptions that occur thereafter, our CSS becomes more complex. We have to remember that any styles added to an object might also have to be maintained (modified or undone) in any object modifiers. This can be overcome by replacing object modifiers with object extensions, but then we have to concatenate additional classes in our HTML.

In the past, I have always used object modifiers (undoing styles) myself in an attempt to refrain from adding more classes in my markup. However, this appears to be just another reason why you should defer work to your HTML in order to keep your CSS tidy and maintainable. In the future I will be using object extensions instead. If you’re still uncomfortable littering your HTML with classes, then have a look at this case study by Harry Roberts which demonstrates how small of a difference it makes to file sizes.

IMG_0798

Sun, 28 Oct 2012 00:00:00 +0200

Summit Awesome – Leeds

Tue, 23 Oct 2012 00:00:00 +0200