Tags: properties



Thursday, June 22nd, 2017

Using CSS variables correctly - Mike Riethmuller

Mike examines the real power of CSS custom properties compared to Sass variables—they can change at runtime.

I’m convinced that in almost all cases, responsive design logic should now be contained in variables. There is a strong argument too, that when changing any value, whether in a media query or an element scope, it belongs in a variable. If it changes, it is by definition a variable and this logic should be separated from design.

Tuesday, May 23rd, 2017

Learn CSS Grid - A Guide to Learning CSS Grid | Jonathan Suh

A quick visual guide to CSS Grid properties and values.

Tuesday, April 18th, 2017

Organize your CSS properties however you dang like – Michael.blog

Neither matters all that much and you can use every method on the same project without the universe imploding.

Some interesting approaches in the comments too.

Saturday, April 15th, 2017

The invisible parts of CSS · MadebyMike

This is a really clear explanation of how CSS works.

Monday, November 28th, 2016

CSS Reference - A free visual guide to the most popular CSS properties.

A whole lotta CSS properties and values gathered together in one place. The one-page view is a bit overwhelming, but search and collections can get you to the right bit lickety-split.

Thursday, November 24th, 2016

Between the braces

In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:

There are two types of problems in CSS: cosmetic problems and architectural problems.

The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:

If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.

This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.

selector {
    property: value;

The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.

The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?

I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.

Tuesday, October 11th, 2016

Pragmatic, Practical, and Progressive Theming with Custom Properties by Harry Roberts

Harry demonstrates a really good use for CSS custom properties—allowing users to theme an interface.

Friday, April 25th, 2014

Incomplete List of Mistakes in the Design of CSS [CSS Working Group Wiki]

I think I concur with this list. Although I guess it’s worth remembering that, given the size of the CSS spec, this isn’t an overly-long list.

It’s interesting that quite a few of them are about how things are named. It’s almost as if that’s one of the, say, two hardest things in computer science.