There once was a wise witch who coded the perfect css file. While others, no matter how hard they tried, only spun spaghetti code with 5000 lines of css ignoring any understanding of cascade and specificity, which made them embrace utility based styling as the lesser evil, chasing the devil with Beelzebub.
In real life, hopefully nobody would hand-code repetetive class name combinations in hundreds of lines of markup. As we all know, people don't write HTML. They either write component-based single page applications or use a low code tool like webflow or Gutenberg block editor.
But let's suppose someone did. It was tedious and error-prone, but they did use proper tooling that warned when misspelling class names.
Why use regex to edit when there are transformation tools? In a descriptive language like XSLT, the editing can be done correctly and quickly (they would pay me 1 hour, but at a ridiculously high hourly rate, as knowing how to use XSLT knowledge will be arcane wizardry like COBOL). Of course, I would have to normalize their inconsistent markup first, using an html parser, as XSL needs a well formed DOM to work on. That might introduce some new, hard to find errors, so I can charge some more hours for bugfixing later.
But back in real life, the original developers had some build tool chain anyway, for postcss and purgecss, so they will probably also have used component code for a static content management or site generator like gatsby or eleventy, so we would be able to change one line in a source code component instead of many lines in the emitted code.
Also in real life, we would have avoided repetetive class names by defining our own components, and probably defined some global critical css inline in our document head once. So even without an html content generator there should be some compound classes like .chapter { @apply .p-2 } where you changed the padding only once, once again.
So, like you concluded at the end of the fairy tale, class names are not bad in general, but misuse of tools can pile up technical debt quite quickly!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There once was a wise witch who coded the perfect css file. While others, no matter how hard they tried, only spun spaghetti code with 5000 lines of css ignoring any understanding of cascade and specificity, which made them embrace utility based styling as the lesser evil, chasing the devil with Beelzebub.
In real life, hopefully nobody would hand-code repetetive class name combinations in hundreds of lines of markup. As we all know, people don't write HTML. They either write component-based single page applications or use a low code tool like webflow or Gutenberg block editor.
But let's suppose someone did. It was tedious and error-prone, but they did use proper tooling that warned when misspelling class names.
Why use regex to edit when there are transformation tools? In a descriptive language like XSLT, the editing can be done correctly and quickly (they would pay me 1 hour, but at a ridiculously high hourly rate, as knowing how to use XSLT knowledge will be arcane wizardry like COBOL). Of course, I would have to normalize their inconsistent markup first, using an html parser, as XSL needs a well formed DOM to work on. That might introduce some new, hard to find errors, so I can charge some more hours for bugfixing later.
But back in real life, the original developers had some build tool chain anyway, for postcss and purgecss, so they will probably also have used component code for a static content management or site generator like gatsby or eleventy, so we would be able to change one line in a source code component instead of many lines in the emitted code.
Also in real life, we would have avoided repetetive class names by defining our own components, and probably defined some global critical css inline in our document head once. So even without an html content generator there should be some compound classes like
.chapter { @apply .p-2 }where you changed the padding only once, once again.So, like you concluded at the end of the fairy tale, class names are not bad in general, but misuse of tools can pile up technical debt quite quickly!