Nomenclature

[geelen]

So here's what I'm thinking so far:

• Modules: BEM-style, independent, (usually) app-specific but reusable.
• Traits: Global, reusable, framework-level stuff. E.g. grids, typography. Equivalent to Suit's utils, maybe.

Worth making that distinction? Can you think of more?

[benschwarz]

I'm not sure that it is worth making the distinction… ? To what ends? How would they be different in terms of 3rd party code vs non?

… I think they're all either "modules" or "components"

[geelen]

In my code, I've been doing things like ui-flex and ui-type vs ui-Markdown and ui-LoginForm. So the capitalization is different, but also it feels like some things (like the grid) exist pretty separately to the components you're working with.

[benschwarz]

Perhaps thats why library / 3rd-party code should use the am- prefix, and we suggest that for your own components, you choose your own prefix?

[geelen]

Yeah that's a nice idea. But I still think there's something in the module/trait distinction. I'm going to have a hunt for some other people doing the same thing to see how they explain it.

On 16 August 2014 16:40, Ben Schwarz notifications@github.com wrote:

Perhaps thats why library / 3rd-party code should use the am- prefix, and we suggest that for your own components, you choose your own prefix?

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/2#issuecomment-52385661 .

[geelen]

Actually, just had a thought about this distinction.

Traits: a collection of rules that can be mixed-and-matched. Each rule tends to have only one CSS property, and no styles targeting the attribute alone. For example:

[am-type~="italic"] { font-style: italic; }
[am-type~="centered"] { text-align: center; }
[am-type~="upcase"] { text-transform: uppercase; }

A module presents a higher-level component, and should reuse traits wherever appropriate. Usually will provide the bulk of the styling on the attribute itself:

[am-Button] {
  @extend [am-type~="centered"];
  @extend [am-type~="upcase"];

  background-color: $primary;
  border: darken($primary, 20%);
}
[am-Button~="disabled"] {
  background-color: $grey;
  border: darken($primary, 20%);
}

[bensmithett]

Should "use traits or modules on an element, but not both" be a rule? Otherwise source order starts mattering

// Different results depending on which of these you specify first
[am-type~="downcase"] { text-transform: lowercase; }
[am-type~="upcase"] { text-transform: uppercase; }

[am-Button] {
  @extend [am-type~="upcase"];
  foo: bar;
}

<a am-Button am-type="downcase">

[benschwarz]

Its not really different than doing it with classes @bensmithett, so I'm not really convinced its a real issue

[bensmithett]

@benschwarz true, but we have conventions with classes now to avoid being at the mercy of whatever order things were specified in:

:x: <a class="button downcase"> :+1: <a class="btn btn--downcase"> :+1: <a class="btn u-downcase">

SUIT gets around it like so:

Utilities make use of !important to ensure that their styles always apply ahead of those defined in a component's dedicated CSS.

If amcss traits are analogous to SUIT utils, should they always apply ahead of those specified in a module/component? And how does that even work if modules @extend traits?

[benschwarz]

SUIT gets around it like so:

I didn't really realise that it was doing that(!)… I don't use it, I just dig the methodology more than anything else.

And how does that even work if modules @extend traits?

@extend & SASS is for dorks I don't think am-css should demonstrate any pre-processor in usage whatsoever.

---

All the same, I'm not sure what you're advocating for here. I don't perceive there to be a problem.

[geelen]

Good catch. I don't think we should use !important anywhere, and someone's bound to hit this issue.

The thing, in your example - you have a Module/Component which includes a trait, then you're using the same trait in your markup, you've got a clash. It's the same as doing <a am-type="upcase downcase">, so yes source order becomes important.

I often will add a trait, like spacing, to a module element, e.g: <div am-TabBar am-layout='mt1'>, which is fine because the TabBar module shouldn't be concerned with its positioning. So it's not right to say you can't have both, but if you're trying to use a module then override a property, you've made a new variant on that module. So:

[am-Button] {
  @extend [am-type~="upcase"];
  foo: bar;
}
[am-Button~="secondary"] {
  @extend [am-type~="downcase"];
}

That way you're encouraged to find a new, semantic name for your variant, which also helps you keep a lid on (or at least an eye on) the number of variants you're introducing.

Also :+1: to not showing any SCSS examples in AMCSS. Though you're bound to hit this problem as soon as you have Modules & Traits with overlapping concerns. The way I see it - traits are more OOCSS and Modules are more BEM, so I think a lot of people wil tend towards one or the other, which is totes fine.

[benschwarz]

You've defined traits as one liners, almost more for convenience than anything else. They're sugar, more or less.

I don't see modules/traits as 'one or the other', I think its a matter of more modules, with traits thrown in to make life easier.

For westfield, we called these kinds of things 'abstractions', which is also an offshoot from Harry's work on inuit.

[geelen]

Yeah except then you can use the traits right there in your markup, which makes them more useful than SASS-level helpers/variables, imo. I was mainly saying people will lean more on one or the other, not that they're exclusive. But I do think there's a distinction there and Modules/Traits are decent names to capture them, so that's good.

On 24 August 2014 14:16, Ben Schwarz notifications@github.com wrote:

You've defined traits as one liners, almost more for convenience than anything else. They're sugar, more or less.

I don't see modules/traits as 'one or the other', I think its a matter of more modules, with traits thrown in to make life easier.

For westfield, we called these kinds of things 'abstractions', which is also an offshoot from Harry's work on inuit.

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/2#issuecomment-53177436 .

[benschwarz]

I personally prefer to have the 'traits' outlined in the markup, rather than somewhere hidden inside a component or a magical selector. We were taught for so many years to not do this, but its the most maintainable, fast to develop and easy to mess around in the debugger with.

[benschwarz]

We can call this issue done—

[geelen]

have the 'traits' outlined in the markup, rather than somewhere hidden inside a component or a magical selector

Not sure what you mean?

[benschwarz]

have the 'traits' outlined in the markup, rather than somewhere hidden inside a component or a magical selector

Not sure what you mean?

I think using @extend is most-generally poor practice. I'd rather have the traits visible in markup.

[bensmithett]

I don't think am-css should demonstrate any pre-processor in usage whatsoever.

:+1:

So it's not right to say you can't have both, but if you're trying to use a module then override a property, you've made a new variant on that module.

:+1:

Re: this actual issue, I think the Modules/Traits distinction is valuable. At some point you're going to want to bundle

<button am-layout="p1 mr1" am-background="blue" am-color="white">

up into

<button am-Button>

(whether you hand code [am-Button]'s properties or pull shared stuff in with Sass doesn't really matter)

Mixing the two still feels error-prone, but I'll experiment some more & open another issue if anything pans out.

[geelen]

Sounds good to me.