{ "uuid": [ { "value": "400a0b92-7c40-43b0-883d-5f199fb5471f" } ], "langcode": [ { "value": "en" } ], "type": [ { "target_id": "daily_email", "target_type": "node_type", "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7" } ], "revision_timestamp": [ { "value": "2025-05-11T09:00:10+00:00" } ], "revision_uid": [ { "target_type": "user", "target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849" } ], "revision_log": [], "status": [ { "value": true } ], "uid": [ { "target_type": "user", "target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849" } ], "title": [ { "value": "Back to Sass and traditional CSS" } ], "created": [ { "value": "2024-07-08T00:00:00+00:00" } ], "changed": [ { "value": "2025-05-11T09:00:10+00:00" } ], "promote": [ { "value": false } ], "sticky": [ { "value": false } ], "default_langcode": [ { "value": true } ], "revision_translation_affected": [ { "value": true } ], "path": [ { "alias": "\/daily\/2024\/07\/08\/back-to-sass-and-traditional-css", "langcode": "en" } ], "body": [ { "value": "\n

I'm currently working on a project that doesn't use any atomic or utility-first CSS.<\/p>\n\n

It uses Sass, which I haven't used for some time, but it has reminded me of some of the reasons I like the utility-first approach to CSS.<\/p>\n\n

Specificity and cascading<\/h2>\n\n

With utility styles, there are no specificity or cascading issues as styles are added to each element and provide a local scope.<\/p>\n\n

With global styles, your element can be overridden or altered by another part of CSS elsewhere in the stylesheet.<\/p>\n\n

I've also had situations where I've had to \"undo\" unwanted styling that was added elsewhere, such as on a hover or focus state.<\/p>\n\n

Easier to read and understand<\/h2>\n\n

With utility styles, I can read the classes on an element and understand straight away what styles are applied to it and start to make changes - especially when using a framework, such as Tailwind CSS.<\/p>\n\n

With generic class names or IDs, I'm not able to do that.<\/p>\n\n

Context switching<\/h2>\n\n

To make changes to an element, once I've found it in the HTML, I then need to find the stylesheet (or stylesheets) that add the styling and switch between the HTML and CSS files as many times as needed.<\/p>\n\n

Usually with utility styles, I rarely need to edit the stylesheet and can work almost exclusively in the HTML and not need to switch between files.<\/p>\n\n

Concatination and nesting<\/h2>\n\n

Something I've avoided with Sass<\/a>, as well as newer versions of CSS, is the over-use of nesting styles, which makes it harder to find them when searching for the correct stylesheet.<\/p>\n\n

If there was this CSS:<\/p>\n\n

.sidebar {\n  &-wrapper {\n    a {\n      &:hover,\n      &:focus {\n      }\n    }\n  }\n}\n<\/code><\/pre>\n\n

If I tried searching for .sidebar-wrapper<\/code> or .sidebar-wrapper a:hover<\/code>, they wouldn't be found and it would take me longer to find it.<\/p>\n\n

Here's the thing<\/h2>\n\n

It's taken me a while to get back into this way of working with CSS, but it does remind me why I prefer to use utility styles<\/a> for my own projects.<\/p>\n\n ", "format": "full_html", "processed": "\n

I'm currently working on a project that doesn't use any atomic or utility-first CSS.<\/p>\n\n

It uses Sass, which I haven't used for some time, but it has reminded me of some of the reasons I like the utility-first approach to CSS.<\/p>\n\n

Specificity and cascading<\/h2>\n\n

With utility styles, there are no specificity or cascading issues as styles are added to each element and provide a local scope.<\/p>\n\n

With global styles, your element can be overridden or altered by another part of CSS elsewhere in the stylesheet.<\/p>\n\n

I've also had situations where I've had to \"undo\" unwanted styling that was added elsewhere, such as on a hover or focus state.<\/p>\n\n

Easier to read and understand<\/h2>\n\n

With utility styles, I can read the classes on an element and understand straight away what styles are applied to it and start to make changes - especially when using a framework, such as Tailwind CSS.<\/p>\n\n

With generic class names or IDs, I'm not able to do that.<\/p>\n\n

Context switching<\/h2>\n\n

To make changes to an element, once I've found it in the HTML, I then need to find the stylesheet (or stylesheets) that add the styling and switch between the HTML and CSS files as many times as needed.<\/p>\n\n

Usually with utility styles, I rarely need to edit the stylesheet and can work almost exclusively in the HTML and not need to switch between files.<\/p>\n\n

Concatination and nesting<\/h2>\n\n

Something I've avoided with Sass<\/a>, as well as newer versions of CSS, is the over-use of nesting styles, which makes it harder to find them when searching for the correct stylesheet.<\/p>\n\n

If there was this CSS:<\/p>\n\n

.sidebar {\n  &-wrapper {\n    a {\n      &:hover,\n      &:focus {\n      }\n    }\n  }\n}\n<\/code><\/pre>\n\n

If I tried searching for .sidebar-wrapper<\/code> or .sidebar-wrapper a:hover<\/code>, they wouldn't be found and it would take me longer to find it.<\/p>\n\n

Here's the thing<\/h2>\n\n

It's taken me a while to get back into this way of working with CSS, but it does remind me why I prefer to use utility styles<\/a> for my own projects.<\/p>\n\n ", "summary": null } ] }