[shadowmint]

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 down say I hate the custom attribute syntax; it scatters the style into multiple locations and makes it unclear what parts are data and what parts are presentation.

I thought we all agreed that:

    <font color="red"> Its 1998! Hi! </font>

Was a bad thing. (and that was fifteen years ago... lessons from the past or whatever...)

[grumblestumble]

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 means scattered into multiple locations.

[shadowmint]

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 <--- this is why multiple display classes (btn--big) and custom attributes are fundamentally an anti-pattern.

Markup should be tagged with meaning attributes (btn--buy) and the styling done via stylesheets.

[geelen]

Well, the problem with having foo and foo--bar but not both is that contextual overrides become a problem. Having both of them solves that but clutters things up.

This is a technique to better express your styling intent through markup. Instead of <div class="x x-y z"> you have <div x="y" z> - two namespaces instead of one.

[shadowmint]

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?

[lowboy]

It's trying to ease the problems surrounding contextual overrides.

Having color="red" and other inline styles is a bad design pattern, but AM only superficially resembles it in that it uses attributes. Whether you give an element the attribute of class="nav" or just am-nav, it's accomplishing the same thing: defining that it's a "nav" element for purposes of styling.

[masklinn]

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".