This will be horribly slow for DOM-heavy projects.
AM – Attribute Modules for CSS
31–40 of 58 posts
Re: AM – Attribute Modules for CSS
#32Looks 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 means scattered into multiple locations.
Re: AM – Attribute Modules for CSS
#33Why should "rounded" and "large" be classes?
Isn't
...
.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, ..., no needed.
Re: AM – Attribute Modules for CSS
#34What'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 a slightly OCD designer wanting to write pretty markup, which is, in my opinion, probably the last thing you should be optimizing for productivity.
Re: AM – Attribute Modules for CSS
#35Re: AM – Attribute Modules for CSS
#36Earlier quoted context omitted.
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 you have - two namespaces instead of one.
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?
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.
Re: AM – Attribute Modules for CSS
#37Why 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…
Yeah I'll second this. You can also use the @extend directive to make selector definitions inheritable (kinda), in the case where 'rounded' and 'large' do have to be classes.
.buy {
@extend .large;
@extend .rounded;
}
Re: AM – Attribute Modules for CSS
#38This 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.
I'm not sure, but from the post it's actually ~=.
The =~ variant is used in Perl and Bash as a regex matching operator.
Re: AM – Attribute Modules for CSS
#39You may prefer the regular "data-" prefix ( https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Usin... ) to "am-", especially if you want to be compatible with React.
You can definitely do this, though I think "data-am-" is better to avoid conflicts. React ignores unexpected attributes at the moment, but can't forever with Custom Elements (since it can't know what valid attributes for new elements are). We've got an open discussion on this point, if you want to contribute there: https://github.com/amcss/attribute-module-specification/issu...
I wouldn't completely assume react is going to give on that. In React you can create any custom properties you want to because it's just JS. The problem is how to interop with Web Components and from what I've seen nobody is really interested (rightfully so) in that
Re: AM – Attribute Modules for CSS
#40I really like this approach, but I think the thing that is currently missing is preprocessor/build support. The primary use case for this would be large-scale web applications -- it's probably overkill for anything else. Unfortunately, for large apps, the performance hit of using ~= is unacceptable. However, most large apps use some kind of build system - grunt, gulp, make, etc, and writing a task to convert these into old-fashioned CSS class names as part of the build seems entirely doable.