Using adjoining classes

[Arunan Skanthan]

Are there any cons to using adjoining classes besides no support in IE>=6?

<a class="button disabled">Button</a>

.button.disabled {

  color: #ccc;

}

vs

<a class="button button-disabled">Button</a>

.button .button-disabled {

  color: #ccc;

}

The HTML seems much nicer for adjoining classes, though admittedly the CSS seems a bit ugly.

But with SASS the CSS can be much nicer too ...

.button {

  &.disabled {

    color: #ccc;

  }

}

Any thoughts? Cue the flamewar :P

[Micky Hulse]

Hi,

<my-2-cents>

On Wed, Aug 14, 2013 at 11:14 PM, Arunan Skanthan
<arunan....@gmail.com> wrote:
> Are there any cons to using adjoining classes besides no support in IE>=6?

I usually refer to them as "chained classes". I think that's the
official term that most people recognize.

There's lots of info on the topic if you Google for "CSS chained classes".

Here's one article:

"The Two CSS Selector Bugs in IE6"
<http://www.paulirish.com/2008/the-two-css-selector-bugs-in-ie6/>

The take home point is:

"IE6, however, will only apply [the styles to] the last class
mentioned [in the chain]."

> <a class="button disabled">Button</a>
> .button.disabled {
> color: #ccc;
> }
>
> vs
>
> <a class="button button-disabled">Button</a>
> .button .button-disabled {
> color: #ccc;
> }
>
> The HTML seems much nicer for adjoining classes, though admittedly the CSS
> seems a bit ugly.
> But with SASS the CSS can be much nicer too ...
>
> .button {
> &.disabled {
> color: #ccc;
> }
> }

I suppose that your preprocessor example might be more useful if
you're planning on cramming more selectors inside `.button`, otherwise
I'd just write:

.button.disabled { ... }

... or:

.button.button-disabled { ... }

In terms of the naming convention of `.button-disabled` class, that's
probably best explained by the techniques outlined in SMACSS book:

"Scalable and Modular Architecture for CSS"
<http://smacss.com/>

Here's a quote:

> Related elements within a module use the base name as a prefix. On this site, code examples use `.exm` and the captions use `.exm-caption`. I can instantly look at the caption class and understand that it is related to the code examples and where I can find the styles for that. -- <http://smacss.com/book/categorizing>

This chapter is pretty relevant to your questions:

"Module Rules"
<http://smacss.com/book/type-module>

In fact, the whole book is a decent read. Definitely some interesting
concepts, techniques, and common sense are sprinkled throughout the
SMACSS pages.

Me personally? I think I prefer the SMACSS thinking in terms of "modules".

Here's a real world example as to why using verbose class/ID names can
be useful:

At my day job, I do a lot of work with unpredictable 3rd party sites,
and, 9 times out of 10, these companies rarely do anything to avoid
their styles potentially colliding with customer styles. I've learned
that it's best in these situation to use CSS "namespaces" and/or to
modularize my styles (example: `.ns_foo{}` & `.ns_foo-sub{}`). By
being more specific, there's way less of a chance that the 3rd party's
CSS will conflict with mine (and vice versa).

> Any thoughts? Cue the flamewar :P

No flame war here! :)

Here's how I see it:

1. Avoid chained classes if you're worried about IE6 (the last class
gets the styles, preceding classes in the chain are ignored).
2. `.button-disabled` is one of many techniques you can use to style
elements on a page. If you don't like the looks/length, don't use it.

</my-2-cents>

I feel bad, that really was off-topic for OOCSS group. For anyone
wanting to discuss CSS techniques in general, I highly recommend the
CSS-Discuss list:

<http://www.css-discuss.org/>

Anyway, good questions Arunan!

Cheers,
M

[Nicole Sullivan]

IMO, it adds specificity unnecessarily. If something is a .button-disabled you already know it is also a .button because the subclass extends the base class. You don't gain a lot by chaining and you make your specificity more complicated.

Nicole

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.

[Matthew Browne]

On 8/15/13 1:23 PM, Micky Hulse wrote:
> I feel bad, that really was off-topic for OOCSS group. For anyone
> wanting to discuss CSS techniques in general, I highly recommend the
> CSS-Discuss list: <http://www.css-discuss.org/> Anyway, good questions
> Arunan! Cheers, M

I think much of your post was relevant to OOCSS (at least indirectly),
and I found it informative. Thanks for sharing.

[Arunan Skanthan]

Thanks for the replies all.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented-css+unsub...@googlegroups.com.
To post to this group, send email to object-oriented-css@googlegroups.com.

Visit this group at http://groups.google.com/group/object-oriented-css.
For more options, visit https://groups.google.com/groups/opt_out.

--

Website: http://askalot.org
---
"Ariels in the sky. When you free small mind, you free your life..."

[Nicole Sullivan]

Nothing was off topic Mickey, thanks for sharing. We talk about anything style related here. :)

On Thu, Aug 15, 2013 at 8:24 PM, Micky Hulse <rgm...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-oriented...@googlegroups.com.
To post to this group, send email to object-or...@googlegroups.com.