Live data from Hacker News

AM – Attribute Modules for CSS

glenmaddern.com

41–50 of 58 posts

Re: AM – Attribute Modules for CSS

#41
post #23

What's the problem with `class="btn large rounded"` and then in css: .btn {} .btn.large {} .btn.rounded {} .btn.large.rounded {}

I've heard people complain about this approach because if you tried to refactor, someone could have written class = "large rounded btn" in one place and "btn rounded large" in another, making finding all the variations more cumbersome. That doesn't mean it's a bad approach, but that is one concern I've heard about it.

Not sure what you mean - order of classes don't have any effect with regular css .class selectors.

http://jsfiddle.net/n1a9Lew5/

Edit: Oh never mind, I now realize that you're saying it's harder to find markup that uses a specific combination of classes. That's probably true, sorry.

Re: AM – Attribute Modules for CSS

#43
post #33

Why should "rounded" and "large" be classes? Isn't ... plus a bit of SASS .buy { @include big; @include rounded; } enough and more correct? If you embed "big" in the HTML, how do you go from mobile to desktop? Maybe that button should be "big" on desktop, but only slightly bigger than normal on mobile. If you specify its _role_ rather than its presentation, it becomes very easy to override the style in CSS with @medi…

In my experience the lower level classes increase flexibility, maintainability, and sanity of your css. It's what allows bootstrap to be such a powerful tool for so many products.

Using a conceptually high-level naming scheme won't scale very well as your team and site grows. Eventually someone will say, I need a large rounded button, I can use the .buy class for this contact form. Or perhaps your team is very disciplined but ends up with 10-15 different ways of specifying large rounded buttons.

You'll potentially end up where .buy makes sense in two different contexts which will then increase the complexity of your css:

button.buy {...} h1.buy {...}

Having .button .button-rounded .button-large helps you keep your css simple allows it to be remixed and reused in ways you haven't planned for yet.

Not to say semantic classes are wrong, I like them, but I have yet to see a system for it that doesn't break down after a certain size for a project/team.

Re: AM – Attribute Modules for CSS

#45
post #34
post #23

What's the problem with `class="btn large rounded"` and then in css: .btn {} .btn.large {} .btn.rounded {} .btn.large.rounded {}

There's nothing technically wrong with this, but one could make the argument that once a project expands beyond a single developer, you have a greater chance of namespace collisions with vague class names like `.large`. Eventually someone will come along and make a `.large` class for headlines that will make your buttons have 36pt labels. Edit: I have a suspicion that most attempts at "semantic" CSS are a symptom of…

Except here .large doesn't exist on it's own, it's only used inside the .btn selector.

the .large class for headlines would similarly only be used inside the .h1 selector.

So there would be no collision in this case.

Re: AM – Attribute Modules for CSS

#46
post #33

Why should "rounded" and "large" be classes? Isn't ... plus a bit of SASS .buy { @include big; @include rounded; } enough and more correct? If you embed "big" in the HTML, how do you go from mobile to desktop? Maybe that button should be "big" on desktop, but only slightly bigger than normal on mobile. If you specify its _role_ rather than its presentation, it becomes very easy to override the style in CSS with @medi…

In my experience the lower level classes increase flexibility, maintainability, and sanity of your css. It's what allows bootstrap to be such a powerful tool for so many products. Using a conceptually high-level naming scheme won't scale very well as your team and site grows. Eventually someone will say, I need a large rounded button, I can use the .buy class for this contact form. Or perhaps your team is very discip…

I've started combining both approaches, with help from SASS's '@extend' directive.

What I mean is, I have a section of my CSS for defining all of those simple, modular classes like 'button' and 'button-rounded' (I start with bootstrap for most of these and then add more as I need them), with the idea that I'll reuse these over and over.

BUT, these never get used in the HTML directly. Instead, I have a second section of my CSS which contains definitions for those high-level, one-time-use rules. So, for instance:

  // Low-level CSS (don't nest anything or it breaks @extend)
  .button { // basic button... }
  .button-large { // large button... }
  .button-rounded { // rounded button }
  .button-primary { // blue button }
  .button-warning { // red button }

  // High-level CSS (avoid nesting, but sometimes it is okay)
  #buy_page .buy_button {
    @extend .button;
    @extend .button-large;
    @extend .button-primary;
  }
  #settings_page .deactivate_button {
    @extend .button;
    @extend .button-rounded;
    @extend .button-warning;
  }
The big rule for the HTML is that I can only use IDs and classes from the high-level CSS, and should really only have one class/id per element. For the most part the high-level selectors are 1:1 with the markup, but things like widgets/components it's okay to reuse them on multiple pages.

The major exception here is the CSS for actually laying out pages. I don't use a class-based grid system. Instead, I map tags to rows and // tags to columns. The grid behavior is defined using Susy[1], and for specific pages I can modify the standard layout pattern if necessary.

The result of all of this is CSS that is easy to navigate. The low-level CSS is highly reusable, and the high-level CSS is structurally similar to page content, yet keeps the presentation information entirely out of the HTML. It also sometimes results in very long selectors, but that's actually not an issue performance-wise and has yet to cause me any issues.

[1]: http://susy.oddbird.net/

Re: AM – Attribute Modules for CSS

#47
post #45
post #34

Earlier quoted context omitted.

There's nothing technically wrong with this, but one could make the argument that once a project expands beyond a single developer, you have a greater chance of namespace collisions with vague class names like `.large`. Eventually someone will come along and make a `.large` class for headlines that will make your buttons have 36pt labels. Edit: I have a suspicion that most attempts at "semantic" CSS are a symptom of…

Except here .large doesn't exist on it's own, it's only used inside the .btn selector. the .large class for headlines would similarly only be used inside the .h1 selector. So there would be no collision in this case.

You can't guarantee that someone won't add a 'top-level' class name in the future that matches one of your 'modifier' class names. It's essentially the same argument as saying that global variables are OK because no one will ever have a global variable with the same name as yours.

Re: AM – Attribute Modules for CSS

#48
post #2

This looks a promising approach to the chaos that is writing reusable and maintainable CSS. I wonder about performance though, especially on mobile. Will this perform as good as regular class-written CSS, even if you have >2000 loc CSS files?

Attribute selectors have the worst performance of any selector. Coupling that with the =~ operator is even more cause for concern. This is why classes and id exist.

No, :nth-last-child(n) has the worst performance of any selector.

Re: AM – Attribute Modules for CSS

#50

Earlier quoted context omitted.

Attribute selectors have the worst performance of any selector. Coupling that with the =~ operator is even more cause for concern. This is why classes and id exist.

No, :nth-last-child(n) has the worst performance of any selector.

span:nth-last-of-type(2n+1):not(div) > span ?

Edit: I reversed my edits to maintain proper history.

Post reply on HN