There's a few Bootstrap v3 based themes being worked on now, and there talk (MDL-40177) of upgrading Bootstrapbase to use v3. So is there some central place people can contribute to this effort?
The github of Bas Brands seems like a potential candidate:
https://github.com/bmbrands/theme_bootstrap
I am a little too sceptical to say yes, as I feel that with Bas not being around as much, was in some way instrumental in us losing the opportunity to get the dock working in Moodle 2.6 because it was not submitted on time. We cannot afford to do the same if we want Bootstrap3 to be ready to be submitted for approval by HQ.
Perhaps you could set up a new branch on your GitHub at least you have some authority in the Moodle Tracker and you could co-ordinate it.
Just some thoughts...
Mary
I'm intending to use it for a 2.6 theme, and that's what Bas (and others) are working on right now, and the numerous users of the various themes gives a much greater opporutinity for feedback and bug-reporting. Once there's a decision made about whether Bootstrap 3 is wanted in the main codebase it should be relatively easy to import the changes for use in 2.7.
I cannot agree more! Let's first try to get it working and show how Bootstrap 3 could be an improvement over Bootstrap 2. Once that's finished it can be modified / polished improved to work as a base theme.
All input is very valuable and help with code and test is very much appreciated. We are still at a very early stage of creating this theme and there is still lots to do. I think Bootstrap 3 itself is still a bit of a work in progress (no rtl support) so rushing things might be a risk.
and unfortunately there is not port to YUI of the new Bootstrap 3 jQuery
Are there any fundamental differences between 'bootstrapbase/less/moodle' and 'theme_bootstrap/less/moodle'?
both a mess - some of which i'm happy to take the blame for.
seems to be lots of random new stuff in bootstrapbase/less/moodle ?
have been sorting through some of it, but i get the feeling i could swap them around and not much would change.
which "bootstrapbase/less/moodle" are we talking about? Mine? If so there shouldn't be much new stuff, if any (compared with 2.6 bootstrapbase), but there should be:
* stuff that got deleted as it's not needed anymore
* lots of stuff that got renamed
You can see that in the diff if you skip past all the less/bootstrap stuff (which is just replacing the 2.3 files from upstream Bootstrap with the new versions):
https://github.com/ds125v/moodle/compare/master...bootstrap3
I've started putting in pull requests to Bas's github for some of that stuff though.
* stuff that got deleted as it's not needed anymore
* lots of stuff that got renamed
You can see that in the diff if you skip past all the less/bootstrap stuff (which is just replacing the 2.3 files from upstream Bootstrap with the new versions):
https://github.com/ds125v/moodle/compare/master...bootstrap3
I've started putting in pull requests to Bas's github for some of that stuff though.
Sorry, I mean the difference between: https://github.com/bmbrands/theme_bootstrap/tree/master/less/moodle and https://github.com/moodle/moodle/tree/master/theme/bootstrapbase/less/moodle
I just ran a diff on the two to check but as I suspected the vast, overwhelming majority is simple changes in LESS variables like:
@linkColor -> @link-color
@successText -> @state-success-text
and so on.
With a smattering of more clever replacements like the fact that form layouts used to be their own thing in Bootstrap 2.3 but now they use the same grid system as everything else. So the code that did that mapping has changed to map the new CSS to the Moodle HTML.
@linkColor -> @link-color
@successText -> @state-success-text
and so on.
With a smattering of more clever replacements like the fact that form layouts used to be their own thing in Bootstrap 2.3 but now they use the same grid system as everything else. So the code that did that mapping has changed to map the new CSS to the Moodle HTML.
Thank you David.
possibly OT - but i was looking at the moodle/less files on github latest branch...
is it the case that most of the css in moodle/less should map to the css for non-bootstrap themes in core.css, course.css and mod specific css etc? It seems like most of the css, as you would expect at the moment, is duplicated in both these places (except where moodle html now uses bootstrap css where i have no idea how hq have handled this) ?
Yes, the less/moodle files started off by forking the base/style/ CSS files, though they've diverged in various ways since.
have you taken a look recently? lots of stuff in those less files including widths set to 200px, divs with display:tabel-cell, massive overspecification and all that fun ;)
most of these changes made the output css even bigger
Yeah, it's become part of mainstream Moodle development now so the same processes that created the Base CSS continue in Bootstrapbase (and a lot was never fully exorcised in the fork).
I try not to worry about the CSS too much since I believe that most of it is unnecessary, for a range of reasons, and so focus on ways to simply delete it.
So ways to do that are to fix bugs and remove the CSS workaround, or implement Bootstrap HTML in renderers and delete the old CSS. The latter will be my focus for Bootstrapbase3.
I try not to worry about the CSS too much since I believe that most of it is unnecessary, for a range of reasons, and so focus on ways to simply delete it.
So ways to do that are to fix bugs and remove the CSS workaround, or implement Bootstrap HTML in renderers and delete the old CSS. The latter will be my focus for Bootstrapbase3.
That's certainly a better approach...I fully subscribe to that way of working. If only it were that easy...
The key is refactoring -> http://martinfowler.com/books/refactoring.html. Change the existing mark-up and styles such that a more flexible architecture can be employed that facilitates the implementation of different frameworks with minimal mapping. So, for Moodle, reduce the chaos, remove duplication, separate out form and function styles - i.e. grid, colours etc. separate. Implement common base renderers in everything for which a framework in a theme can override if required. The renderers themselves should not be one monolithic method, but rather call protected methods that define elements that are perceived to be different in each framework but keep the logic in one place.
how do you spell css again?
Chaotic Style Sheets.