WIP thoughts on my last few years thinking about how to scale css for large and small teams working on large and small web applications.

scalable-css-draft.md

How not to scale css

Several years ago I got curious about how css worked at scale. When I first started out, there weren’t nearly as many learning resources as there are now. CSS zen garden was amazing, at the time it showed how much you could change a design without altering the html.

In the beginning, that’s what people sold me as a feature. By writing css, you could make a change one place and have it propagate everywhere. In principle this sounds pretty good. I’m lazy so I like doing things one time. But eleven years later, my experience on both large and small teams is that this is the most terrifying thing about css.

https://twitter.com/thomasfuchs/status/493790680397803521

In the past few years a lot of very smart people have been thinking more about CSS and this has lead to some fascinating discussions around how to build ‘scalable’ ui and how that relates to CSS. When I first started to think about scalability I naturally started to read every blog post and watch every tech talk I could get my hands on. There are a number of suggested 'best practices' around how sass/less/stylus etc. will help you build maintainable css. How mixins can make your code more DRY. How extends will keep your markup clean and pretty to look at. How BEM will make your code so perfect you want to cry.

But what is reality? What actually gets shipped to production? What do all of these tips and tricks do to our production css? How does it affect the whole team? More important, how are your end users affected?

When it comes to designing and shipping products I like to think about reality. Which can be challenging sometimes. I’ve sat in too many meetings where people don't want to hear or talk about reality. They talk in empty phrases about hypothetical possibilities. I like to do drugs and talk like that too sometimes. But, if you don't accurately assess where you currently are and what your reality is, it can be pretty tough to figure out what your problems are. And the chance of finding solutions to unidentified problems is, well, not good.

So there I was, in the fall of 2013, a new employee at an award winning tech company that had a website. And that website had a lot of css. Wanting to familiarize myself with the codebase - I opened up dev tools and started to read the site's css.

Line by line. From start to finish.

Some of the code made me laugh.

/* Start of reusable styles here */

Some of the code made me cry.

.homepage-promos .grid-50 {
    width: 100%
}
.homepage-promos .grid-33 {
    width: 100%
}
.homepage-promos .grid-34 {
    width: 100%
}

Some of it made me laugh and cry at the same time.

#seo-container {
    display: none;
}

Some of it made me wonder where numbers come from

.product-tab {
  height: 530px;
  width: 99.7%;
}

Some of it made me thankful that I have read the spec

  .container-inner.promo-status { 
     float: center;
  } 

Eventually, I stumbled across this class of code.

.left {
  float: left!important;
}

I saw this class and thought - well at least you know what it does. Unlike some of the other css it seemed like it was very reusable. By anyone who needed to float something left.

I kept reading and stumbled across this:

.left-max-scr1,
.left-max-scr2,
.left-max-scr3,
.left-only-scr1 {
    float: left;
}

…followed by this very similar block of code…

.left-min-scr2, 
.left-min-scr3, 
.left-max-scr3, 
.left-only-scr3 {
    float: left;
}

I found myself wondering what the story was behind this next code block. Is it for .header-nav-list elements that aren’t nested inside a .header-nav-container element?

.header-nav-container .header-nav-list {
    float: left;
}

.CA .header-nav-list.second {
    float: left;
}

#nav.challenger-a .submenu-3col li,
#nav.challenger-a .submenu-3col li {
    float: left;
}

Here we start to see a mixture of content-semantic (.submenu) with visually semantic class names (-3col).

.ie6 #footer-content .flex-control-nav li a,
.ie7 #footer-content .flex-control-nav li a,
.ie8 #footer-content .flex-control-nav li a {
    float: left;
}

#nav.challenger-a li.menu-products {
    float: left;
}

CSS is interesting because unlike other types of code, you are most likely to find the most recent code towards the bottom of the file. Reading a css file from start to finish will often times reveal in chronological order how a defined system breaks down.

In the above examples we see things breaking down to increasingly longer selectors that have more and more weight that were only setting one property to one value: float: left.

Mind you, there are only three options for float. Contrary to one of the code examples above, there is no float center. Just left, right, and none.

Reading the css made me think about a lot of things. One thing I couldn’t get out of my head was - why all this work to change one thing? Why write all that code to just float something left? To me, this is a reflection of the mental model most people are in when they are writing front-end code. They are generally trying to change one or two things in an interface and that’s it. And when you are in this mode of development you want to limit the amount of things you break - while also making the change that is being asked for in some jira ticket that got assigned to you.

I also started to think about communication and how it moves in multiple directions. If I’m reading html, I want to know what the css is going to do. If I’m reading css I want to know what will happen if I apply it to a block of html. In a great system there is a two way street of information. If you look at the CSS, you can tell what will happen. If you look at the html, you know what the code will do.

But most front-end systems are not great. You have what I refer to as one-way streets of information. If I am looking at a block of html and I can’t find ALL of the css that will visually affect how it renders in under 5 seconds, I feel that system is failing. So if I ran into the above example: .container-inner.promo-status That means I would have to find elements that had both of those classes (but not limited to) on an element. But by looking at this block of css I also have no idea if it has been redefined elsewhere. So I must grep through the system to find definitions for container-inner and promo-status. By the time I found those definitions - I would probably have forgotten what I was trying to do in which case I’d leave my desk and go get coffee.

On the flip side think about this example:

.red {
	color: #FF4136;
}

I’d presume that this would make an element have red text. I was traditionally told this is a horrible name for a class. But I quite like it. The only way I’d think it was bad is if it set the color property to purple, blue, or any other color that wasn’t red. Or if it was redefined a few times to a few different shades of red. But more on that later.

And if I saw this block of html:

   <div class=“red”>Some text</div>

I’d know without looking at the css what was going to happen. This is what I call a two-way street of information. It’s easy to learn a group of small classes that do one thing well and can be reused in any context. There should be a one to one mapping between a class and it’s definition. Having a class that has multiple definitions be being redefined depending on context doesn’t solve problems, it creates them. The concept of immutability is not new - but we’ve ignored it in the css community for far too long. Imagine if you had a function called ‘filesize’ where you passed it a filename and it returned the filesize. That sounds pretty great. But imagine if sometimes it returned the amount of lines in the file. That doesn’t sound great at all does it. Well that’s what you’re doing anytime you redefine a css class. It’s the worst for people who are good at debugging css. It’s even more horrible for people new to the cascade.

When we look at convoluted css, we must remember that behind every css ruleset is a story. Maybe the author was on a time crunch and didn’t have time to look up if there was some previously written code they could reuse. Maybe they don’t care about css at all and the second something works they save, commit, and go back to writing monads. When I write bad code, it isn’t because I’m not trying to write good code. There are always other forces at work. What are the forces that work against writing clean reusable code? How do we get rid of them? I’ve spent the last few years doing a lot of user testing centered around how people write their own front-end code, consume other peoples front-end code, and think about developing UI in general. It has been a pretty valuable experience (as user-testing generally is). I’ve learned a lot about the different mental models people use - and how to try to construct systems that allow people of all abilities to spend more time designing / building and less time debugging/fighting/crying.

Sidenote (I don’t know where to fit this in) Before I started doing both performance and user testing I did not like the idea of oocss / atomic css. I really liked writing monolithic classes and traversing the dom with my selectors. It made a ton of sense to me and I was able to build out a lot of websites that way. Running tests and testing my assumptions helped inform a lot of how I think about code now. I’m not very interested in what I can do with css. I’m interested at this point in what I can help groups of people do with css.

If you’re going to build a new component, or change a piece of UI in your app - what do you do? I don’t know anyone that reads all the available css in the app to see if there is something they can reuse. Who has time to read thousands of lines of code before they start working!? Even if people do have the time, I have not found that this is their first instinct on how to get going. I don’t blame them.

Even if you did read all of the available css and stumbled upon some code that you think might be reusable - what if someone edits it later? If you are starting from the assumption that your css isn't reusable, your first instinct is to write new css. But most likely you aren't creating a new classification of visual styles. In my experience it is likely that you are replicating visual styles that already exist.

Salesforce may pay people a lot of money. And they may win Forbes awards for being the most innovative. But they are not known for hiring people who are good at css. Their css is anything but innovative. After reading all of the css and going through bits of crying, head-scratching, and laughing out loud - I determined that this problem must only exist at Salesforce. Surely awesome companies like Medium, GitHub, Adobe, and Pinterest didn’t have this problem. They’ve hired some of the most amazing CSS developers I’ve ever met. They most have figured out how to scale css.

Naturally I opened up their sites and started to read their css too. Line by line. From start to finish. I wanted to see what everyone’s reality really was.

I found the exact same things.

Let’s take a look at just the rulesets that set things to display none:

GitHub https://gist.github.com/mrmrs/786241f0a5fade0324e2

Pinterest https://gist.github.com/mrmrs/57705f9a9fdce4d3d6f7

Medium https://gist.github.com/mrmrs/07e2ad668bac33e2da67

Adobe https://gist.github.com/mrmrs/2d5592826adb45748bac

That’s a lot of code setting things to display: none. If you look at the files above ask yourself some questions: Do they seem like they follow the principles behind DRY? Does this seem like a bunch of code you would know how to reuse?

If I’m going to write css, I want it to be reusable. If someone isn’t going to reuse it - it seems pretty useless.

So what does DRY even mean? Because you do have to repeat yourself somewhere! You either repeat yourself in html or in css. But no matter how good you are at html - you can’t build out a new component without editing html. But, it is possible to build a new component without writing a single line of css. And this applies to changing UI too. You should be able to change most things, just by editing HTML.

When you repeat yourself in HTML, there isn’t any real damage to file size (read: multi-class patterns will not bloat your HTML). A user doesn’t have to download every html file from your website to view one page. Yet most web sites are architected in a way that require you to download the css for the entire site when you try to view one page. This is a broken model.

The files I referenced above are the result of css authors generating really long selectors that add a lot of weight to your cascade to do one or two things. And as time goes on there are more and more things in your cascade to override. So your selectors get longer and longer, your file sizes get bigger and bigger, and the amount of time you spend debugging css is going to go up and up and up.

In this model, you will never stop writing css. Refactoring css is hard and time consuming. Deleting css is hard and time consuming. And more often than not - it’s not work people are excited to do. So what happens? People keep writing more and more css.

This affects scalability in two ways. One, it makes it harder to work on your app, but it also means that your users have an increasing amount of code to download. And if you think “oh but it will never get that bad” - well you’re wrong. Pinterest has more than 1mb of css spread out of 5 files [todo: calculate gzipped file size]. That is a lot of css. 97% of it isn’t used on pinterest.com. I’d rather just try and send my users the 3% they do need.

Part of this code bloat is an attachment to authoring ‘content-semantic’ class names. Honestly I’m surprised you can find people that still think this isn’t the worst idea ever. Nicolas Gallagher already wrote the mic drop piece on why this doesn’t work: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/

So we come to the crux of the problem I have with any system that requires you to map visual styles to components in your css. Content semantics have NOTHING TO DO WITH VISUAL STYLES. When I used to build things with legos I never thought ‘oh this is a piece for an engine block’ I thought ‘oh cool this is a 1x4 blue lego and I can do anything I want with it’

It’s all about lego bits. Because I never needed to re-contextualize my understanding of lego blocks. I could use them across ‘projects’ and they were always the same. I dream of this world in front-end development. Give me lego blocks that work everywhere.

Outside of some brand specific background-images, gradients, and colors etc., the overwhelming majority of css you would need for your site has already been written. Yet we continue as a community to constantly reinvent the wheel. Which is starting to feel like building a camera from scratch every time you want to take a photo. I totally think building cameras from scratch is cool and a worthwhile endeavor. But I don’t want to do it every time I am going to take a photo. I just want to go take photos.

When I read about or listen to ideas on how to scale an app’s css - most of the talk is about how to write css. The real way to scale css, is to stop writing css. Abstract out the things you use most - and move to a multi-class pattern where you compose lego bits in your html. You’ll be amazed at how quickly your team starts to move.

There are a lot of problems that come a long with people writing css. Inconsistent values, the introduction of magic numbers, duplicate code, non-responsive patterns. I’m sure there are others.

If you create a system that is flexible and powerful, and pull from that, you might find your designs to be more harmonious. You might spend less time debugging the cascade. Your pages will probably load faster. But who knows. Maybe that won’t work for you at all. All I know is the current model is definitely not going to work.

Writing new css should be the exception, not the rule.

A couple of takeaways:

If you have never read your outputted css from start to finish - I recommend it as an amazing way to learn a lot about css and how people use it. After I read salesforce’s css I started reading css in entirety for many sites. I still do this! I learn something new every time.

Don’t take my word for it! Go test your assumptions. Not many of us sit with other people building UI and just observe how they build out new features or refactor old ones. User-testing is great for this. You can learn a lot from people who are great at writing front-end code and also people who are brand new to it. I wouldn’t have learned much of this if I just sat around and tried to solve problems my self or read all the latest hip blog posts.

🌟 🌟 🌟

Awesome write up! Thank you for taking the time to articulate these thoughts. The notion that our current model encourages writing more CSS was a pretty eye opening slap in the face; I never thought of it like that. Do you know of any companies that are using functional CSS patterns like this at scale?

Wow! Amazing work. Sometimes it feels that CSS scales with every team member into the wrong direction. It should be quick and easy. A parallel workflow — just styling. It's hilarious how hard it is.

"The real way to scale css, is to stop writing css." — is a key point.

I love it. Great draft. :)

They talk in empty phrases about hypothetical possibilities. I like to do drugs and talk like that too sometimes.

😆

<style>

CSS is interesting because unlike other types of code, you are most likely to find the most recently towards the bottom of the file.

…you are most likely to find the most recent code towards… ?

You have what I refer to as one-way streets of information.

…a one-way street of information ?

This to me is a two ion way street of information.

I think a rogue ion got stick up in therre.

that do one thing well that you an use anywhere.

…that you can use anywhere.

between a class and it’s use

its

it generally isn’t because I’m not trying to write good code.

The double negative is confused. Perhaps it generally isn’t because I’m trying to write bad code. ?

This concept of immutability is not new

In this context, it feels like you’re talking more about immediacy or understandability, rather than immutability. You can have a one-to-one mapping of how something works, but technically that doesn’t mean it’s immutable in the programmatic sense (IMHO).

Salesforce may pay people a lot of money. 

I wonder if it’s worth mentioning Salesforce here, as they aren’t mentioned previously. I see how it flows into where you talk about how you wanted to see how other companies do CSS, but I also wonder if there’s a way to cut to the chase here without dipping into this specific case? I think the paragraph would be stronger you just started it as Working at that job in 2013, I determined that this problem must only exist within this company. … and continue from there.

The real way to scale css, is to stop writing css.

You could make this argument even stronger by providing some examples of where this has worked, IMHO. I’ve found when discussing this topic that readers gain a lot of value from seeing how things have been done differently, and what the direct benefit has been. You’ve clearly articulated some practical examples of how content-semantic classes are shitty. Providing some examples of how single-purpose classes/multi-class have saved you file size, cut out complexity, and made systems more understandable would be a great thing to include to seal the argument. (FWIW, I think the practical examples I gave in that functional CSS article I wrote were the only reason it had value for people. They got to see it wasn’t just theoretical, and how it all shook out in the end.)

---

This is a great write-up. A few refinements and some practical examples of how your idea works well, and it’ll be sitting real pretty.

I really agree with you, and it's nice to see such a good explanation of it. One downfall of this, is if your brands design is still going through it's own iterations, you can't really see what "legos" you'll need for it. With that said, we are already adopting your concept by using what I've been naming mini-classes, which is stuff that is always re-usable, like text-alignment, floats, colours.

Great draft, looking forward to your post.

Nice one, agree with pretty much all of the points you're making.

After using "lego-block-based" styling (Basscss) for a real-world application for some time now, I feel the one single aspect in which an approach based on inline classes is lacking is that it cannot support pseudo-classes. More specifically: it is impossible to define the styling of a pseudo-class state in terms of lego blocks. For example: imagine a button whose border color should change upon :hover. Clearly we would like to implement this in terms of the reusable classes as provided by some border color module (such as tachyons-border-colors or basscss-border-colors). But we can't and instead we are forced to write CSS (border-color: #...). Ouch.

One solution (which I am currently using experimentally via a custom PostCSS plugin) to work around this limitation is to not use lego blocks as inline classes but instead to use them as mixins (without arguments).

But I'm quite curious what your thinking has been so far on this topic…

@timmolendijk - a little unsure of what you are saying. Classes do support pseudo elements and so you can have a class that only does something on hover. I use this pattern a lot:

.bg-blue-hover:hover { background-color: blue; }

These aren't 'inline classes' they are just classes. Inline styles are a much different thing.
Does that answer your question or did I misinterpret?

This is amazing, thank you so much for taking the time to write this @mrmrs.

@DLavin23 - Buzzfeed? http://solid.buzzfeed.com

Tools like Sass, LESS, Stylus, also PostCSS, Ideas like BEM, SMACSS had made a huge progress for CSS styling.
But fact is, many front end developers did not care about it at ALL!
I am the one who was curious about what is a best solution for web developer to build a scalable stylesheet,
after many failures, realized that the answer might was wrong about BEST.
Coudn't agree more with the two-way street of information, that's the new point for me~ thx for that

@twoism-dev nice! Really cool to see a large company utilizing immutable/atomic css patterns. Although, at a cursory glance, it looks like they still have some work to do...http://cssstats.com/stats?url=http%3A%2F%2Fwww.buzzfeed.com. I counted 404 declarations of display: none; 😏

@mrmrs – What I mean is that classes cannot be applied to an element in pseudo-class state. At least not as long as we use classes in the conventional way (by "inlining" them on the element definition) as opposed to, for example, using some kind of @extend mechanism.

The solution you propose works, but don't you think it feels silly and cumbersome to replicate CSS without any clear benefit?

<button class="bg-blue border-lighter-blue bg-lighter-blue-hover border-blue-hover bg-lighter-blue-active border-red-active bold-active">I’m blue</button>

.bg-blue {
  background-color: #00BFFF;
}
.bg-lighter-blue {
  background-color: #87CEFA;
}
.border-blue {
  border-color: #00BFFF;
}
.border-lighter-blue {
  border-color: #87CEFA;
}
.border-red {
  border-color: #FF4500;
}
.bold {
  font-weight: 500;
}

.bg-lighter-blue-hover:hover {
  background-color: #87CEFA;
}
.bg-lighter-blue-active:active {
  background-color: #87CEFA;
}
.border-blue-hover:hover {
  border-color: #00BFFF;
}
.border-red-active:active {
  border-color: #FF4500;
}
.bold-active:active {
  font-weight: 500;
}

This does not feel like something one would want to be doing for an entire app – imagine what a button will look like when we add a couple more requirements and pseudo-classes.

I tried, but I backtracked fairly soon because it just felt too painful and wrong.

---

The problems here are lack of composability and “pseudo-classlessness-induced” verbosity.

Wouldn't it be a lot nicer if we could write something along the following lines:

<button class="my-blue-button">I’m blue</button>

.bg-blue {
  background-color: #00BFFF;
}
.bg-lighter-blue {
  background-color: #87CEFA;
}
.border-blue {
  border-color: #00BFFF;
}
.border-lighter-blue {
  border-color: #87CEFA;
}
.border-red {
  border-color: #FF4500;
}
.bold {
  font-weight: 500;
}

.my-blue-button {
  @extend .bg-blue, .border-lighter-blue;
}
.my-blue-button:hover,
.my-blue-button:active {
  @extend .bg-lighter-blue;
}
.my-blue-button:hover {
  @extend .border-blue;
}
.my-blue-button:active {
  @extend .border-red, .bold;
}

P.S. If you don't like the reusability of .my-blue-button because f.e. you don't intend it to be reusable, you can switch out .my-blue-button for an (element-specific) identifier such as #blue-button-x.

---

So this is essentially the approach that I am currently taking. Yes it is very experimental and it depends on preprocessing, but it is the only one I have been able to come up with that makes a lego-block approach to styling actually practical.

really great :)
says all the things I wish I could convey when evangelising this approach to CSS.

I have no constructive feedback at this point, just a "hope to see this soon" word of motivation! :) 🙇

This is great, a really good rationale for why to prefer single purpose classes over component classes that do many things at once.

@timmolendijk - I don't know what you mean by "nicer" - in your example you are going to keep generating more and more css. Extends I've found are impossible to use when more than one person is writing css. There are many great articles on why it should be avoided. If it works for you great! But this doesn't address the 'at scale' part. It's mathematics. You can output more variation with less code when you break things down to small pieces. "Nice" seems to be subjective. I'd ask - what problem does your pattern solve? Again if I see blue button in my markup - what does that mean? Are there rounded corners? What is the hover interaction? What happens if you need a blue button that has a border vs a blue button that doesn't have a border? Part of what I'm trying to address here is that I want css to work across all projects. "Blue button" can mean so many things - it sounds like a simple thing - but it really isn't in practice. There are still many variables. Maybe some blue buttons have white text, maybe some have black text. I don't know what you mean by "replicating css without clear benefit" - could you please elaborate? I think in the examples I outline there is NO css repetition. Your model though, will output the same css over and over again. Check these articles out about extend - I have never found them to be scalable at all but these articles are a bit more articulate. Would love to hear your thoughts:

http://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
https://oliverjash.me/2012/09/07/methods-for-modifying-objects-in-oocss
http://csswizardry.com/2016/02/mixins-better-for-performance/

@mrmrs Thanks for your elaborate reply. I'm digesting it as we speak.

Just a quick reaction regarding extend; I think this discussion shouldn't be about extend as a tool since the only reason I use extend in my examples is because it is an existing concept that makes my code samples comprehensible. I agree with the communis opinio that extend should be avoided in favor of mixins. So what I would be suggesting (and what I am actually currently using) is a construct that makes it possible to mix-in the declarations inside a class instead of extending it. But I think that should be irrelevant for the point I'm trying to make.

I don't know what you mean by "nicer"

Something that is more readable, comprehensible, maintainable than:

<button class="bg-blue border-lighter-blue bg-lighter-blue-hover border-blue-hover bg-lighter-blue-active border-red-active bold-active">I’m blue</button>

In other words: something that does not require creating a new class for every pseudo-class that you want to support on a lego block.

in your example you are going to keep generating more and more css

Maybe I shouldn't have included the idea of composition in the mix because it is not entirely relevant. Let me rephrase my point: what if instead of applying classes on the HTML tag, we could apply them in the style sheet itself (and use f.e. an element id to establish the one-to-one relationship between classes and element):

<button id="blue-button-x">I’m blue</button>

#blue-button-x {
  @extend .bg-blue, .border-lighter-blue;
}
#blue-button-x:hover,
#blue-button-x:active {
  @extend .bg-lighter-blue;
}
#blue-button-x:hover {
  @extend .border-blue;
}
#blue-button-x:active {
  @extend .border-red, .bold;
}

Notice how the preceding CSS is really just a means of applying classes to a (single specific) element and nothing more, so it should be considered an alternative to listing classes in the class attribute on that element. The major differentiator of course is that now suddenly we get pseudo-class support for free. At the same time we lose none of the benefits of lego-block-styling. Win.

Your model though, will output the same css over and over again

The byte size of the (preprocessed) CSS in my scenario is probably going to be significantly larger than in yours (especially if we mix-in instead of extend, as I propose), but much of it will be squashed by gzip as soon as we send it over the pipe. And on top of that, browsers can deal with a little extra CSS just fine, so it's a price I'd gladly pay in exchange for better maintainability.

@timmolendijk - If this works for you that is awesome. But I think we are talking about different types of scale. Because gzip doesn't take care of the bloat that comes from this approach. Pinterest serves up 159kb of gzipped css. Kickstarter serves up 156kb of gzipped css. The approach I describe will often times keep your css somewhere between 2-10kb. 140kb difference is non-trivial. And their css is probably still growing! That isn't even the peak. Besides sending more stuff over the wire -you also have more and more code that becomes impossible to memorize even for the greatest css minds. This promotes people to not reuse existing classes and to keep adding to the pile. I totally used to use the method you describe - and it made a lot of sense to me at one point. But through both performance testing of how it affected page speed to user-testing how it affects peoples ability to build out UI - I have found it is very unscalable. I encourage you to not take my word for it and run your own tests that aim to solve the problems you are trying to solve. But this is what I've found trying to solve problems at scale.

@timmolendijk - Also I really appreciate you taking the time for this discourse and writing out these examples. I know it is very time consuming and a pain! So please - keep asking questions.

@timmolendijk - I recently saw some research showing that due to gzipping, pages with @Mixins actually rendered smaller than the same page with @extends (due to the repeated property/value pairs). It may have been Harry Roberts that wrote it. So while @mrmrs and I would have to agree to disagree on the one property per class approach, we should all easily agree that @extends benefit nearly nothing and nobody. ;)

@stefsullrew - Agreed

@stefsullrew - I don't have a one property per class approach. I have a single purpose class approach. This sometimes means that there is only one property per class per breakpoint - but not always. The point is each class does one thing very very well.