Class naming style

[i-like-robots]

Discussions for class naming style in one tidy thread...

Should classes be .camelCase or .hyphen-separated?

Do we need a prefix?

[enjikaka]

I lay my vote on hyphen separated.

[kshmir]

I lay also my vote on hyphens

[jkneb]

hyphens

[AaronLayton]

I would say hyphenated as this follows everything else H5BP

As for prefixed, that depends on if we ever want people to swap out the CSS lib for another one (like jQuery and Zepto)

[paulirish]

I think we'll do hyphen. It's BEM style and follows the community direction on style isolation.

as this follows everything else H5BP

This project is just under H5BP for now for logistical reasons. I'm fine with moving it.

[paulirish]

From @chriscoyier

Should we use a prefix like "eff-"?

Works for now.

Should each effect have a standard class?

Definitely.

How to handle variations on that class? Maybe like class="modal" data-modal-style="from-top" ?

Good question..

[chriscoyier]

My votes:

• hyphens
• The classes in the demo (and raw CSS output) should be prefixed like "effeckt-" - but in reality doesn't matter since you'll use your own classes with @mixin
• Class name "light", each effect has a single class, and variations handled with data-* attributes.

[jkneb]

What about "fx-" ? :)

[sindresorhus]

Hyphens

[i-like-robots]

• I'm also going for hyphens.
• an fx- prefix sounds good to me.

[KittyGiraudel]

Definitely hyphens.

How to handle variations on that class?

BEM-style?

[mente]

• hyphens
• fx-

[grayghostvisuals]

Hyphens FTW with a prefix just in case we don't override other stuff. Also lowercase E please cuz that's how I roll. Hollah!

.effeckt-[animation-name]

I also rly like this as well in order to handle variations :facepunch: :man:

class="modal" data-modal-style="from-top"

[bensmithett]

+100 for hyphens & BEM

fx-modal--is-active, fx-modal__overlay etc.

If we're going the BEM route I'm in favour of keeping modifiers in class names instead of needing extra data attributes.

.fx-modal--from-top is cleaner & avoids unnecessary specificity woes.

[jbeja]

1+ hyphens and BEM style, similar the one that Inuit.css use in it classes e.x: .navigation{ @extend .nav; //this is the main class for navigations @extend .nav--stacked; // this is an modifier class that alter the .nav class } I absolutely love this.

[darsain]

How realistic would it be to use CSS3 animations, and leave classes out of the question altogether?

You'd define an animation as keyframes:

@keyframes scalein {
  from {
    transform: scale(5);
  }

  to {
    transform: scale(1);
  }
}

And than leave it on the end developer to which classes should this animation be applied to:

.modal {
  animation-name: scalein;
  animation-duration: 500ms;
}

This would give people a comfy control via animation-* properties, like duration, delay, direction, ...

Also this is a lot better way how to declare animations in your styles than just another spam of non-semantic classes. Seems like an ideal solution for a modern web.

A small issue is that CSS3 animations are not supported in IE9, but as "not having animations" doesn't break anything, I don't personally care about that.

You could still create a class proxies for these animations to be used in a possible JS library. Unless there is a native API that would allow us to trigger keyframe animations on elements directly with JS that I don't know about. Yeah, that would be just too nice to have I guess :)

[paulirish]

I don't want to expose end users to the timing functions if we don't have to. Exposing things as just classes gives us a lot more flexibility in case we need to do some layer promotion (translateZ) or have other adjustments.

[AaronLayton]

Also by having the class named defaults we get to set the optimal times for jank-free animations. With the proposed custom builds they will be able to change this anyway?

[grayghostvisuals]

@Darsain That's a really great thought about just providing the keyframes and their corresponding animation name. Total modularity heaven. I think there's a bit more flexibility with classes though.

[jbeja]

@Darsain I really like the idea, modularity is key, hower i could be wrong, but i don't get to see and interface where the end-user could customize the key-frames properties values in your example.

[mnording]

My 2 cents is doing this hyphen-separated according to the community. +1 on the -fx prefix

[tyom]

In terms of prefixes/modifiers. Is it worth considering using variables and class placeholders in Sass to set defaults and allow easy configuration to suit individual needs? For example:

SCSS

// Definitions
%xxx-test {
  border: 2px solid green;
}
%xxx-test-small {
  width: 10%; 
}
%xxx-test-active {
  background: yellow;
}

// BEM
$prefix: "fx-";
$modifier: "--";
$state: "__";

.#{$prefix}bem {
  @extend %xxx-test;
}
.#{$prefix}bem#{$state}active {
  @extend %xxx-test;
  @extend %xxx-test-active;
}
.#{$prefix}bem#{$modifier}small {
  @extend %xxx-test;
  @extend %xxx-test-small;
}
.#{$prefix}bem#{$modifier}small#{$state}active {
  @extend %xxx-test;
  @extend %xxx-test-small;
  @extend %xxx-test-active;
}

// COS
$prefix: "fx-";
$modifier: ".m-";
$state: ".s-";

.#{$prefix}cos {
  @extend %xxx-test;
}
.#{$prefix}cos#{$modifier}small {
  @extend %xxx-test-small;
}
.#{$prefix}cos#{$state}active {
  @extend %xxx-test-active;
}

HTML

<div class="fx-bem--small__active">
  BEM style
</div>

<div class="fx-cos m-small s-active">
  COS style
</div>

I think this would make it more configurable for individual styles. Personally I prefer the COS style (which I'm currently developing and planning to write about).

Just a thought. Have a play on CodePen. Try changing the variables at the tops as per the example above.

[grayghostvisuals]

Use hyphen separated selector names and the prefix below for the time being. Honestly it could be renamed so right now this is good to go with.

.effeckt-[whatever]

Looks like this thread is going beyond the original intention which was prefix name and/or hyphens in selectors.