CSS

CSS Ruleset Terminology

Image

If you ever wanted a mini-cheat sheet for what every part of a CSS rule is called, here it is:

  • The whole thing is a ruleset.
  • The curly braces and everything inside is a declaration block.
  • The bit before the opening curly brace is a selector.
  • Each key/value pair, as separated by a colon and ending in a semicolon, is a declaration.
  • In those key/value pairs, the key is a property (or property name), and the value is a value (or property value).

Text stroke with CSS

Image

There is a non-standard way to stroke HTML text (SVG has a standard way). It’s not particularly new. There are -webkit- and -moz- prefixes for it. Jen Simmons recently posted about it, with an example:

Code language: CSS

span {
     -moz-text-fill-color: #fde;
  -webkit-text-fill-color: #fde;
     -moz-text-stroke-color: #666;
  -webkit-text-stroke-color: #666;
     -moz-text-stroke-width: 2px;  
  -webkit-text-stroke-width: 2px;
}

And she’s right:

This CSS isn’t fully-baked or fully-supported. But it’s good enough to be used today, especially since it’s simply offering a visual enhancement. It’s not mission critical to making a website usable.

I’d only perhaps add that if you were going to do something like add a stroke around white text, you could wrap it in a @supports to be extra sure it’ll be OK (just in case a browser exists that supports text-fill-color but not text-stroke-color) :

Code language: CSS

@supports 
  ((-webkit-text-stroke-color: #666)
  and
  (-webkit-text-fill-color: white))
  or
  ((-moz-text-stroke-color: #666)
  and
  (-moz-text-fill-color: white)) {
  span {
       -moz-text-fill-color: white;
    -webkit-text-fill-color: white;
       -moz-text-stroke-color: #666;
    -webkit-text-stroke-color: #666;
       -moz-text-stroke-width: 2px;  
    -webkit-text-stroke-width: 2px;
  }
}

See the link for more tricks, and the comments make a good point that you don’t have to use text-fill-color if you’re using @supports: just use color.

Dealing with long words in CSS

Code language: CSS

.hyphenate {
  overflow-wrap: break-word;
  word-wrap: break-word;
  -webkit-hyphens: auto;
  -ms-hyphens: auto;
  -moz-hyphens: auto;
  hyphens: auto;
}

This solution will show hyphens for every browser supporting it and will break lines in every other browser – perfect. [Although] I have tested this solution in 26 different browsers I am still not sure this will work 100% – if you find any edge case please let me know.

Expand last row of wrapped flex items to fill entire row

Thanks to Jonathan Snook, I’ve learnt that we don’t need quantity queries to create a balanced grid. Quantity queries are very powerful, but so is Flexbox. If we just want all the items in the last row to fill the space, regardless of how many there are, then Flexbox can take care of this. But if we want to add additional styles to the items, we still need quantity queries.

This is the grid we want to achieve:

Image

Here’s the Flexbox magic.

The container needs to have the property display: flex; and the items need to be wrapped using flex-wrap: wrap;

Code language: CSS

.list {
    display: flex;
    flex-wrap: wrap;
}

Now here’s the clever bit. We can set an initial width to the items (in this case flex-basis: 23%;) so that each item will always get a width of 23% unless otherwise stated in the CSS. flex-grow: 1; tells the items to grow and fill the space in the row.

Code language: CSS

.list-item {
    ...
    flex-basis: 23%;
    flex-grow: 1;
}

So, thanks to flex-grow, no matter how many items are in the last row, they will always fill the space. Works like magic! It’s amazing how much can be achieved with so little CSS.

Fixed and sticky headers and in-page anchors

I made a little tweak to The Session today. The navigation bar across the top is “sticky” now—it doesn’t scroll with the rest of the content.

I made sure that the stickiness only kicks in if the screen is both wide and tall enough to warrant it. Vertical media queries are your friend!

But it’s not enough to just put some position: fixed CSS inside a media query. There are some knock-on effects that I needed to mitigate.

I use the space bar to paginate through long pages. It drives me nuts when sites with sticky headers don’t accommodate this. I made use of Tim Murtaugh’s sticky pagination fixer. It makes sure that page-jumping with the keyboard (using the space bar or page down) still works. I remember when I linked to this script two years ago, thinking “I bet this will come in handy one day.” Past me was right!

The other “gotcha!” with having a sticky header is making sure that in-page anchors still work. Nicolas Gallagher covers the options for this in a post called Jump links and viewport positioning. Here’s the CSS I ended up using:

Code language: CSS

:target:before {
    content: '';
    display: block;
    height: 3em;
    margin: -3em 0 0;
}

I also needed to check any of my existing JavaScript to see if I was using scrollTo anywhere, and adjust the calculations to account for the newly-sticky header.

Anyway, just a few things to consider if you’re going to make a navigational element “sticky”:

  1. Use min-height in your media query,
  2. Take care of keyboard-initiated page scrolling,
  3. Adjust the positioning of in-page links.

Style List Markers in CSS

It’s a perfectly reasonable to want to style the marker of list items. You know: blue bullets with black text in an unordered list. Or red counters with knockout white numbers in an ordered list.

There is a working draft spec that defines a ::marker pseudo-element that would give us this control.

Code language: CSS

/* Not supported anywhere; subject to change */
li::marker {
  color: blue;
}

It’s possible to do this styling now, though, thanks to CSS counters. The trick is to remove the list-style, then apply the markers through pseudo-element counters.

Code language: CSS

ol {
  list-style: none;
  counter-reset: my-awesome-counter;
}
li {
  counter-increment: my-awesome-counter;
}
li::before {
  content: counter(my-awesome-counter);
 
  /* Style away! */
 
}

Understanding the Critical Rendering Path

Image

When a browser receives the HTML response for a page from the server, there are a lot of steps to be taken before pixels are drawn on the screen. This sequence the browsers needs to run through for the initial paint of the page is called the “Critical Rendering Path”.

Knowledge of the CRP is incredibly useful for understanding how a site’s performance can be improved. There are 6 stages to the CRP -

  1. Constructing the DOM Tree
  2. Constructing the CSSOM Tree
  3. Running JavaScript
  4. Creating the Render Tree
  5. Generating the Layout
  6. Painting

Coding CSS for Context

Dave Rupert recently tweeted asking a question that I see quite often:

Code language: CSS

.some-context .thing { /* special rules and overrides */ } 

Does that go in thing.css or some-context.css?

Then, Harry Roberts discussed this concept further in his article of CSS Code Smells Revisited.

Harry uses a practical example of .thing being a .button. (Well, actually, a .btn but whatever. And yes, I just “well, actuallied” myself. It’s preemptive mansplaining.)

You’ll have the standard button that appears throughout your application. And then you have this variation in modal dialogs.

Instinctively, we start writing .modal .button. Hence, Dave’s question of where to put this particular bit of code. It’s interesting to note that the results of Dave’s survey indicated that a slim majority of people prefer that this bit of code live in with the modal CSS and not with the button CSS.

Harry indicated that it should live with the button CSS. And I agree with him. We’re styling a button! It should be in with the buttons.

[…]

One thing you have to worry about is components becoming too complex. Yes, the modal has a button. It could also have inputs and headings and all sorts of things. Over my career, I’ve noticed useful boundaries and tend not to create components with deep hierarchies.

Identifying The Thing

Going back to our thing that we’re trying to style: the button. Yes, right now, we’re styling a button in a modal dialog. Is this the only place that this exists? Right now, quite possibly. Will it always be the only place it exists? If your project is constantly in flux, then not likely.

Here’s what’s important:

  • We want to identify that this is a variation on our button.
  • We want to indicate the purpose of this button style.
  • We want to avoid tying the code to a particular context that could change.

Going with .button--modal, for example, now identifies it as a variation. But fails on the other two points: It indicates its context and doesn’t say what it’s trying to do other than be in a particular place on the page.

So, why is the button in the modal different than regular buttons? (If you’re the designer, ask yourself this. If you’re not the designer, ask them this.) You might get something like, “It needs to be green to draw attention to the fact that it’s a primary action.” Or maybe something like, “the button is smaller because we don’t have as much room.”

This helps you come up with a name like .button--primary or .button--compact.

Either of those names satisfy the three points I mentioned above.

  • It identifies itself as a variation using the BEM double hyphen.
  • It indicates its purpose through the variation name.
  • It hasn’t tied itself to a specific context.

That last point, to me, is the most important. As a designer, I might end up using these styles on a new page that hasn’t been thought up yet. I might want to use a primary button style on a form that isn’t in a modal dialog. I might want to use a compact button in a sidebar where I don’t have a lot of room.

And as Harry also mentioned, by keeping all our button styles in one place, we have the ability to see patterns emerge across an entire project.

Three months down the line, do we suddenly find ourselves with 30 button styles and need to reduce the complexity of our UI? That can be harder to do if button styles are strewn throughout the codebase, hidden within other contexts.