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.
