I was going to say this wouldn't work because the entire point of those functions was to be able to dynamically change them based on any conditional. But I realized you could accomplish this with normal selectors as well since all the variations are added to the body class.

And if that's the case, why even keep roots_main_class at all?

Initially I thought roots_main_class() could go away too, but we need to know if <main> precedes a sidebar because there is no CSS parent selector. The conditional functions will still work 100%.

It can still work without it. With this PR roots_main_class just depends on roots_display_sidebar which is just a bunch of conditionals. All of which could (in some way) be determined by classes on the body. So you could do something like:

.front-page .main {
  .make-sm-column(8);
}

That would be ok but then pages that should not display a sidebar would still have the sidebar markup.

roots_display_sidebar could still remain although I guess at that point you may as well keep it for the <main> classes as well instead of duplicating login in CSS.

If roots_display_sidebar() remains then I think roots_main_class() is indispensable. The body classes should be ok but their removal will force a decent bit more CSS/LESS which is not a problem per sé, it just seems like keeping Roots lean is a noble aim.

I think I like the idea of this PR, except for the fact that we're re-using the classname "sidebar". I'm all for OOP LESS/CSS but I think for some newcomers to roots it could get to be confusing. If I was just getting started using roots I'd be like "I'm going to style the sidebar now" and then I'd be like oh, ".sidebar will have a background color of black", and then I'd be like "WTF, my main element has a background of black" - then I'd have to add a new class to the sidebar element so I could style specifically that... Does that make sense or is it a bad use case?

Maybe we could do ".main.sidebar-active" or something like that.

Also, this brings up another "direction of Roots" discussion. If we start moving BS styles away from the template files (a la http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html), could that help us in the future move it towards a front end framework agnostic starter theme? If we want to move in that direction, I think it's a good idea. If we don't, then maybe this PR isn't a good idea. Personally I dislike that article and like mixing CSS classes with my HTML because I like markup that has descriptive classes and such, but that's just me.

Sorry not trying to thread jack this with that last comment, just thought it would be a good point to bring up.

Both good points.

A sidebar-active class is a good idea but now that I think about it I would add that class to the body element and just leave main alone... better yet the class can be roots-sidebar. Thoughts on that?

Any change has the possibility of starting a slippery slope, but I think if we have intelligent discussions about it and keep checks on the relevant issues then the slopes can be less slippery.

While it's true that I have an affinity for removing Bootstrap markup, the main purpose of this PR is to separate PHP and HTML.

Ah! A .sidebar-active class on the body would also be my choice, good suggestion. That's one of the things I've done when building front ends for Web Applications, don't know why I didn't think about that. I guess I was stuck looking at the lines in the PR. Again, my personal choice, what do the others think?

As much as I personally wants Roots to stay Bootstrap forever because I personally like Bootstrap, it's not fair for me to hold it back from what it could be. I think that eventually if a developer could start with Roots and use (or even switch between) different frameworks using bower and a few LESS/SCSS rules, I'd be pretty cool. Plus everyone knows that something bigger/better always comes up.

I say go for it, and let's start that discussion about moving Roots towards a "whatever you want to use" somewhere. (Discourse?)

PHP is used because WordPress doesn't have a proper template engine like Smarty or Twig.

Because of the filter that is applied to the output of each function, users can also hook into it and change the class(es) dynamically. Perhaps you want a wider sidebar on pages than on posts, or some such. That's where PHP is more helpful than LESS.

Also, if you are going to stick with this method, I'd recommend the following...

- .main { }
+ .main:extend(.col-sm-12 all) { }
+ .main.sidebar:extend(.col-sm-8 all) { }

- .sidebar { }
+ .sidebar:extend(.col-sm-4 all) { }

PS-

it just seems like keeping Roots lean is a noble aim.

If that's the case, then keeping it how it is much leaner than forcing users to figure out how to specify the sidebar only in special circumstances, something that is much more easily accomplished by simply overriding the output of the filter.

Updated the commit to add a body class of roots-sidebar but now I'm not sure how that amount of branding sits with everyone or if this entire PR is even worth continuing.

@QWp6t, I did try your suggested LESS but for some reason the .main and .sidebar selectors don't get extended into the column classes, which I suspect is because the column classes are generated by .make-grid-columns(). I'm not familiar enough with LESS and extend to determine whether it's a defect.

Edit
It is a known issue with LESS.

I like the way you did those recent changes, but again, that's my personal preference. Maybe this PR is better to come back to down the road, when we decide if we want to spend more time moving towards moving Bootstrap-specific classes outside of the templates and more towards the LESS files.

While I prefer it, doing it this way does seem a little inconsistent with the rest of the way Roots looks, at least now. What do you guys think?

Well again, I just want to highlight that the motivation behind this is to move some of the markup out of PHP if possible.

Totally. You have to start somewhere, right?

I think it's up to the "team" to figure out what they want to do at this point, I'm totally ok with whatever is decided.

I did go ahead and change the active class to .sidebar-active to keep it more generic.

I also like .sidebar-active. And as someone who uses Bootstrap I'm still very happy with the prospect of moving away from Bootstrap specific HTML. I much prefer to keep my grid decisions in Sass.

Without weighing in on any of the other important issues raised, I think .sidebar-primary is more useful than .sidebar-active as it actually describes the sidebar in use.

Good point Foxaii, but when you create multiple sidebars that means you have to go add the classes somewhere, would that be in config.php?

Foxaii that's perfect. I knew what I had so far wasn't 100% there and your suggestion was spot on. PR updated!

Updated and rebased

Can we get these changes in the Sass build as well. Or should I open a separate issue.

@cfxd sorry this has been sitting around, will test and merge this in tomorrow

thanks @cfxd and everyone else who weighed on this.

this is a move in the right direction to become framework agnostic. 👍

Heh, ok. I still maintain my motive was just to move some markup out of PHP ;-)