Smashing Conf: CSS Application Frameworks

by Luke Wroblewski September 9, 2013

In his talk at Smashing Conf in Freiburg Germany 2013 Nicolas Gallagher shared a CSS Framework in progress and the lessons learned building it. Here's my notes from his talk CSS Application Frameworks:

  • Architecture: is a plan of how to structure an application. A framework is an implementation of an architecture. It is like scaffolding. A toolkit is pre-built components.
  • With static Websites, you approve a design and build it. Then 2-3 years later you might redesign it again. In these cases, you don't need an architecture.
  • Long-lived products are different. You need to find the right problems to solve.
  • Clean code is not the right evaluation criteria for always changing products and teams. Don't think about yourself, think about the problems teams have.
  • Dealing with change is one of the biggest problems within product teams: different skills, changing teams, domain expertise, design changes, and testing systems.
  • Many small frustrations can add up and make you feel out of control or helpless at work. Make people feel comfortable working with the code.
  • CSS is very unstructured. A framework needs to communicate a specific way of thinking: what is right and what is wrong. Remove the need for people to make choices.
  • Design principles can help guide how a framework works.
  • CSS is easy to work with in small components and scope. With lots of components and global scope, things can get really complicated.
  • Web components promises encapsulation so styles don't bleed outside of a component. To achieve this today you need naming collision hacks.
  • Name spacing can scope utilities, components, and Javascript utilities.
  • The issues with CSS and browser hacks biases you toward a lot of documentation about each component in the framework.
  • States are always scoped to components not a global scope. Encapsulation is favored over re-use.
  • The Boston Globe website has 27 different width-based breakpoints and 92 separate @media directives. This is really difficult to test even width automatic testing.
  • We need some restraint with breakpoints for designers and developers to work toward. We can't support and test every breakpoint.
  • CSS pre-processing can allow you to write CSS without pre-fixing and with CSS variables.
  • Custom pre-processors like LESS and SASS require you to learn new syntax. But you should just be able to write CSS code like normal and have a processor take care of things for you.
  • Nothing is perfect, nothing lasts, and nothing is ever finished. The UI layer in the Web platform is always being updated and change continues to accelerate. We need tools to help us know what the common baseline is, and allow us to escape global scope issues.
  • When Web components arrive and fix some of these issues many CSS frameworks will be thrown anyway. Accept this in how you build today.