http://perpetual.education is a design/programming school. We like to be part of the discussion over here at Dev.to / We have time-slots for free conversations for career advice IRL : )
Yikes! "Cleaner" CSS but now the markup is horrendous. We tried B.E.M. on a few projects 5 years ago - and felt like it was really bad for everyone involved. It actively fights the Cascade... which is the best thing about CSS. It's like choosing not to use classes in OOP. 'Utility CSS' seems just as bad. We took a look at Tailwind, but just look at this markup: codepen.io/sheriffderek/pen/QWwyJmB - and that's not even with JS framework attributes and templating stuff. Under the hood, we're still adding little modular groups of rules - but we add them in the CSS instead of the HTML. What do you think about that style?
I don't think I'd use Tailwind on a plain HTML+CSS site.
It is great for components though. I use Vue in most projects nowadays, and Tailwind's utility classes are used only once in the components you make.
Want a card? Make a functional card component with all the classes needed to compose a card component. Then, just use that.
If you don't want to mess up the HTML, you can extract the component with @apply in the style section of the component and use that instead.
http://perpetual.education is a design/programming school. We like to be part of the discussion over here at Dev.to / We have time-slots for free conversations for career advice IRL : )
We're usually working with Ember or Vue or WordPress for larger sites - and everything is a component. We don't have any room for a new toolbox of classes to fiddle around with. We're pretty happy with our workflow, but - we always check things out and give them a spin. : ) It all just reminds us of the "pull-left" years. again... "Yikes!"
I think you bring up a great point in that BEM does actively go against the cascade. I think the main reason for this is that the cascade presents serious problems with CSS selector specificity.
Take this example, with a paragraph element inside a div:
In this example, what color with the example text appear? To know this, you would have to understand specific intricacies of how CSS specificity and styles are actually calculated, which can be really hard to understand and interpret while actually writing your stylesheets.
This is a problem with the cascade which can quickly make CSS extremely confusing for less-experienced developers. BEM fixes all of this by eliminating specificity altogether, and showing specificity in the actual element classnames.
Of course, as you mentioned, BEM does make for less clean markup, but for me, that is a sacrifice I was willing to make for cleaner stylesheets.
As for using Tailwind and other utility CSS frameworks, I haven't ever tried using utility CSS yet. I enjoy writing my own stylesheets myself, but I understand that utility CSS can be really useful for writing CSS quickly and effectively.
Using a modular CSS system with different files and folders is great in my opinion, and is another way to write cleaner CSS. For this, I would suggest looking into various conventions for folder structures and systems for splitting up your styles. I use SASS as a precompiler, and I personally use these guidelines for most of my sites.
http://perpetual.education is a design/programming school. We like to be part of the discussion over here at Dev.to / We have time-slots for free conversations for career advice IRL : )
I each their own! : ) We'll be sticking with the markup and CSS that is most easily read by humans. We liked where this was going: maintainablecss.com
In any language - you can write it in a way that makes it harder to use... but - we just figure - we'll write it in a way that's easy to use. That works for us.
In any language - you can write it in a way that makes it harder to use... but - we just figure - we'll write it in a way that's easy to use.
And that's really the fundamental point. I feel like BEM (as well as some other CSS methodologies) adds lots of overhead to handle a worst case scenario which should be easily avoidable. After more than 15 years of writing CSS for many different scenarios, I can safely say I never worked on a project that became unmanageable to the point of actually needing something as heavy-handed as BEM (and I was on a team that used BEM for a couple of years). It appears to me that many of the struggles people seem to have WRT the CSS cascade and/or inheritance are based on either a misunderstanding of those concepts or an unwillingness to just think a little bit more about what they're doing. I would never write CSS like the example above (div p, div > p:not(:hover), div.div), and I wouldn't approve a commit where a teammate wrote that (and I'd ensure my team understood what a bad idea it is to use super generic selectors... and class names which are also tag names).
I've worked on large projects where many engineers touched the code, and it doesn't take more than following some simple best practices (e.g., not creating rules with more than two selectors) and a simple code search (which I still did when using BEM) to see whether your new rule would break something else.
http://perpetual.education is a design/programming school. We like to be part of the discussion over here at Dev.to / We have time-slots for free conversations for career advice IRL : )
YES. Clearly - there is a gap in understanding on these fronts. We're happy to demonstrate any situation anyone can think up. Glad we're not alone in this. We only have 10 years under our belt - and still wonder if we're missing something - so, it's lovely to hear from someone with 15 years.
http://perpetual.education is a design/programming school. We like to be part of the discussion over here at Dev.to / We have time-slots for free conversations for career advice IRL : )
"In this example, what color with the example text appear? To know this, you would have to understand specific intricacies of how CSS specificity and styles are actually calculated,"
You should understand CSS specificity and how styles are calculated, not rely on a methodology that breaks the cascade because you don't.
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.
Yikes! "Cleaner" CSS but now the markup is horrendous. We tried B.E.M. on a few projects 5 years ago - and felt like it was really bad for everyone involved. It actively fights the Cascade... which is the best thing about CSS. It's like choosing not to use classes in OOP. 'Utility CSS' seems just as bad. We took a look at Tailwind, but just look at this markup: codepen.io/sheriffderek/pen/QWwyJmB - and that's not even with JS framework attributes and templating stuff. Under the hood, we're still adding little modular groups of rules - but we add them in the CSS instead of the HTML. What do you think about that style?
You can extract tailwind CSS components with @apply as can be read here
or watched in a screencast here. This would at least move the verbose classes out of the markup.
I don't think I'd use Tailwind on a plain HTML+CSS site.
It is great for components though. I use Vue in most projects nowadays, and Tailwind's utility classes are used only once in the components you make.
Want a card? Make a functional card component with all the classes needed to compose a card component. Then, just use that.
If you don't want to mess up the HTML, you can extract the component with @apply in the style section of the component and use that instead.
We're usually working with Ember or Vue or WordPress for larger sites - and everything is a component. We don't have any room for a new toolbox of classes to fiddle around with. We're pretty happy with our workflow, but - we always check things out and give them a spin. : ) It all just reminds us of the "pull-left" years. again... "Yikes!"
I think you bring up a great point in that BEM does actively go against the cascade. I think the main reason for this is that the cascade presents serious problems with CSS selector specificity.
Take this example, with a paragraph element inside a div:
In this example, what color with the example text appear? To know this, you would have to understand specific intricacies of how CSS specificity and styles are actually calculated, which can be really hard to understand and interpret while actually writing your stylesheets.
This is a problem with the cascade which can quickly make CSS extremely confusing for less-experienced developers. BEM fixes all of this by eliminating specificity altogether, and showing specificity in the actual element classnames.
Of course, as you mentioned, BEM does make for less clean markup, but for me, that is a sacrifice I was willing to make for cleaner stylesheets.
As for using Tailwind and other utility CSS frameworks, I haven't ever tried using utility CSS yet. I enjoy writing my own stylesheets myself, but I understand that utility CSS can be really useful for writing CSS quickly and effectively.
Using a modular CSS system with different files and folders is great in my opinion, and is another way to write cleaner CSS. For this, I would suggest looking into various conventions for folder structures and systems for splitting up your styles. I use SASS as a precompiler, and I personally use these guidelines for most of my sites.
Thanks so much for reading!
— Gabriel
I each their own! : ) We'll be sticking with the markup and CSS that is most easily read by humans. We liked where this was going: maintainablecss.com
In any language - you can write it in a way that makes it harder to use... but - we just figure - we'll write it in a way that's easy to use. That works for us.
And that's really the fundamental point. I feel like BEM (as well as some other CSS methodologies) adds lots of overhead to handle a worst case scenario which should be easily avoidable. After more than 15 years of writing CSS for many different scenarios, I can safely say I never worked on a project that became unmanageable to the point of actually needing something as heavy-handed as BEM (and I was on a team that used BEM for a couple of years). It appears to me that many of the struggles people seem to have WRT the CSS cascade and/or inheritance are based on either a misunderstanding of those concepts or an unwillingness to just think a little bit more about what they're doing. I would never write CSS like the example above (div p, div > p:not(:hover), div.div), and I wouldn't approve a commit where a teammate wrote that (and I'd ensure my team understood what a bad idea it is to use super generic selectors... and class names which are also tag names).
I've worked on large projects where many engineers touched the code, and it doesn't take more than following some simple best practices (e.g., not creating rules with more than two selectors) and a simple code search (which I still did when using BEM) to see whether your new rule would break something else.
So, indeed, to each their own.
YES. Clearly - there is a gap in understanding on these fronts. We're happy to demonstrate any situation anyone can think up. Glad we're not alone in this. We only have 10 years under our belt - and still wonder if we're missing something - so, it's lovely to hear from someone with 15 years.
PS - that code example - was more insane than we could ever come up with, so - the OP is clearly gifted in that manner.
"In this example, what color with the example text appear? To know this, you would have to understand specific intricacies of how CSS specificity and styles are actually calculated,"
You should understand CSS specificity and how styles are calculated, not rely on a methodology that breaks the cascade because you don't.