The =~ variant is used in Perl and Bash as a regex matching operator.
Technically nothing prevents browsers from inferring specific behaviors from the way a custom attribute is used, and dynamically generate shortcuts (e.g. key objects by attribute name, value or computed value), but I doubt any existing browser does so, so you get a "universal selector" behavior: every element of the DOM has to be scanned and processed to apply the rule.
And it's not exactly an easy problem, it's essentially equivalent to auto-generating (and tearing down, since elements, attributes and CSS rules can be added and removed on the fly) database indexes except you've got way less usage to rely on (for cost/benefit estimations), and way less usage time to recoup your investment.
Performance has improved a bit since this post but it's still relevant: http://perfectionkills.com/profiling-css-for-fun-and-profit-...
.btn {}
.btn.large {}
.btn.rounded {}
.btn.large.rounded {}Edit: I have a suspicion that most attempts at "semantic" CSS are a symptom of a slightly OCD designer wanting to write pretty markup, which is, in my opinion, probably the last thing you should be optimizing for productivity.
the .large class for headlines would similarly only be used inside the .h1 selector.
So there would be no collision in this case.
That doesn't mean it's a bad approach, but that is one concern I've heard about it.
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.
Isn't
<div class="button buy">...</div>
.buy {
@include big;
@include rounded;
}
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 @media selectors.
PS: BTW, <button class="buy">...</button>, no <div> needed.
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.
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 major exception here is the CSS for actually laying out pages. I don't use a class-based grid system. Instead, I map <section> tags to rows and <header>/<article>/<aside> 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.
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;
}
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.
.buy {
@extend .large;
@extend .rounded;
}
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>
...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.
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.
...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?
We've got an open discussion on this point, if you want to contribute there: https://github.com/amcss/attribute-module-specification/issu...
eg. 
Aside & max500px were then picked up the CSS using the images alt attribute as the selectors.
It was a terrible hack but it worked.
[foo] {
color: blue;
background-color: pink;
.bar .baz {
[qux~="ok"] {
color: red;
}
}
}
[foo] {
color: blue;
background-color: pink;
}
[foo] .bar .baz [qux~="ok"] {
color: red;
}
*[am-Button]
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 slowestAM 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.
On a side note, the name sounds funny in Turkish but I guess that's a minor concern.