• A Complete Guide to CSS Cascade Layers by Miriam Suzanne
• Hello, CSS Cascade Layers by Ahmad Shadeed
• The Future of CSS: Cascade Layers (CSS @layer) by Bramus Van Damme
• CSS Cascade Layers: An overview of the new @layer and layer() CSS primitives (YouTube) - By Una Kravets
• Polypane, one of the first browsers with Cascade Layer support in the devtools

I can see myself using CSS Cascade Layers in a setup like Structured Front-end components. Maybe I'll write an article about that in the future.

In short they are currently running an experiment in Chrome 86:

In Chrome 86, we’re likewise going to experiment with how URLs are shown in the address bar on desktop platforms. Our goal is to understand -- through real-world usage -- whether showing URLs this way helps users realize they’re visiting a malicious website, and protects them from phishing and social engineering attacks.

While I can imagine where they are coming from – noboby knows what's happening with URLs like this https://www.totally-made-up-shop.com/N/51141/filter/4277392517-4275877262-4275059032-4274437062-26297-21584-16639/ – I'm strongly against the decision to hide parts of the URL. Here's why:

Security

As Chrome's security team layed out in their blog post:

there are myriad ways that attackers can manipulate URLs to confuse users about a website’s identity, which leads to rampant phishing, social engineering, and scams.

While this is entirely true, those are not problems with the URL itself. The problems lie within education of users and spam/phishing filtering on browsers end. And in my opinion their proposed solution only adds up to the confusion by removing key parts of the url.

Users have been told and are getting used to check for the https protocol identifier to check if a site sends data securely. Hiding that will break that check.

Let's say that a user has navigated to the following URL: http://awesome-bank.com/superawesome-phishing-page.html Chrome will only show awesome-bank.com making it impossible for the user to check if the site sends data securely and indentifying the fishy html page they are on.

Basically Chrome reduces the ability for a user to verify a URL by 3 points to just 1 point (https, the domain and the endpoint). Making it less easy for a user to identify possible fraud/phishing/scams.

Identity

Let's say you are using Chrome 86 and you found out about this blog on Twitter. You clicked on the link in the Twitter post and landed on this page immediately. The URL-bar is showing you bram.is. Are you on the homepage? How do you share this page? Where the hell are you?

The URL always provides context and a unique identity to the page you're visiting. When created correctly a URL can add to the accesibility of a page by giving a clear and concise notion on where the user is on your site.

Creativity

The last but certainly not the least important point I'd like to make is that URLs can be super creative.

On this blog for instance all my urls and pages are written in sentence format: “Bram is doing-something”. When you search for my work the URL says: https://bram.is/working And if you want to know more about me as a person: https://bram.is/awesome. Reading a blog post? The URL says: https://bram.is/writing/in-defence-of-the-url

Be creative and clear with your URLs. Browsers should not hide the URL. The users will thank you.

This article is an in depth follow up on the talk I gave at the Fronteers meetup at e-sites.

In 2013 I wrote an article about structuring CSS with Smacss & Sass. Since then I read up on new techniques and changed my workflow here and there to accommodate modern web projects. Many things have changed over the years, but the basics remain the same.

The problem with Smacss

In that time I found solace in the Smacss methodology, it solved the problems which I had in an easy and structured manner. But when the projects I worked on growed in size I found myself struggling with the layout and the modules layers. All the components you make live in the modules section. In large projects you will still end up with a very big file list in that section. Also defining layouts is really cumbersome in my opinion; the larger the app, the more different layouts you’ll get. Smacss also does not provide a good way to structure HTML templates. This can be done better, no?

The basics: Atomic Design

In my search for ways to find a solid methodology to build up design systems in large webapps & projects I stumbled upon Atomic Design by Brad Frost. Brad was trying to find a solution in what our interfaces are made of and how we can construct design systems in a more methodical way.

He found this structure in chemistry, where atomic elements combine together into molecules and these molecules can form together into complex organisms. This can easily be translated into software development and especially into Webdesign.

In my projects I apply Atomic Design by splitting the code in distinct stages:

Atoms

Atoms are the basic building blocks of matter. In your interface atoms serve as the foundational blocks that live in our interfaces. These consist of basic HTML elements like form labels, buttons, inputs and others which cannot be broken down any further without losing function.

Molecules

Molecules in chemistry are atoms grouped together which take on new distinct properties. In interfaces, molecules are relatively simple combinations of UI elements who work together as a group. Eg. a form label, some input fields and a button combine together as a contact form.

Organisms

Organisms are complex and distinct UI components in our interface. They are composed out of groups of molecules and/or atoms and/or other organisms. This could be a header component consisting a logo atom, the primary navigation and a search form. Or it could be a section in your application containing a blog post and a sidebar with related articles.

Templates

This is the place where the chemistry ends. Templates are page-level objects that place components in a layout which can explain the underlying content structure. All content entries are articulating important properties of components like Heading 1: Lorem ipsum (XX characters) or image: 1920x1080px. An example of a template could be a blog page with the header, blog, and footer organisms combined into one simple layout. These layouts are an understandable way to describe the content structure to the stakeholders, bosses and colleagues.

Pages

Pages are instances of templates shat show what the UI looks like with real world content in place. This is the most concrete stage in the methodology. This is what the end-users will see and interact with when they visit your User Interface. This is what the stakeholders will sign off.

Also the page stage is and ideal place to test the effectiveness of the underlying design system. Does everything works good with the actual content applied? No? Back to the drawing board, but you only need to alter the components that needs change. Here we can also test variations of a page, for instance if the user has items in his/her shopping cart.

This was Atomic design in a nutshell, I'm not going to bother you with in-depth information about the methodology. If you want more information you can read Atomic Design by Brad Frost.

Atomic Design applied to HTML with Pattern Lab

The most important part of component-based design and development is a pattern library, which is used as a central hub of all UI components which are used in your interface. There are many benefits to a pattern library:

• Promotes consistency and cohesion
• Speeds up a teams workflow
• Promotes collaboration accross disciplines
• Establish a shared design vocabulary
• Provide essential documentation
• Makes testing easier
• Provides a future friendly foundation to iterate on

Since we are working with Atomic Design the choice for a pattern library was an easy one: Pattern Lab In the basis Pattern Lab is a static site generator and a pattern documentation and annotation tool.

Folder structure

Out of the box Pattern Lab will include a limited folder structure. Actually it is entirely up to the designer to create the folder structure. It does not matter if you want to implement Atomic Design or another template methodology in Pattern Lab. It just works. In our projects we establish the folder structure like this:

This resembles the Atomic Design methodology and gives us proper structure to organise our UI components.

Now that the HTML templating structure is in place we can move on to the next important step in our front-end workflow: CSS.

CSS structure with Atomic­Oocss­Itcss­Bem­(Patent pending)

Since I used the Smacss methodology in my previous article there have emerged a lot more ways to structure and organise your CSS. To name a few:

• BEM
• ITCSS
• SUIT CSS

A lot of them are derived from Nicolle Sullivan's OOCSS ideas. They all try to solve one thing: structuring css in an understandable, scalable manner. In my projects we use a hybrid of Atomic Design, BEM and ITCSS. Sounds weird and complex huh? Why not use one methodology and get it over with? Let me elaborate.

Atomic Design & CSS

Atomic Design can perfectly be used as a structure for your CSS files, you can structure your Scss partials in the Atoms, Molecules and organisms order and you'll be fine. Actually this is how we iniatially did it when we started implementing Atomic Design at Colours.

But when the projects grew in size and length we encountered a big problem with atomic design: Objects. Objects are reusable, style agnostic patterns which usually define layout structures. Think of grid systems, the classic media-object, flexembed and other structural objects. Since objects are style agnostic they have no place in the include based structure of atomic design. Imagine creating a grid-atom(most logical place for a grid in Atomic Design), you cannot include the grid alone in another template.

Instead of being a standalone component objects can be interlocked in other templates. They can be used in the smallest form to provide structure to an atom, but at the same time they can be used in a full blown organism. An example where a o-layout object can be used in multiple situations:

Atom: icon-label

<div class="icon-label  layout">
  <div class="icon-label__wrap-icon  layout__cell  layout__cell--fit">
    {{> atoms-icon }}
  </div>
  <div class="icon-label__label  layout__cell  layout__cell--fill">
    <!-- label -->
  </div>
</div>

Molecule: product-overview

<div class="layout">
  <div class="layout__cell  unit-4-12">
    {{> molecules-product }}
  </div>
  <div class="layout__cell  unit-4-12">
    {{> molecules-product }}
  </div>
  <div class="layout__cell  unit-4-12">
    {{> molecules-product }}
  </div>
</div>

In Atomic Design there is no logical place for these kind of objects, that is why I decided to think of a different implementation.

Scss structure

What I came up with is a hybrid system between BEM, Atomic Design & ITCSS where the best parts of these methodologies are used. First of all we need to establish the structure:

• Settings - This is where all project specific settings are located. Here you will define colors, font sizes, font families, etc.
• Tools - Here you define globally used functions & mixins like font-size mixins, rem helper functions, etc.
• Generic - Normalize, resets, vertical rhythm & box-sizing definitions would live here.
• Objects - Style agnostic objects like the media-object, grid systems, etc. (ideally prefixed with o-)
• Atoms - Basic unclassed HTML elements and everything that cannot be made smaller.
• Molecules - Combinations of atoms, components with disctint functionality.
• Organisms - Combinations of atoms & molecules, sections of your interface.
• Utilities - Helper classes which override everyting stated before. (ideally prefixed with u-)

This will enable us to structure our CSS in a more component based manner and allows us to pull in .scss files from their Atomic Design template directories as well. The typical styles.scss will look like this:

@charset "UTF-8";
/*----------------------------------------------------------------------------*\
    Styles
\*----------------------------------------------------------------------------*/

/*  Settings
    Global variables, config switches
\*----------------------------------------------------------------------------*/

@import "settings/vars";

/*  Tools
    Global mixins & functions
\*----------------------------------------------------------------------------*/

@import "tools/mixin.font-size";

/*  Generic
    Ground zero styles, normalize.css, resets
\*----------------------------------------------------------------------------*/

@import "generic/normalize";

/*  Objects
    Cosmetic free design patterns
    Prefixed with: o-
\*----------------------------------------------------------------------------*/

@import "objects/media";
@import "objects/layout";

/*  Atoms
    These are basic tags, such as form labels, inputs or buttons. They also
    include more abstract elements like color palettes, fonts, and icons.
\*----------------------------------------------------------------------------*/

@import "_patterns/atoms/typography";
@import "_patterns/atoms/buttons";

/*  Molecules
    Molecules are groups of elements that function together as a unit
\*----------------------------------------------------------------------------*/

@import "_patterns/molecules/product";
@import "_patterns/molecules/list-product";

/*  Organisms
    Organisms are groups of molecules and atoms joined together to form
    distinct sections of an interface.
\*----------------------------------------------------------------------------*/

@import "_patterns/organisms/header";

/*  Utilities
    Helpers & overrides
    Prefixed with: u-
\*----------------------------------------------------------------------------*/

@import "utilities/spacing";

As you can see we can properly structure our CSS the same way as our HTML templates while maintaining the layers which cannot be easily put into the Atomic Design methodology. That leaves us with the last layer in out front-end stack: JavaScript

JS Structure

After these changes to our workflow we started tinkering with applying the same structure into our JavaScript layer. These ideas are getting more concrete but they are not crystallized yet. Also this article would become a pretty long read if I write about that implementation too ;).

Credits

• Brad Frost for being awesome and for publishing the awesome book: Atomic Design
• Harry Roberts for his work on ITCSS and other numerous CSS ideas
• Brian Muenzenmeyer for is hard work on Pattern Lab Node and his help & advice

My talk

The talk will be about Atomic Design and how to incorporate this methodology into your front-end workflow. I will be rambling about Pattern Lab, components, templating, using data, CSS, a dash of JavaScript and their place in your design system.

Timetable

• 18:00 · Entry with food
• 18:50 · Introduction and opening words
• 19:00 · Talk 1: Iain van der Wiel - Prevention of complexity in your CSS
• 19:45 · Pause
• 20:00 · Talk 2: Bram Smulders - Atomic design with Pattern Lab
• 20:45 · Drinks

All talks are in dutch, and will take about 45 minutes. There will be a short period of Q & A after each talk.

Venue

The event will be held at E-sites in the lovely city of Breda, The Netherlands. The event is free of charge and there will be drinks and food!

Signup is required and can be done at the Fronteers website

So, be there or be

height: 0;
padding-bottom: 100%;

A couple of months ago I passed by Jonathan Snook's SMACSS website while browsing the web. After reading the SMACSS core articles I felt a bit awkward about how I organised and crafted my CSS. My CSS was quite unorganised and the only pattern used was the waterfall pattern; Work your way from the header all the way to the footer. The CSS also contained fixed withs, overuse of ID selectors & many specificity workarounds. It was not organised, not modular & most of all: Not reusable.

Meet SMACSS

SMACSS stands for Scalable and Modular Architecture for CSS, and is more a style guide than a CSS framework. On a high level SMACSS aims at changing the way we are turning designs into code. Instead of working in a page mentality where you try to turn a single page design into code, SMACSS aims to identify repeating visual patterns. Those patterns are then supposed to be coded into flexible/re-usable modules, wich should be independent as possible from the individual page context. This is not a revolutionary point-of-view for a programmer, but in the web design world this is indeed a newer way of thinking.

Categorization

The basic concept of SMACSS is to devide styles into 5 categories: base, layout, modules, states and theme*. Each category comes with a set of usage rules and naming conventions. The main reason of this categorization is that rulesets should only ever inherit and add to previous ones, never undo.

Any declarations like these

border-bottom: none;
padding: 0;
float: none;
margin: 0;

...are typically bad news. If you have to remove borders, you probably applied them to early.

Base

This is where all the base styles live; resets, element defaults, default font sizes, etc. This category is mainly dominated by element selectors. You should always ask yourself if a ruleset must live in base in order to not lose flexibility down the road.

Layout

In this section you specify all types of layout containers, such as header, footer, content, sidebar, etc. The layout elements haven't got any styles applied to them, they only divide the website into sections. This is the layer where grid systems etc, would be living.

Modules

The bulk of your css is made up of independent modules and submodules. Every module should be completely independent of its context and should work within any layout container or other module.

If a specific context requires changes to a module you rather create a submodule that describes the context instead changing styles based on the parent.

State

Modules can be in different types of states: class-based-states(.is-active), pseudo-classes(:hover, :focus), attribute states(data-state="rotating"), or @mediaquery states. These states belong directly to the modules but have a different categorybecause the have their own naming convention and usage rules.

*Theme

SMACSS points to an optional fifth category, theme, but this is only applicable to pages that require theming. Theme styles override or extend the modules, and only apply colors and backgrounds.

Syntactically Awesome StyleSheets(Sass)

SMACSS works especially well with Sass, and I'll try to explain why and how I implemented Sass into my workflow:

File structure

In Sass you can easily chop your stylesheet into partials by using the @import rule. This allows us to easily organize and maintain our files similar like this:

-theme.scss
  - theme/_base.scss
    - theme/base/_reset.scss
    - theme/base/_headings.scss
  - theme/_layout.scss
    - theme/layout/_masthead.scss
    - theme/layout/_main.scss
    - theme/layout/_footer.scss
  - theme/_modules.scss
    - theme/modules/_search.scss
    - theme/modules/_gallery.scss
  - theme/_state.scss
    - theme/state/_mediaqueries.scss

Partial setup

Every partial stands for a standalone module wich has its own sectioning:

• module, the base module rulesets
• state, the different states the module can be in
• theme, optional but recommended to separate style from structure

Since the module has its own module, state, theme sections it can be easily copied to another project while the characteristics stay the same.

Namespacing

I'm using a namespacing that is based off the BEM front-end naming methodology wich stands for: Block, Element, Modifier. The naming convention follows the following pattern:

.block {
}
.block__element {
}
.block--modifier {
}

• .block represents the high level element of the module
• .block__element represents a descendent of .block
• .block--modifier represents a different version of .block

The point of BEM is to tell other developers more about what a piece of markup is doing from its name alone.

Within the SMACSS guidelines we prefix the classes with a section based prefix. A module should always be prefixed with .m-: e.g. .m-search, .m-contentbox. Elements that live inside a module have classnames like this: .m-search__heading. A brief example of a module:

.m-search {
  border: 1px solid #ccc;
}
.m-search__heading {
  font-size: 20px;
  color: #f00;
}
.m-search__body {
  padding: 10px;
}

A submodule is specified like this:

.m-search--attention {
}
.m-search--attention__header {
  border-bottom: 1px solid #f00;
}

A module that lives in the layout section gets the prefix of: .l-.

When you are using BEM, though, it is important to remember that you don’t need to use it for everything. Take for example:

.text-right {
  text-align: right;
}

This CSS would never fall into any BEM category, it’s merely a standalone rule.

Using Sass @extend

Sass @extend is a very powerful tool to DRY out you stylesheets, but must not be overused. Since we want modules to be portable you must only extend within a modules scope, a module must not be tied to other modules to work.

Conclusion

SMACSS is a very user-friendly approach to modular CSS. It asks for nothing less than a complete shift from a "page mentality" towards web design, to a search and codification of visual patterns. For that it offers a sensible categorization and naming scheme. It goes along very well with SASS, especially using the @extend feature and when it comes to themeing. It's kind of an open question how SASS's nesting capabilities fit with SMACSS, but in general I think it can bring lots of very valuable and badly needed modularity and conventions to the web design community.