Hacker News Reader

Comment by vladocar | Hacker News Reader

I know you are joking .. but there are some CSS Frameworks with really terrible names and naming logic. If you have better naming system let me know.

View on HN

This, or something similar, should be your guideline for naming things in CSS: https://en.bem.info

IMO a "modern CSS frameworks" should have 0 classnames and should not inject any CSS statement anywhere. They should only provide mixins for LESS/SCSS to be included by the user.

Wouldn't that be better described as a "LESS/SCSS" framework?

So, something like [Bourbon](https://www.bourbon.io/), which is a Sass framework like you describe.

Any CSS framework can be included as namespaced mixins in LESS.

The joke was that its a framework to do what is now natively supported. I would look into CSS grid.

That is the point that I'm failing to make. It is all about reusability not about the grid system. You can use one CSS layout system in multiple cases otherwise you need to define separate CSS logic for every different web layout.

I don't understand your reasoning.

In my opinion, classnames should say what the HTML element represents, and a stylesheet contains the definitions for styling and sizing.

Your HTML should not include information about the size of an element. Your HTML document should represent the content & structure of your document. Your stylesheet is then responsible for layout, design, color and dimensions.

It is all about semantics. See: https://maintainablecss.com/chapters/semantics/

By writing the column sizes in the HTML, you're effectively reinventing inline styles

I agree about the semantics. If you are building small web site or big web with the simple structure don't use CSS Framework.

Here is blog post about this (It is from 2008): http://www.vcarrer.com/2008/08/when-to-use-css-framework.htm...

There’s a problem with this approach, which I found out about the hard way.

Like you I thought I should keep my html “semantic”. The problem with this approach is that you end up tightly coupling the stylesheet and the html, because it requires you to recreate the html’s tag structure using contextual selectors.

Besides becoming very complex this means that every time you need to change the html you also need to change the css.

The other major downside is that all those mixins end up generating a ton of duplicate rules in the stylesheet.

Note that if you define everything using classes and then put those classes in the html you have none of these issues. The coupling is much more straightforward and the stylesheets can be much smaller. Besides that, contextual selectors are many times slower than a single classname.

The inline styles thing I can’t agree with, classes are much more DRY.

I found the methodologies outlined by Harry Roberts to change the ways I structure my css for the better. (www.csswizardry.com)

Reply on news.ycombinator.com