Hey Designer/Developers, I got a question for you. Yeah, you 👇🏽

When working on a project codebase that is expected to grow and evolve heavily. How do you usually split up your CSS (SASS, LESS etc) in a good way to take into account all the different device sizes?

I am not asking how it is done but more about the design of the code. This would be for a production codebase to be released.

Do you use large blocks broken down by media...

(Media width) {

~site code

}

(Other media) {

~same site code with diff sizes

}

Or do you do individual media queries inside css classes...

.className {

(Media size) {

}

(Other media) {

}

}

Or a mixture of both?

If it is a mixture of both then how do you decide which way to go about structuring the code.

I have been endeavouring to greatly improve my CSS and have done so. But this question has been bugging me. Both sides seem to be a bit sloppy and my programmer side is fighting the repeatitipve code.

Note: all code examples are gibberish and only intended for visualization.

Yeah. This got tagged wrong. 🙅🏼‍♀️

I usually, if I actually need to make media query based changes just group them up like

@media(){
.Bunch_of_classes
}

Per size, it’s not often you’ll have to make adjustments using a responsive framework unless you’re going outside it’s box with a design.

@C0D4 That’s a good point. Using something like Bootstrap can reduce a lot of the need to mobile queries.

I have been on a few project that were started with bootstrap though and it seemed to drive our good designer/developers crazy. They seemed to hate that when something need to be custom that it took layers and layers of changes to make these simple modification, because of the rules of the framework.

But that’s off topic...

So, let’s say you were not working with a framework and you did what you described above.

Would you repeat all the code from all the classes inside in every other media size? I’m sure there would be a lot of cross over and repeated code?

If, let’s say the structure of those classes grew and got deeper, would you see this causing problems with developers having to update detailed and multi-level classes in multiple places?

Thanks for the input!

@leanrob bootstrap has its moments of pain staking when designers want something it won’t do naturally.

As for starting from scratch,
can’t say I’ve done that in a while 😂

I would try and plan out the main templates as much as possible to minimise the repetition of classes and build a base structure that works in the lower sizes and make the minimal changes needed to scale it back up to desktop nicely.

Having every class rewritten in every query size will become over whelming when the template starts to grow out and mistakes will happen.

So yes doing it in a block persize would work if you can reduce the number of changes needed going up to desktop.

@C0D4 That’s a really good point about planning in advance.

I have not gone into things with the mindset of “scaling up for desktop”, I always thought of it as “shrinking for mobile”. But just reading it I can feel that your mindset is right. In a mobile world I would be working from mobile up.

Thanks for the new mind expansion buddy!

I would just group all of them on a media queries

@media (screen) {
Whole classes here
}

@media (anotherscreen) {
Another group of class
}

At the end of my css files

@leanrob it’s a hard mentality to get use too, especially when your only use too desktop layouts.
But starting from mobile and working up will save you a lot of energy and headaches later.

It will just be challenging getting the designers to switch if they don’t do mobile first design.

@C0D4 I can see it being challenging for my current project. But that’s a good thing.

Through challenge comes success. A sword only stays sharp in battle type of thing.

I’m rethinking the entire design at this moment based on this new found mentality.

Also, I wanted to open the floor to the possibility of linking some projects with open source code that you would consider a good example of how to handle these issues at scale.

If anybody has some link feel free to drop them and liven up the discussion.

if you follow BEM (together with scss in my case), then most usually you will do the second option you suggested in the OP, to apply to block/element level, instead of the entire site, that can get much more ugly over time, than having "components" react to the viewport

that way you could also split them into seperate files (with meaningful names) and compile them into one before deployment with webpack or something

http://getbem.com

@JoshBent I can confirm everything you just said. I’ve used BEM before with some success.

I went down the same route you mentioned and eventually it got messy.

That’s actually one of the major things that prompted this rant.

It seems like, as usually for our profession, there is no right answer but simply a bunch of trade-offs to measure on all sides.

@leanrob how would you make it messy if you split elements into their actual BEM levels and then component them into their own files?

for that to be needed, you really need a huge site though, I rarely ever saw anybody needing that

can't find the link right now, but medium themselves were using a mixed BEM for their entire website, which has tons of slight changes, especially across different viewports

@JoshBent I’ve never come across this BEM methodology, but it certainly looks like what Salesforce implements so I’ll be reading up on this😎

The more we know!

I do individual media queries in CSS-classes. Because I like to create modular components, each in separate files.

I am a big fan of using SMACSS (Scalable and Modular Architecture for CSS)

SMACSS is a style guide, it is a way to examine your design process and to attempt to document a consistent approach when using CSS.
SMACSS is about categorization, identifying repeating visual patterns so you can define better practices around each of these patterns.
The idea is to divide styles into 5 categories: base, layout, modules, states and theme. Each category is defined by its own guidelines, they are then supposed to be coded into flexible/reusable modules (independent from the context or content).

I like this approach because it's easy for CSS at enterprise levels to get messy. By setting up the expectations from the beginning you can have a maintanble CSS codebase.

I also do a mixed approach to media queries when using preprocessors.

I make a _mediaqueries.scss file as part of the project scaffolding and it's imported first in the main style.scss. It holds the media query as a mixin and all the media query definitions (defining what $desktop, and $tablet and $moble sizes are going to be for this site) and then once setup they are used in the markup as needed attached to the element it's affecting. This way if I have to go back and edit a button style I can see that button also has things going on in tablet and mobile as I see the media queries right there too.

I have my own micro CSS framework that I use that's an example of SMACSS. Once I clean it up a bit I'll share the link.

I do it via passive screen size listener in JavaScript. I don't use CSS.

@natesymer what the hell