Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AM – Attribute Modules for CSS

glenmaddern.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: AM – Attribute Modules for CSS

#52

Post by ratbeard »

bGriz wrote: post #50
ratbeard wrote: post #48

Earlier quoted context omitted.

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.

Actually, I spoke to soon. Since selector engines work right to left, this would first narrow down the list of elements to all the spans in the document. Assuming thats a fairly small percentage of the overall tags in the document, this selector runs at .0023 ms on my MBP w/ 8 GB or RAM.

Sa'll good.

Edit: For the record, bGriz edited his comment, making my comment invalid.

Edit (2): Thanks!

Re: AM – Attribute Modules for CSS

#53

Post by bGriz »

ratbeard wrote: post #52
bGriz wrote: post #50

Earlier quoted context omitted.

span:nth-last-of-type(2n+1):not(div) > span ? Edit: I reversed my edits to maintain proper history.

Actually, I spoke to soon. Since selector engines work right to left, this would first narrow down the list of elements to all the spans in the document. Assuming thats a fairly small percentage of the overall tags in the document, this selector runs at .0023 ms on my MBP w/ 8 GB or RAM. Sa'll good. Edit: For the record, bGriz edited his comment, making my comment invalid. Edit (2): Thanks!

Definitely fact.

Re: AM – Attribute Modules for CSS

#54

Post by EdSharkey »

amccloud wrote: post #44

What is the performance of an attribute selector?

These selectors are evaluated globally, checked against to EVERY NODE in the DOM. You might as well write

  *[am-Button]
just to hammer home to the reader that performance is going to be a problem with this selector approach on any complex DOM.

If I recall, CSS performance can roughly be gauged by the key selector (right most thingy on the selector) like this:

  * inline styles = fastest (ok, this doesn't have a selector, but it evaluates fast!)
  * id = fastest-ish
  * class = fast
  * tagname = slower
  * any/everything else evaluated like global = super slowest

Re: AM – Attribute Modules for CSS

#55

Post by shadowmint »

grumblestumble wrote: post #32
shadowmint wrote: post #20

Looks like tal:attributes to me. That was a terrible idea before, and its a terrible idea now. Honestly, what problem is this actually solving ? You have .foo, .foo--bar, .foo--extra, and you're concerned the style tags are what... not pretty enough? Too hard to visually parse? Too complex when you're building a large css framework? I really don't understand the problem. ...but having worked with tal, I can hands dow…

This is a terrible misinterpretation of the article. It's not even tangentially related to hard-coding styles into HTML. Attribute models retain the ability to abstract style away from the HTML. Take the example used in the article, am-Button. Using the AM approach, you retain the ability to update the font-color, size, base styling in one place in a separate block of code (css, scss, whatevs). The styles are by no m…

Certainly having a custom attribute that bundles multiple styles is novel.

...but having single attributes for color, font size and base styling is what attribute styles in early html were.

I think its disingenuous to suggest this is fundamentally different because these are custom style attributes (am-font) instead of hard coded style attributes (color).

The point is that presentation and data should be distinct in markup, and this use of custom attributes muddles things.

I can easily imagine some css framework providing css attribute classes that get used just like the old html style attributes, with all the same markup clutter and maintenance issues.

oh, want to change a style? now you have to change the markup attribute instead of the style sheet Markup should be tagged with meaning attributes (btn--buy) and the styling done via stylesheets.

Re: AM – Attribute Modules for CSS

#56

Post by [deleted] »

masklinn wrote: post #28
shadowmint wrote: post #22

Earlier quoted context omitted.

So its to avoid human readable visual clutter? ...by having obscure custom attributes? That seems extremely close to having size="big" and color="red" from html4. How is this not just going back to a known bad design pattern?

Not to be insulting but… are you unable to read text? Because the problem (which has nothing to do with visual clutter and has to do with modularity and contextual overrides) is explained from the third section "Contextual overrides".

[deleted]

Re: AM – Attribute Modules for CSS

#57

Post by lobster_johnson »

jdcantrell wrote: post #43
gioele wrote: 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…

If all classes are basically strictly scoped, encapsulated components, targeted in the CSS via parent chains, then you won't have this problem, and you won't fall into the trap you describe.

For example, rather than having .buy, it would be named something like .NavigationBar_buy (ie., following a ComponentName_child naming convention) and it would be declared in NavigationBar.scss and look like something like:

    .NavigationBar > .NavigationBar_buy {
      @include button(large, red);
      margin-left: 15px;
    }
The really nice thing about the mixin approach is that you will be able to trace all usage. After all, a huge problem with CSS is class rot (where you don't know which classes are actually being used by the app) and class leakage (where classes are used for unrelated things in surprising ways that break if you modify it not knowing about the potential side-effects). Whereas in a component/mixin system, the dependencies are crystal clear: if a mixin isn't used in the stylesheet, you know it's not used by the page, and similarly, you know exactly which classes map to which components. You may get some rot, but zero leakage, and the rot is carefully contained. The only downside is increased HTML/CSS size.

Class-based CSS doesn't scale to large teams, in my opinion. A strictly enforced design manual might do it, but I don't think most companies can work that way.

Re: AM – Attribute Modules for CSS

#58

Post by acjohnson55 »

I've gone full BEM on a recent project of mine, and it's been a godsend. Name our block elements by function, take advantage of SASS's abbreviated BEM syntax, reuse actual presentation styles with mixins, and use helpers within our templates to vastly minimize BEM's noisiness in the markup we work with. The modifiers are also great for capturing variations.

AM strikes me as clever, but I can't see it replacing class-based styling. At best, with some extensions, it might be a slightly more abbreviated way to write BEM, but decent tooling can do that for you anyway.

Post reply on HN