Let’s get back to the beginning

If you’ve written CSS long enough, you’re probably aware of the waves of features that we get to use across many browsers. In the mid-2000s CSS modules for border radius, background gradients, text and box shadows, and media queries were making their way into browsers.

After a monolithic release of CSS3 (or CSS level 3) specifications being published and executed upon by browser vendors we were in a lull, it felt like the development of CSS specifications stagnated a little.

During that time there was also debate amongst browser vendors about vendor prefixes.

Some front-end developers seemed only to write CSS for webkit browsers (Chrome – at the time – and Safari) leading to browsers discussing adding aliases in their rendering engines so that their browser too could render the website as it ‘should’ be. Yet at the time there were various ways to create all of the prefixes required.

Waving the flag

To cut a long (or not so long) story short most browsers ended up hiding new, draft CSS features behind flags and, CSS felt like it stagnated a little.

Ultimately though, this was the better decision; allowing authors to create more robust specifications, letting developers test these new ‘works in progress’ and feedback any issues in the spec. or to the browser vendors.

Onwards, to the future

I think we are in the the initial splashes in another wave of exciting CSS for us to dig our teeth into.

We are seeing the pages of can i use go mainly green for CSS modules like variables, flexbox, filters, scroll snap points and we are very close to being able to use grid across popular, modern browsers.

CSS. It’s broken, in two

Looking at the current drafts for CSS module specifications I feel that we can see CSS is starting to provide us with two clear tranches. That which is inside the curly brackets and that that is outside of them.

/* CSS that could start here */


.elf__hat {  
  /* CSS that would go here */ 
}

On the inside we have rules available to use to style, we can add colour, shadow, rounded corners, filters. CSS ready for us to use that will affect the look and feel of what we are creating. CSS that determines the ‘cosmetics’.

On the outside we have CSS that helps with how we architect our CSS. CSS that can make our codebase more manageable, maintainable, and understandable. CSS that may well not do anything unless it’s added to or invoked by another CSS property.

I’m on the outside

Currently, available today is the custom properties for cascading variables module. Although not strictly ‘outside’ of the brackets, CSS variables allow us to architect our codebases more clearly and succinctly, making them more maintainable.

CSS variables are set by using a custom property (--brand-color--main) and are accessed (with the curly brackets) by using var(). To be sure that we have the values available to all elements in our HTML we place the variables in the :root.

:root {
  --brand-color--primary: #DA2A32;
  --brand-typeface--heading: "proxima-nova", sans-serif;
  --brand-typeface--body: "freight-sans-pro", sans-serif;
} 

We can then call them wherever needed in the rest of our stylesheet, using var().

#main-header {
    background-color: var(--brand-color--primary);
}

I’m looking in

The CSS available today for us to style our HTML is long and winding list. As mentioned further up this post we have flexbox, filters, grid (soon, soon), scroll snap points and more to create our websites with.

There is so much, that this article would turn out to become several books-worth of what is available for the ‘cosmetic’ side, so I won’t start listing all of them here.

It’s almost paradise

Looking at what Safari are doing and reading through the issues and updated specs on the CSS Working Group’s GitHub page there’s several exciting modules making there way to a browser near you soon.

Again we are getting CSS that will help us with the cosmetic (the inside of the curly brackets) and the architecture (the outside) of our stylesheets.

When they’re in, they’re out

CSS that is nearly within our reach to use on the cosmetics of what we are creating are both new and old, some of what we could be using someday (real) soon has been around in the specification drafts for few years already.

We have exciting things like backdrop filter, shapes, regions, and more. CSS that is almost all green in every popular browser.

When they’re out, they’re in

With what (to me) seems a re-ignition of creating and pushing forward new CSS modules, we also have exciting things in the CSS specification drafts for code that will allow us to architect our CSS better.

If you are familiar with preprocessors, as well as variables (CSS Variables) you will be familiar with features such as nesting, and mixins. These could be on their way to the browsers soon for us to take advantage of, allowing us to make better maintainable code. Mixins get a little naming refresh with @apply and nesting acts similar to what you would be used to if you’ve ever nested in Sass.

In the sky, with diamonds.

We can use the future CSS today. Kinda. PostCSS allows developers to create plugins to polyfill or prollyfill draft specification CSS so that we can use it today. We can now ‘fill the gaps’ with plugins for nesting, mixins (@apply), a better @import and much, much more.

That is fantastic, but we need to be mindful. CSS draft specifications are subject to change.

If you start to rely on a plugin to polyfill or prollyfill your current project with code that might be available natively in the future, you must be prepared to ‘watch for the changes’. Some specs change a few times before their candidate release (flexbox or grid for example) and at times, parts of or whole specifications get depreciated.

I can see clearly now

As I’ve mentioned, I think we are on the cusp of a new wave of exciting CSS feature we can use. CSS that not only makes our design patterns and layouts more robust and usable but CSS that makes creating and maintaining the code in our stylesheets more manageable and better.

With this new wave of CSS giving us the ability to write better code and create better products in doing so we should benefit the person taking a look at our websites, web apps and products.

Yet, we must still give due diligence, not everything that’s being created in the drafts, and that’s ok. What is really exciting about this is that, those drafts being in the open and on Github make it easier for us to contribute and voice our ideas, opinions and thoughts on what’s being worked on.

Merry Xmas and a Happy New CSS Year.