I was working with CSS Grid and came to the
grid-row properties. I paused for a moment.
They’re not overly complicated. They are shorthand properties for expressing where an element should start and end on a grid’s defined columns and rows.
What caught me was the fact that I can name these lines. It’s not a requirement (you can use numbers), but the ability to name the grid lines is something we can do here. In fact, naming lines can open up neat CSS tricks.
Grid lines are another item in a long list of examples where front-end developers have the power to name things. Class names and IDs have always been things we need to name in CSS, but consider a few of the more historically recent things where naming is important when it comes to styling:
- Variables: Naming values for context, such as re-usable colors or numeric values whether in preprocessors or new CSS variables.
- Data attributes: Selecting elements based on their HTML attributes rather than a class name.
- Components: Like what we’re seeing in React and future CSS features like Web Components.
- CSS files: Organizational methods like Atomic Design have accentuated the importance of naming our files, including preprocessor partials.
- Media queries: We know naming them after devices is futile, so that has to make sense as well.
It’s not that naming things is ridiculously hard in and of itself. It’s more that there is a sense of power that comes with the ability to name things. As the saying goes: with power comes great responsibility. In this case, naming has an impact on everything from how code is written and organized to its overall performance and maintainability. Poorly named elements are smelly by nature and often indicative of the overall quality of the code. It can lead to the wariness of a growing code base.
Let’s just say I’ve spent more time naming some CSS classes than I spent naming my own two kids. I’m embarrassed to say that, but it’s the truth.
Naming grid lines is just another item in the growing cascade of things we are responsible for as front-enders. It’s not a bad thing or even an annoying one, but yet another reminder of how front-end development is development, design, and architecture all in one.
I think this post is actually underestimating how hard and important naming things are. If you actually sat with a stop watch behind most developers, front or back end, I’d bet you’d find 20% or more of their time is spent naming things. Not only that, but I’d bet 80% of time spent reading code would be reading these names. I feel it’s not naming things getting harder, but the actual logic of our job is being abstracted into reusable Lego like pieces, and each of those pieces need names.
Agreed, the abstraction and importance of naming those lego pieces is exactly what’s up. The point is not that naming things is not hard or hasn’t been hard before, but it’s only getting harder and more important as we go.
Some years ago I created a CSS naming methodology (mostly for my own) but maybe you can use some things?
Your github source is really useful, thank you very much.
Very cool! Thanks, Kevin. :)
Here’s what I’ve come up with in terms of breakpoint naming conventions below. Sizes are mobile first, i.e. zero and up. Each bp is a range where the most popular device size usually sits about in the middle so we’re grouping similar devices by bp groups:
mobile: 0px // Mobile first, i.e. zero and up
tablet-v: 600px // target 768
tablet-h: 900px // target 1024
laptop: 1200px // target 1366
desktop: 1600px // target 1920 and greater
Hopefully anyone using this code should find it pretty self-explanatory.