Looks like they've not updated the main site yet:
https://github.com/cloudhead/less.js/commit/5b6b5ccc8d919a5afdeff5b9b75430cde9c2ed50
David Scotson
Interventi di David Scotson
It's a matter of "parent" vs. "plugins", you need a line like this:
$THEME->parent_exclude_sheets = array('moodle');
which controls the theme sheets (i.e. themename/styles/blah.css) you get from parents.
This line, which you've already got, excludes the styles coming from plugins (e.g. mod/forum/styles.css)
$THEME->plugins_exclude_sheets = array(
So take bootstrapbase out of the latter, and put it into the former. If you've only got one parent, you don't need to specify the theme by name in an outer array, just name the stylesheet.
Regarding the Bootstrap and Pure navbar examples. The reason that Bootstrap needs the extra code for the seperators is because it's supports IE7, which doesn't support :before. Bootstrap 3, which no longer supports IE7, now does it the Pure way (or more likely, Pure copied the Bootstrap 3 way).
http://rnikitin.github.io/components/#breadcrumbs (note this is unofficial docs of an unreleased version, they've been asking people not to publish them because they get so much grief from people commenting on their half-finished work, so don't assume that it's look, particularly the buttons, is final)
Which brings me to my wider point. We should upgrade to Bootstrap 3 for 2.6. I was going to start work on this today, I'm not anticipating it being a big deal, and it brings a lot of good things to the table.
http://rnikitin.github.io/components/#breadcrumbs (note this is unofficial docs of an unreleased version, they've been asking people not to publish them because they get so much grief from people commenting on their half-finished work, so don't assume that it's look, particularly the buttons, is final)
Which brings me to my wider point. We should upgrade to Bootstrap 3 for 2.6. I was going to start work on this today, I'm not anticipating it being a big deal, and it brings a lot of good things to the table.
So one issue that probably needs exploring is what I generally think of as "semantic fundamentalism" for lack of a better phrase. Which is represented here by the following lines:
"The problem with this approach IMO is that adding specific classes to the HTML prevents themers from changing the presentation. It also combines logic about the presentation with the content (which CSS is supposed to avoid)."
and a few other comments further down.
This used to be a popular CSS approach, advocated by the like of Zeldman. And if you were building a one-person, custom built website today then it might still make sense. (Actually, now I think about it, this approach would only make sense if you were a professional web developer and needed to show off your skills, everyone else would just use a framework and move on to the more interesting parts of their web project i.e. the content or service they want to provide, not the the low level details of the HTML).
The basic gist is that you name your classes after the semantics of what the thing is, rather than what it looks like. And then, like the CSS Zen Garden, you custom write CSS to match those semantic names without ever touching the HTML.
This also gets confused with the semantics of using correct HTML e.g. putting lists in lists, using buttons for buttons, making headers headers, using tables for tables and lots of other very obvious things that seem blindingly stupid when you write them down like that. But unlike that other kind of semantics, class names have absolutely no impact on usability and accessibility, and are much closer to variable or function names in code. They're important to the developers, not to the users and should reflect the concerns of the developers.
But the reason there's been a move away from this is that it simply doesn't work in large projects being built by distributed teams. Often the new best practices that were developed at places like Facebook, Yahoo or Twitter fly directly in the face of this old-fashioned method. One thing they discovered is that, to put it bluntly, most pages on Facebook are not unique snowflakes. They're fairly boring re-arrangements of standard components. Components so standard that you can get 90% of them in a 3rd party library.
The final upshot of this is that it should be possible, and is desirable, to use standard Bootstrap HTML in many places in Moodle. In an ideal world those should be in renderers so that other frameworks, or the next version of Bootstrap can easily swap in other HTML. But, if time pressure strikes, simply using Bootstrap HTML to cover the last few places that aren't neatly reached via nicely modular code should not be seen as some great sin. It will almost certainly be better than the alternative which is a developer, under time pressure, coming up with some one-off HTML that varies in subtle ways from basically the exact same thing built by all the other devs under similar circumstances.
Which reminds me: It's worth mentioning that although the Zeldmanesque method gets talked about in Moodle forums quite a lot, it's not particularly reflected in the current HTML codebase which is a bit more random in it's methodology. So it's not like I'm saying we should move from A to B, I'm saying we've not got either A or B, and they clash at a fundamental level so going forward we should choose one (B!) and work towards that without getting confused by inappropriate notions from A. They're different paradigms, mixing them will only lead to confusion and a lot of pointless extra work that will provide no benefit.
"The problem with this approach IMO is that adding specific classes to the HTML prevents themers from changing the presentation. It also combines logic about the presentation with the content (which CSS is supposed to avoid)."
and a few other comments further down.
This used to be a popular CSS approach, advocated by the like of Zeldman. And if you were building a one-person, custom built website today then it might still make sense. (Actually, now I think about it, this approach would only make sense if you were a professional web developer and needed to show off your skills, everyone else would just use a framework and move on to the more interesting parts of their web project i.e. the content or service they want to provide, not the the low level details of the HTML).
The basic gist is that you name your classes after the semantics of what the thing is, rather than what it looks like. And then, like the CSS Zen Garden, you custom write CSS to match those semantic names without ever touching the HTML.
This also gets confused with the semantics of using correct HTML e.g. putting lists in lists, using buttons for buttons, making headers headers, using tables for tables and lots of other very obvious things that seem blindingly stupid when you write them down like that. But unlike that other kind of semantics, class names have absolutely no impact on usability and accessibility, and are much closer to variable or function names in code. They're important to the developers, not to the users and should reflect the concerns of the developers.
But the reason there's been a move away from this is that it simply doesn't work in large projects being built by distributed teams. Often the new best practices that were developed at places like Facebook, Yahoo or Twitter fly directly in the face of this old-fashioned method. One thing they discovered is that, to put it bluntly, most pages on Facebook are not unique snowflakes. They're fairly boring re-arrangements of standard components. Components so standard that you can get 90% of them in a 3rd party library.
The final upshot of this is that it should be possible, and is desirable, to use standard Bootstrap HTML in many places in Moodle. In an ideal world those should be in renderers so that other frameworks, or the next version of Bootstrap can easily swap in other HTML. But, if time pressure strikes, simply using Bootstrap HTML to cover the last few places that aren't neatly reached via nicely modular code should not be seen as some great sin. It will almost certainly be better than the alternative which is a developer, under time pressure, coming up with some one-off HTML that varies in subtle ways from basically the exact same thing built by all the other devs under similar circumstances.
Which reminds me: It's worth mentioning that although the Zeldmanesque method gets talked about in Moodle forums quite a lot, it's not particularly reflected in the current HTML codebase which is a bit more random in it's methodology. So it's not like I'm saying we should move from A to B, I'm saying we've not got either A or B, and they clash at a fundamental level so going forward we should choose one (B!) and work towards that without getting confused by inappropriate notions from A. They're different paradigms, mixing them will only lead to confusion and a lot of pointless extra work that will provide no benefit.
Regarding the section on backwards compatability and keeping bootstrap specific code out of "core renderers", it would be possible to move the current "core renderers" into the Base theme and move the current BootstrapBase renderers into core without affecting anyone who inherits from those either of those two themes.
Any new renders would then be somewhat constrained by current Moodle, since you'd have to keep the current code (or a close approximation) pluggable with the new code. But it should work as well as the current tabs renderer does for most stuff.
In fact you could test this by doing this switch with the tabs renderer right now.
Any new renders would then be somewhat constrained by current Moodle, since you'd have to keep the current code (or a close approximation) pluggable with the new code. But it should work as well as the current tabs renderer does for most stuff.
In fact you could test this by doing this switch with the tabs renderer right now.