Scope classes with css prefixes

[Arunan Skanthan]

http://www.markdotto.com/2012/02/16/scope-css-classes-with-prefixes/ 

I practically find that .btn .btn-alert seems a good alternative to .btn.alert (having used the latter style in a recent project and found that I had to create a different class name instead of .alert)

Any thoughts on this?

[Murray Nuttall]

I totally agree and with Marks approach. I think it's better to prefix extensions to keep them predictable.

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/NFClFalm3pYJ.
To post to this group, send email to object-or...@googlegroups.com.
To unsubscribe from this group, send email to object-oriented...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-oriented-css?hl=en.

[Rick Lowes]

Plus, if you need IE 6 compatibility (yes some people still do) it's the only way to go - you can't class chain in IE6

[xckpd7]

Why would you even use a use case like 'success'? Wouldn't a button class be more apt in this situation? 

Let's take another situation: Assume I have a button and I want an alert button, a success button, warning button, so on. They all share styles (border-radius, cross-browser stuff, what have you). Now I don't know about you, but maintaining a mini library (aka multiple selector) of all the buttons I have is a tad silly(e.g. .btn-success,.btn-alert,.button-warning { border-radius: 5px; }). 

What I do is throw default styles on a button class (.btn) and then you can namespace with stacked classes to keep class names simple and reduce possible conflicts within a very big system (.btn.green / .alert.green will never conflict if used properly.. this is a huge gain in terms of simplicity, readability, etc) and you avoid doing .btn-green / .alert-green... and that's not even taking into account how you're going to handle implementing DRY for that).

As far as the article goes, the base can stand for anything.... ideally in your CSS there is explanation on how to use the classes, what sort of markup is needed.

You can either choose to have a default or not (.... smart defaults anyone? This is OOCSS right? This is always what Nicole Sullivan has advocated) for instance if I just use .btn, maybe I make a certain style default, but maybe not. It depends on what works for your site... at my job we use both in different situations when it makes sense. If you don't choose to use a default, then the stacked class should always be used with another class. As far as reusing it with other modules... just build out a reusable class to do just that. If you find that you want to use .btn-success on some other sort of item other than a button, then it was an architecture problem in the first place.... rename it to something that makes sense, and make it reusable. 

Let's not forget that even though we use classes for reusability, when we make skins, the styling inside the skins are using descendant selectors... it's not like everything is ia global class that can be mixed-matched ad-infinitum. That would get very messy, very fast. It might make sense for the simply designed Twitter / Bootstrap, but many large sites would probably be better suited with the stacked classes in certain situations.

Rick, I think IE6 support is it's own separate thing that shouldn't be grouped in. If you're among the unfortunate that still have to support IE6, this obviously not might work well for you. If you don't however, I think it's perfectly fine to use stacked classes, just not in the way perpetrated in the example given.

[Murray Nuttall]

Can you give us an example of .btn.green and .alert.green "done properly". 

Unless you're in complete control of the entire project, until the end of its life, I can't see how you can avoid cross pollination of styles. I'm interested to see how you do it. 

Also OOCSS is supposed to be cross browser compatible, so there is value in taking ie6 into account when discussing  things like this. 

Regards, Murray

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/WH1nS6wIAs4J.

[xckpd7]

It's great that OOCSS is cross browser... but that doesn't mean that someone who doesn't have to support IE6 can't use stacked classes. For example...just because jQuery is cross compatible doesn't mean everything done with it is cross-compatible. 

This isn't a discussion about whether or not to support IE6... nowhere in the article linked does it even broach the topic of browser support (and for good reason): You either support IE6 or you don't. Even if you liked stacked classes, you couldn't even use it (unless you use some Javascript library to get selector support, which is another topic entirely). Keep doing whatever works for you right now if you must support IE6, as I (nor the article) am in no way advocating dropping IE6 support just for stacked classes.... so why discuss it?

Let's discuss stacked classes.

I think people forget how fragile CSS actually is... 1 line of errant CSS is all it takes to pretty much wreck the way a site renders: keep this in mind. This isn't Dreamweaver.. ideally you are working in an environment where you know someone isn't going to take a class that was only meant to be targeted with a stack and put styles directly on it... this is obvious, but you could just as easily target something based on location / circumstance / perceived 'smart default', all which would be just as bad.

Take this example: Take the .invert class Nicole Sullivan has talked about (which I'm currently using). It serves only 1 purpose: to identify areas of the site where content should be inverted for contrast purposes. Let's assume I'm working with a templated system (Ruby on Rails, Django, whatever) and I have a footer that appears on multiple pages with the same exact code, but some of those pages are dark text / media on light background, and some are light text / media on dark background. Let's say I have an .error class which styles error text. But that doesn't look too good on a dark background. So I want error text to look different on dark backgrounds. What's the fix? Some people would change the actual content each time it appears to account for that (.error and .error2 to surmise) or just target based on location, both subpar solutions. The smarter thing to do is to have the template engine insert a .invert wrapper which describes the section, and if a class can know how to display on a light / dark background, you have the class chain upon that invert class (it works nicely with SASS using the parent selector but you can do without) so that other than describing that section, nothing else is needed.

Now you might be asking what that has to do with chaining... it doesn't explicitly (you could use descendant there). But think about the usefulness of the invert class, and how utterly easy it would be for someone to mess it up... maybe use it to create multiple permutations that had nothing to do with inverting for contrast purposes(wrong)... adding margin to items based on location and pure circumstance (very wrong)... put it in the wrong place, leave it there when no content needs to be inverted (all wrong)...it's very easy in a robust application to mess stuff up like this. Granted the example I gave before(.btn.green / .alert.green) is a little bit contrived (probably would be .success or something vague like that) but the overall idea is that we're working on sites with thousands of pages and ideally everyone on my team knows what they're doing... we check code in via git (source control) and can immediately run git blame to see if someone did something wrong... we have descriptions and labels for all of our classes (for instance, .invert is a modifier class and should never be targeted directly, and should only be used for contrast purposes where you have an element that looks good on one type of background and not the other (which makes sense on our site)), and we use them responsibly. 

Yes you occasionally mess up but that is the nature of the beast, especially with OOCSS (everything is a class? everything is reusable? staying away from targeting based on body id? you are bound to have run into more conflicts with this philosophy but that's the point). But generally no cross pollination wouldn't happen... even if it did, it would be just as apt at happening as someone creating a class for a specific purpose not knowing it already existed on a descendant selector or what have you... and you would use the same sort of process to check that (ctrl + f / grep your repo, if it's not being used your golden... if it is being used, see what context it's being used in and mirror / alter it if need be). The only way to stay away from that is do what many sites do: end up targeting location / pages specifically.... which gets you reusing code unnecessarily (and let's not even talk about maintainability, or the sheer un-predictability of it).

A great example of stacked classes in use: http://www.mailchimp.com

They use stacked classes on those buttons. If I'm not mistaken, Nicole Sullivan worked on that for them as well.

On Tuesday, March 6, 2012 2:41:43 PM UTC-5, Murray wrote:

Can you give us an example of .btn.green and .alert.green "done properly". 

Unless you're in complete control of the entire project, until the end of its life, I can't see how you can avoid cross pollination of styles. I'm interested to see how you do it. 

Also OOCSS is supposed to be cross browser compatible, so there is value in taking ie6 into account when discussing  things like this. 

Regards, Murray

On 7/03/2012, at 8:17 AM, xckpd7 <**********@gmail.com> wrote:

Why would you even use a use case like 'success'? Wouldn't a button class be more apt in this situation? 

Let's take another situation: Assume I have a button and I want an alert button, a success button, warning button, so on. They all share styles (border-radius, cross-browser stuff, what have you). Now I don't know about you, but maintaining a mini library (aka multiple selector) of all the buttons I have is a tad silly(e.g. .btn-success,.btn-alert,.button-warning { border-radius: 5px; }). 

What I do is throw default styles on a button class (.btn) and then you can namespace with stacked classes to keep class names simple and reduce possible conflicts within a very big system (.btn.green / .alert.green will never conflict if used properly.. this is a huge gain in terms of simplicity, readability, etc) and you avoid doing .btn-green / .alert-green... and that's not even taking into account how you're going to handle implementing DRY for that).

As far as the article goes, the base can stand for anything.... ideally in your CSS there is explanation on how to use the classes, what sort of markup is needed.

You can either choose to have a default or not (.... smart defaults anyone? This is OOCSS right? This is always what Nicole Sullivan has advocated) for instance if I just use .btn, maybe I make a certain style default, but maybe not. It depends on what works for your site... at my job we use both in different situations when it makes sense. If you don't choose to use a default, then the stacked class should always be used with another class. As far as reusing it with other modules... just build out a reusable class to do just that. If you find that you want to use .btn-success on some other sort of item other than a button, then it was an architecture problem in the first place.... rename it to something that makes sense, and make it reusable. 

Let's not forget that even though we use classes for reusability, when we make skins, the styling inside the skins are using descendant selectors... it's not like everything is ia global class that can be mixed-matched ad-infinitum. That would get very messy, very fast. It might make sense for the simply designed Twitter / Bootstrap, but many large sites would probably be better suited with the stacked classes in certain situations.

Rick, I think IE6 support is it's own separate thing that shouldn't be grouped in. If you're among the unfortunate that still have to support IE6, this obviously not might work well for you. If you don't however, I think it's perfectly fine to use stacked classes, just not in the way perpetrated in the example given.

On Monday, March 5, 2012 9:33:13 PM UTC-5, Arunan Skanthan wrote:

http://www.markdotto.com/2012/02/16/scope-css-classes-with-prefixes/ 

I practically find that .btn .btn-alert seems a good alternative to .btn.alert (having used the latter style in a recent project and found that I had to create a different class name instead of .alert)

Any thoughts on this?

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/WH1nS6wIAs4J.

To post to this group, send email to object-oriented-css@googlegroups.com.
To unsubscribe from this group, send email to object-oriented-css+unsub...@googlegroups.com.

[Murray Nuttall]

Hmm, I might revisit stacked classes after all.

I had some life-changing results using them a couple of months ago on some buttons, but the awesomeness had to be scraped once they got into test due to IE6 compatibility... Which wasn't in the functional specification.

Maybe I'm still hurt.

I think your example .btn.green probably threw me off a bit, but of course it was just an illustrative example.

When I used stacked classes I still prefixed each class with it's intended purpose (something like, btn.btn-silver.btn-find-out-more), but this is for ease of use down the track. My job was to build html/css to pass onto a development team that had seemingly no idea how to use html/css at all. 

Murray.

To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/eBOYliHivusJ.

To post to this group, send email to object-or...@googlegroups.com.
To unsubscribe from this group, send email to object-oriented...@googlegroups.com.

[Aeron Glemann]

Six of one, half a dozen of another. There are so many factors at play here, some of which have already been mentioned: template engine, framework organization, preprocessor, ie6 support, etc. I don't see either approach being decisively better. In my case we use SASS with @extend and prefixed classes so you can get away with class="btn-success". But again, this is completely dependant on many other factors in our organization and approach.

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/NFClFalm3pYJ.

[xckpd7]

Watch out using @extend in SASS... specificity gets tricky with it... say for instance you have a class and you extend it 3 times later in the document... if you override the base class before the extends, it will get overridden (because how it works is it combines the thing you're extending with what you're extending in a multiple selector... so if you're used to carefully managing specificity (the kind of thing you do with OOCSS) it gets tricky... just imagine you're using it site wide in thousands of lines of code, with nested extends....  I've found at a high level it's very unpredictable so I don't use it.... I wish they just took the contents of the class you're extending and inserted it where you wanted it (which I know a mixin does but it would be great to have the ability to multipurpose a class as a mixin). 

On Wednesday, March 7, 2012 8:04:51 AM UTC-5, aglemann wrote:

Six of one, half a dozen of another. There are so many factors at play here, some of which have already been mentioned: template engine, framework organization, preprocessor, ie6 support, etc. I don't see either approach being decisively better. In my case we use SASS with @extend and prefixed classes so you can get away with class="btn-success". But again, this is completely dependant on many other factors in our organization and approach.

On Mar 5, 2012 8:33 PM, "Arunan Skanthan" <****@gmail.com> wrote:

http://www.markdotto.com/2012/02/16/scope-css-classes-with-prefixes/ 

I practically find that .btn .btn-alert seems a good alternative to .btn.alert (having used the latter style in a recent project and found that I had to create a different class name instead of .alert)

Any thoughts on this?

--
You received this message because you are subscribed to the Google Groups "Object Oriented CSS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/NFClFalm3pYJ.

To post to this group, send email to object-oriented-css@googlegroups.com.
To unsubscribe from this group, send email to object-oriented-css+unsub...@googlegroups.com.

[Aeron Glemann]

Yep. We only use @extend in a very limited and controlled basis. Everything you say is true plus it can make your stylesheets huge very quickly if you're not careful. What you describe - reusing classes as mixins - sounds like the approach LESS takes.

To view this discussion on the web visit https://groups.google.com/d/msg/object-oriented-css/-/QFYZCrs4iA0J.
To post to this group, send email to object-or...@googlegroups.com.
To unsubscribe from this group, send email to object-oriented...@googlegroups.com.

[Chris Eppstein]

What I suggest in these cases is to have a mixin that you use to build
a base class. You use extend on the base class where it makes sense
and include with the mixin where it makes sense. You can't just mixin
a class in the general case because that class can have lots of touch
points with lots of different selectors.

On Mar 7, 7:16 am, xckpd7 <wright....@gmail.com> wrote:
> Watch out using @extend in SASS... specificity gets tricky with it... say
> for instance you have a class and you extend it 3 times later in the
> document... if you override the base class before the extends, it will get
> overridden (because how it works is it combines the thing you're extending
> with what you're extending in a multiple selector... so if you're used to
> carefully managing specificity (the kind of thing you do with OOCSS) it
> gets tricky... just imagine you're using it site wide in thousands of lines
> of code, with nested extends....  I've found at a high level it's very
> unpredictable so I don't use it.... I wish they just took the contents of
> the class you're extending and inserted it where you wanted it (which I
> know a mixin does but it would be great to have the ability to multipurpose
> a class as a mixin).
>
>
>
>
>
>
>
> On Wednesday, March 7, 2012 8:04:51 AM UTC-5, aglemann wrote:
>
> > Six of one, half a dozen of another. There are so many factors at play
> > here, some of which have already been mentioned: template engine, framework
> > organization, preprocessor, ie6 support, etc. I don't see either approach
> > being decisively better. In my case we use SASS with @extend and prefixed
> > classes so you can get away with class="btn-success". But again, this is
> > completely dependant on many other factors in our organization and approach.

> > On Mar 5, 2012 8:33 PM, "Arunan Skanthan" <*...@gmail.com> wrote:
>
> >>http://www.markdotto.com/2012/02/16/scope-css-classes-with-prefixes/
>
> >> I practically find that .btn .btn-alert seems a good alternative to
> >> .btn.alert (having used the latter style in a recent project and found that
> >> I had to create a different class name instead of .alert)
>
> >> Any thoughts on this?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Object Oriented CSS" group.
> >> To view this discussion on the web visit
> >>https://groups.google.com/d/msg/object-oriented-css/-/NFClFalm3pYJ.

> >> To post to this group, send email to object-or...@googlegroups.com
> >> .

> >> To unsubscribe from this group, send email to

> >> object-oriented...@googlegroups.com.

[xckpd7]

Take a look at this as well.... he advocates the multiple class style... great post.

http://nicolasgallagher.com/about-html-semantics-front-end-architecture/