What should production CSS look like? Share your layout-to-web workflow

1. Since mobile development tends to be one, maybe two col max, if I'm only provided a desktop version of the design, I just run with it and simplify/distill the design down. If there's any elements that don't work on mobile, they get cut out completely until the designer complains and sends over a more mobile-friendly design 😁 Unless you're hired as the designer, or you're included in the design process, it's not your job to "get creative" or "invent" solutions to design problems that should have been resolved in the wireframe/mockup phase.

2. No preference on grid size really. I tend to use 5 and 24 cols, since they're most prevalent in grid systems, but I'll use 3/4/8/16/anything that looks right/makes the design work best.

3. At minimum for any project, one media query (either for desktop or mobile), and the base CSS defaults to the other. If the design is more complex, I add media queries as necessary to correct issues at the problem breakpoint (usually at uber-wide resolutions if the site's audience is rocking 4k double-wide monitors, or small fixes for absolutely positioned elements)

4. CSS/SASS for most animations, unless it's so complex that it requires JS (JS functionality like checking animation frames or DOM elements, or using a lib like GreenSock). Going CSS-first usually ensures the highest level of browser compatibility, particularly since animations will work even when JS is disabled client-side.

5. I use SASS when the project is so large I'll be using variables across the app (which could be replaced with CSS vars) and when I need the power of mixins to simplify CSS generation (like grids, complex animations, or repetitive actions). Otherwise pure CSS run through a minification process (Gulp/Grunt/Webpack/Parcel) before it's deployed to prod works fine. I tend to use BEM combined with OOCSS, so I have non-conflicting CSS styles (.HeaderMenu with .HeaderMenu > .list and .HeaderMenu .item nested classes). That way I get non-conflicting base styles, with without the verbose BEM sub-classes (.HeaderMenu__item) and my shorter CSS classnames work fine thanks to specificity. Similar to Airbnb's CSS style guide (BEM component-style names), combined with Semantic UI's (OOCSS).

I don’t use grids from 2015, and bem from 2016. Old good plain css (with some help by postcss) and components based architectures with style-in-component (webcomponents, vue or react doesn’t make difference). The “framework phase” is something that i’ve already saw.

For your specific questions, see below. I'll post another comment for your other points. :)

1. Sometimes I get mobile designs, sometimes I just have to improvise. Normally though, that improvisation is pretty simple like just re-arranging items. I don't often have to fully switch out interfaces from desktop when going down to mobile. That said, I normally do have a designer I can talk to if I really am not sure about what to do.

2. Honestly, I don't actually use a grid layout. I have looked at them before but I haven't found one that I'd want to stick with.

3. I normally have quite a lot of media queries, it probably plays a bit into #2 about why. I write a new media query every time something "breaks" in the layout like if it overflowed off the screen horizontally or wraps in an unusual way. I am aiming for as fluid of a responsive layout as I can. I aim to get breakpoints down as low as 320px.

4. I use CSS to do all the actual heavy lifting of styling the animation. I will use JS to add/remove classes on a timed sequence if the animation is that complex. The browser can make better use of hardware rendering via CSS transforms etc.

5. This is going to be an uncommon opinion but I'm not actually a fan of SASS/LESS etc. I do understand what it can provide like removing repetition from CSS and allowing for easier to manage complex styles (eg. variables). That said, I've never hit something with vanilla CSS that I consider a problem that needs a solution like SASS etc. As for BEM, I understand what it can help with but it is too verbose for my liking and I feel makes the styling actually more complicated. I guess these both can be summarized that SASS and BEM solve problems but they don't solve my problems.

i come from the Marketing side ( Ad agencies ), my experience may differ from yours if you're working directly with clients.

1. You should always request a Desktop and Mobile layout at a minimum, if there is no way around it, do your best to adjust and make sure people are aware you're a dev and not designer, so expectations are set. Hopefully by then, they will provide you with the additional layout(s). I don't want to go down the rabbit hole how to design for devs because as a dev, you shouldn't be designing.

2. I tend to lean into how frameworks create their grids, i normally create a sass mixin to output my columns, 12-grid fluid columns. I would suggest to look at Foundation or maybe Bootstrap. If this is a large project maybe import a framework, if this is a small project i would highly suggest to keep a list of handy mixins you can use in various project.

3. Everyone should develop smallest-screen-first ( mobile-first ), and should start with two breakpoints, 768px and 1024px. Any additional breakpoints will be dictated by the design.

4. With animations i would suggest to use GSAP, this animation platform tries to leverage css first but defaults to js. Let's be clear, when you refer to animations i am thinking of non-linear animations, something more then just a fade. Simple rollovers, effects should be in css but the fancy stuff should be with something similar to GSAP. You don't want to add unnecessary weight to your page.

5. I always use Sass, I like using a process to build my Sass. Most of the current frameworks allow you to add linters, in my current project we are using Gulp, created task to clean, compile, and minified my code.

Not every project is the same, so a one solution approach will not work. Before any project you should start by asking yourself, What tools do i need?, you can use Angular, React, Vue, or even Static Generators like NunJucks. Always have a plan before you build.

I've cherry picked a few of your specific points that I can provide opinion on.

apply style using classes with semantic names instead of IDs or elements (i.e. .site_header instead of #header ul)

Yep, a good rule to live by.

include cross-browser prefixes for any animations or exceptions (i.e. for drop-capitals in Safari or webkit- for Safari and moz- for Firefox and ms- for IE. Using an autoprefixer makes that easier.

I've kinda stopped using cross-browser prefixes. The main things I use like transitions, transforms and animations have been long supported. The browsers that don't support them aren't ones I test. That said, it really depends on your target compatibility.

convert any sizes to em and rem instead of px

That is a good rule but sadly not a rule I have been following very much. :(

Write as little to accomplish the most as possible, detailing margin and padding on every little thing makes your styles confusing for someone else to read.

I think the general statement here is good for programming in general. Overly verbose code is always going to have a higher maintenance burden.

To make everything show as the size it should in the design, use *{box-sizing: border-box;}

I agree with wanting box-sizing to be border-box but the way I implement it is a little different.

*, *:before, *:after {
    box-sizing: inherit;
}
html {
    box-sizing: border-box;
}

While not super common, if you did change the box-sizing for a particular element, there is a good chance you want the child elements to behave the same way.

Stay away from inline styling at all costs.

Yep! Even for cases where you might have something like style="display: none;", I'd switch that for a class like .hidden or something.

float as a positioning selector is a thing of the past.

Yep though I'm also bad with this though I am getting better! Flexbox is my go-to instead.

!important does not always fix a problem

Yeah... I've had long discussions with one of my colleagues about !important and whether we should use it at all. Personally, I've tried to avoid !important in any styles at all with the exception of print styles. The only reason I have it there is because of a no-print class I have. Because I target that specific class, other selectors have more specificity so I need to force override them.

1. Way too project-dependent to answer. Since space is usually the concern, figure out which elements are essential and which can be relegated to a menu or removed entirely.

2. I don't use fixed-size grids, it's too restrictive. I do like to have a centered content area of a fixed maximum width, since it's hard to read extremely wide windows.

3. As few as possible, obviously depends on design and that may not always be possible but I feel it's best to have a single breakpoint around 480px. Why 480? Because your mobile layout will span 300-480 wide and your desktop breakpoint will span 480-800 or 900. You can have a layout that looks good at 480 that's not cramped at 300, you can have a layout that looks good at 500 that doesn't look empty at 800.

   I think it's fine to show/hide a couple of elements with more than one breakpoint too but you don't want to be maintaining 3 or 4 complete separate layouts.

4. CSS where possible. Not sure where I would have an animation that is only possible with JS. Not counting using JS to change an element's style in order to cause a CSS animation.

5. SCSS all the time! Here's why a preprocessor like SCSS is indispensable for even small projects:

   • You can manage your theme colors with variables in one spot. If you decide to tweak some colors, makes updating the project super easy. Also makes sure you are staying on-brand and not using a bunch of slightly different shades.
   • You can use mixins for compatibility. Instead of having to write multiple lines of CSS for all vendor prefixes each time you use a single rule, you can write out the prefixes once and be cross-compatible with one line (this is especially handy with css grid)

@mixin select-none {
    -webkit-user-select: none;
    -moz-user-select: none;
    -ms-user-select: none;
    user-select: none;
}

span.cant-select-this {
    @include select-none();
}

Also minification and comments! It's good practice to comment CSS, but I don't necessarily want my comments to be made public. So a preprocessor helps with that too.

Hey! These are great thoughts. Totally agree — would also check out AirBnB’s CSS style guide — it’s great.

1. I’ve never worked on a team with a full time designer! I would agree though, that hamburgers and full screen layouts are usuallly the way to go.

2. Definitely depends on the design, but I use fr’s a lot. Super helpful for a lot of layouts.

3. I normally make them once something looks weird. So once text is overlapping or something, I’ll add another mediaquery. I would also look up the sizes of popular devices and make sure your work looks great there.

4. Normally CSS animations are more efficient than JS ones, but really complex ones can only be done in JS. Transforms specifically go to the GPU which makes them super smooth.

5. Bem is still a thing a lot of people like and use! I would say SCSS has the market share for preprocessers. Would go in that direction. I use it if it’s easy to set up for the project, if not, it’s not enough of a game changer for me to get it working.

Great article, thanks, very inspiring!

Those are my thoughts:

• I would use bootstrap (or similar) only for prototypes or small projects without design specifications, in a big project it becomes a limit in few months (overrides and !important hell)

• There are auto-prefixers out there, you don’t want to write them manually

• CSS transition or keyframes (with transform and other hardware acceleration properties) when possible

• never, ever use IDs for CSS, are unique, in CSS we want to style reusable components, not unique elements :)

• don’t try to generalise or reuse everything, repetition in CSS is ok, create reusable components, also small ones that includes behavior and style, don’t create reusable classes, there will always be a special case (many actually:) )

• BEM is a thing, and it’s a good thing to avoid stuff like card sm-margin red in favour of card card—small card—red but also CSS modules and CSS-in-JS are a thing :)

I have created Web Atoms Core, which has CSS styling as JavaScript code.

class ListStyle extends AtomStyle {

    public get root(): IStyleDeclaration {
        return {
            color: Colors.gray,
            backgroundColor: Colors.white,
            subclasses: {
                " > li": {
                    color: Colors.blue,
                    subclasses: {
                        " > button": {
                            color: Colors.green
                        }
                    }
                },
            }
        };
    }
}

HTML

<script>
    import ListStyle from "~src/web/styles/ListStyle";
</script>
<ul
    default-style="{ ListStyle }"
    style-class="{ this.controlStyle.root }">
    <li>First Item</li>
    <li>Second Item</li>
    <li>
        Third Item
        <button>Delete</button>
    </li>
</ul>

In order to avoid naming conflicts in CSS, ListStyle class is instantiated once and root property style is given a css name that is unique. When we assign default-style it creates an instance of StyleSheet if it does not exist and attaches style to current component.

Best part is, IStyleDeclaration object is JavaScript object and it can contain any valid javascript and it refreshes when device size changes. You don't need media queries.

class ListStyle extends AtomStyle {

    public screen = (this.styleSheet as AtomTheme).app.screen;

    public get root(): IStyleDeclaration {
        return {
            width: this.screen.screenType === "mobile" ? "250px" : "900px"
        };
    }
}

Styles can be inherited and overridden easily as JavaScript objects. And you don't need to worry about how and where to put in assets. Also style will only be created for the components that are hosted in the page, making browser free of all unused CSS.

I read about 3%... 2.5% to be honest and kicked this to the read list. But I'll read it when I get 100% sure I can dedicate all of my attention.

As a (mainly) backend developer, I want to give a shout out to all frontend devs. The true magic happens here! Thank you!