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

[James Turner]

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.

[Jen Chan]

Thanks for your feedback. By the way, what is this no-print class you mentioned?

[James Turner]

So a no-print class is designed for controlling whether an element will be printed if someone prints the page. Quite simply, the CSS rule looks like:

.no-print {
    display: none !important;
}

That would be in a print.css file or media query with the media being print.

For me, that is probably one of the only cases where I use !important because that declaration is otherwise not always going to apply.

When you go !important, you need to be absolutely sure that it is the final and ultimate transformation you want to do for matching elements. In print, I need the elements to be gone.

Similarly, you can have only-print classes which do the reverse though it gets harder because for some you might want display: block !important; and others display: flex !important;.

All of this being said, a class like this really is saying what it does rather than what it is, which you may look at as breaking semantic rules for class names.