Format css with your spidey senses.

Deep down we all have our super tingly spidey senses for figuring things out in the best way possible. Now when I first saw idiomatic css by Nicolas Gallagher, my tingley senses got all zingy for how we organize our css! For those of you just digging into formatting css, here's a brief overview of idiomatic css:

    .cocoa {
    /* Positioning */
    /* Display & Box Model */
    /* Other */
  }

Stuff like position, top, right, floats, you name it goes up into Positioning. More boxy stuff like display, border, margin, padding, go into Display & Box Model. Then you have your Other and you guessed it, that's for all the rest of our css. Can we do anything else with Other?

Chunking & Mapping

What if we broke our initial idiomatic css model down a little more, especially that ominous Other. There's a lot of different types of properties out there that we could begin to reconsider:

    .lemon {
    /* Positioning */
    /* Display */
    /* Box Model */
    /* Typography */
    /* Cursor & Pointer */
    /* Appearance */
  }

With this enhanced model, we've added Typography and Cursor & Pointer properties outside of Other and into their own groups above Appearance. This additional level of organization gives us a better sense of chunking, grouping like items together, as we read through our css.

The Missing Link

But what about the ordering of media queries, psuedo selectors, and module states? I always go back and forth on this due to how complex a module can get but what if we give it a try: Disclaimer, this is nested SCSS!

    .velvet {
    /* Styles */

    @media print {}

    @media screen and (min-width: ###px) {}

    &:before {}

    &:after {}

    &:focus,
    &:hover {}

    &.state {}
  }

Have we covered all the bases?

  • Styles: base styles directly affecting our selector
  • @media print: optional print styles related to our base styles
  • @media screen: screen based media queries that extend our base styles
  • &:before / &:after: psudeo selectors unrelated to the 3 style categories above
  • &:focus, &:hover: interactivity states shifted down to their own section
  • &.state: a javascript based interactivity state a little abstracted

The ordering of these extra selectors is based on the principle of mapping. Mapping states that a property must be placed as close as possible to what it's going to change.

In this enhanced model, there was some deviation from mapping in regards to media queries and interactivity states positions. Print styles are directly related to base styles and could get lost if screen based media queries were placed beforehand. Interactivity states were knocked down to the end to prevent redundancy if those states were needed by pseudo selectors or other states.

By adhering to the principles of chunking and mapping, we've created an easier model for our brains to read as we write our css.

Formatting Values

Now you're all set for some tidy css structures using chunking and mapping. What about all the tricky CSS values out there like gradients? Gradients have a bunch of things going on with them:

  • What type of gradient is it?
  • Which direction does the gradient fade?
  • What colors and stops does it use?

Let's get down to the boombahyah (you bet I've been listening to Blackpink)! The following css applies a background gradient to the arbitrarily named .mage class. This also uses an inline format where all values are written on one line.

Inline

    .mage {
    background: linear-gradient(to right, red, violet 100%);
  }

While this is probably easier to write, it doesn't establish any hierarchy to the values of the gradient. It takes your eyes a little more time to logically group the values to see what's going on (unless you're an alien!).

Formatted

    .blackpink {
    background:
      linear-gradient(
        to right,
          black,
          pink 100%
      );
  }

By formatting gradients this way, we can clearly identify their different properties. Imagine if complex gradients were all on one line; that'd be freakin crazy!

Transforms

    .autobot {
    transform:
      translate(-50%,-50%) 
      rotate(45deg) 
      scale(1);
  }

The interesting takeaway from the nature of transforms, which this format alludes to, is that they'll be read from the bottom to the top. Scale will be applied first, then rotate, then translate. It's a strange caveat and luckily we have the amazing bali balo and his post about chaining transforms which covers what happens when you switch up the order of transforms.

Clip Paths

    .so-hexy {
    clip-path: 
      polygon(
        50% 0%, 
        100% 25%, 
        100% 75%, 
        50% 100%, 
        0% 75%, 
        0% 25%
      );
  }

We can then apply the same pattern with clip paths too. I got this from the mister Bennet Freely and his neat clip path generation site. There's also box shadows to cover but my fingers are covered in red hot chips!

Aligning properties like a tree aides in your ability to logically chunk the values of a property and better facilitate your understanding of your css

You've reached the end of this post and maybe a different way of thinking. What a journey it has been ;) Give yourself a jibby, a mizzy, and a whip whap and tell us; what kinds of ways have you been tinkering with your css formatting?


743 0 0