-
-
Save wrumsby/8908260 to your computer and use it in GitHub Desktop.
/* Base styles */ | |
body {} | |
p {} | |
/* .layout-{name} */ | |
.layout-sidebar {} | |
/* .{moduleName} */ | |
.modal {} | |
/* .{moduleName}--{subComponent} */ | |
.modal--header {} | |
/* .{moduleName} */ | |
.button {} | |
/* .{moduleName}-is-{stateName} */ | |
.button-is-disabled {} | |
/* .{moduleName}-{subModule} */ | |
.button-default {} | |
/* .{moduleName}-{subModule} */ | |
.button-primary {} |
And the notion of a submodule is the same as a modifier?
Yup, he basically mapped BEM to this:
B : moduleName
E : moduleName--subComponent
M : moduleName-subModule
It's less jarring.
Also it means I can go back to camel casing :) (I never got used to -'s in class names)
.someFoo--subFoo
I like this a lot, but I'm not quite sure what the difference is between a --subComponent
and -submodule
as far as structure is concerned. They both kind of seem the same to me depending the context.
In this variation, a submodule is a variation on a module. So .button
would be a module with .button-primary
being the submodule. I prefer the term "modifier". "Submodule" is a curious term to use as it implies a descendent relationship.
A subcomponent would be something like:
<div class="modal">
<!-- .modal--header is a subcomponent -->
<div class="modal--header">Modal</div>
<div class="modal--body">
...
</div>
<div class="modal--footer">
<!-- .btn-primary is a submodule -->
<a href="#" class="btn btn-primary">Save</a>
<a href="#" class="btn btn-cancel">Cancel</a>
</div>
</div>
More Transparent UI Code with Namespaces has some interesting ideas on adding namespace prefixes too.
So, comparing this to BEM:
BEM:
.module__submodule
SMACSS 2.0:
.module--submodule
BEM
.module--modifier
SMACSS 2.0:
.module-modifier
BEM
.module__submodule--modifier
SMACSS 2.0:
.module--submodule-modifier
The difference being submodules are denoted with a
-
instead of a__
and modifiers are-
instead of--
?And the notion of a submodule is the same as a modifier?