Post pobrano z: Naming Things is Only Getting Harder
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 grids 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 be 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. And is always said: 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 is 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.