We need to do this soon, so the more people who can collaborate the better.

Amy, Bas, David & Stuart, I've just adding you as watchers with the hope that you can all collabotae on getting this off the ground and into Moodle CORE.

I thought some of this was already happening, there was some interaction about between Martin and Bas in this thread:

https://moodle.org/plugins/view.php?plugin=theme_bootstrap

I'll just copy the relevant bit here:

Martin Dougiamas, 8 déc:

I'd like to see a 2.4 version that keeps the new default icons.

Also, can't the custom menu just use CSS? Is jquery necessary?

Only asking these because I'd love to see something like this as a core base theme."

Bas Brands, 8 déc.:

"Thanks Martin, I am working on a new version and will use the 2.4 icons instead of the glyphicons. The bootstrap custom dropdown menu needs jQuery but I guess it could be rewritten to use YUI.

It would be very cool to have this as a core theme!"

Hi Mary, David,

I still think it would be very nice to have a bootstrap theme into core. And why not try to create it together? So I think this is a nice initiative Mary!
After the messages quoted by David I did not have any contact with Martin or any others about getting bootstrap into core.
I would really like to help out getting it into core and having a online meeting about it might be a good start. There are a couple of questions I have about core themes and it would be a nice opportunity to share experiences.
Oh and I will be at the Ireland / UK Moot next week, will any of you be attending?

From my own perspective a standard core theme that contained the standard bootstrap CSS file in full would be great, even if it was marked experimental, as long as it was made part of the standard QA process to check things against it. There's plenty more work to be done afterwards but having that CSS there is the first big step and I'd be happy to help in any way to get this done.

I'm currently working on Bootstrap v3 stuff, but if this is going live with Moodle 2.5 then Bootstrap v2 would probably make more sense (they're not that different).

Knowing how Moodle works you have to propose something and make a good presentation before it gets acknowledged. If Moodle HQ like it well enough then they will adopt it. So what better that a joint Bootstrap project.

What I am proposing is to start off a Bootstrap Project that will ultimately take over from Base theme. However, before we can do this Base needs to be replaced as it is currently the parent of all themes. We could get round this by adding the pagelayout.css for Base into Canvas. In which case we could use Base theme to hold all the bootstrap files, but would Moodle HQ be happy about having renderers in Base?

These are the things that need to be discussed, I am sure there are lots of other things too to discuss, but at least creating MDL-38016 we have a chance to be heard.

Perhaps the project should be called MootStrap

So if we take Bas's project as a starting point (https://github.com/bmbrands/theme_bootstrap) then I believe the first suggestion Martin made has already been taken care of and you can use the new Moodle icons introduced in 2.4

The other thing is JQuery. There's a bunch of JQuery things in Bootstrap, but I'm guessing the only one that were actually using is the drop down menus. Has anyone done anything about getting them running with YUI?

I'll note that in Bootstrap 3 that sub-menus are no longer part of core Bootstrap, for reasons I agree with, though it seems to be a popular feature with some people. I'm mentioning that because hooking up single level menus would be less work and probably a good first step even if we wanted to make multi-level menus later.

Other than those two specific things (and we should check back with Martin if he or the other core Moodle people have got any other issues) I'd say the rest is just wider testing and bug fixing or nice-to-haves that we can work on right up until the release of 2.5.)

Regarding Mary's comment about replacing Base. I think that's a good long-term goal as well, but right now inheriting from Base (which the theme that Bas built does) is fine.

People wanting to inherit from Bootstrap can do so (I believe? There was some confusion about how renderers got inherited).

And regarding MoodleMoot in Ireland, unfortunately I'll not be there. I had intended to go, precisely to talk about Bootstrap stuff but I got confused and thought it was in the summer and by the time I realised my mistake it was a bit late.

I think what you are proposing David is OK up to a point, however, I feel that we need to move as far away as possible from the Holy Grail layout in Moodle. Historically speaking, the Matthew James Taylor's Holy Grail was implement just prior to Moodle 2.0 bring rolled out in March 2010. It's actually flawed in Moodle, as it has been hacked to death, and no one really understands how it's put together, how it is balanced on a knife edge in CSS. In fact it's a nightmare of a thing to get right, and does not work well in RTL for IE6 & IE7.

I propose we go for the bootstrap grid system, which seems to work well in my Tiny Bootstrap Project.

As for the custommenu and YUI, Amy Groshek has been helping with the menu in my Tiny Bootstrap Project and has got it working with sub-menus. It also has icons added to it too.

I think it would be easy enough to use Base theme as a home for the majority of the Bootstrap files. Technically speaking, CORE themes rely more on Base css to style the inner workings of Moodle. So shifting the pagelayout.css from Base theme to Canvas will take care of the Holy Grail layout, while still keeping Base(bootstrap) as a parent to allow access to the CSS needed to style those themes were needed, as well as carry the bootstrap css. We will, of course, have to exclude some of the bootstrap css from current CORE themes, but we may also have the chance to revamp those themes at a later date should the need arise, and add some nice buttons and eye-candy. Let's face it there are lots of areas in Moodle that need a face lift, like forms and stuff.

These are only my views of the larger picture, and may not be to everyones liking.

Sadly, I am not going to the Moot either.

I'm with Mary on adopting a grid system. This would put us in a good position to make all core themes responsive down the line.

As far as rewriting custommenu for YUI, I think we should push back on this. The jQuery/YUI issue is a larger issue that Moodle needs to solve. There's no reason the two libraries can't coexist in Moodle. Why spend all that effort to retool the menu, since it will make upgrading bootstrap harder, and supporting the theme harder, in the future. By rewriting only one component because Moodle refuses to use two libraries, we generate high technical debt for future supporters of these themes. Ideally, as Bootstrap versions are released, our theme is designed so we can just drop in those new releases with minimal effort and upgrade the theme.

Moodle packages YUI css in /lib. I'm wondering whether bootstrap, as what is technically its own external library, should also in some way be placed in lib, and managed as such?

Adding Andrew Nicols and Petr Škoda to get some input on this from a development and maintenance perspective.

Thanks Amy.

The jQuery/YUI debate from October 2011 makes an interesting read, especially Martins comments...

The main reason I'm looking at jQuery at all is because every single developer that walks in here for an interview has already used it. It's more efficient to be working ith a mainstream product (in terms of users). I think at this point a switch from YUI to jQuery is fairly possible using rosetta stones etc, if we do it soon, although it's a lot of work for core and contrib devs.(21/10/2012)

Regarding grids the Bootstrap theme by Bas Brands that I linked to earlier uses the Bootstrap grid. I agree using the Bootstrap grid layout classes is a vital requirement. (That theme also has some leftovers classes from older Moodle that could probably go, assuming that taking them out no longer breaks Moodle javascript, but the grid layout with "row" and "spanX" classes is definitely already there).

https://github.com/bmbrands/theme_bootstrap/blob/master/layout/general.php

Regarding the existing Base theme anything we change in that will affect every core theme and custom theme in existence as they all inherit from there. That will massively increases the amount of work (and in particular very boring, exhaustive testing) required to prevent breaking things for people with no interest in or knowledge of Bootstrap, and for no great benefit that I can see. It would be a lot easier to run the two themes in parallel and then deprecate/drop Base in 2.6, 7 or 8 and at that point promote Bootstrap to the Moodle "Base theme" (assuming all goes well) which means we can just focus on the future and people can make their own choice about when to inherit from Bootstrap rather than Base for their themes. I'd quite like it if we copied over everything we need from Base into Bootstrap and drop the inheritance in time for 2.5, but it's really not a dealbreaker for me if that inheritance remains for the next version. (In fact I'd go further and copy in some images from core Moodle too, but that's a tangent.)

For YUI and JQuery, I think getting the Bootstrap CSS and HTML into Moodle will do more for the cause of JQuery in Moodle than anything else I can think of. So I would suggest trying to achieve the easier target of of JQuery free Bootstrap first and then, once that's in the bag, move on to advocating for including JQuery and Bootstrap.js so there's a safe fallback position if that doesn't succeed. It's not particularly hard for a themer to include JQuery if they want it, plenty of people already do. I've not yet seen anywhere but the menus where it's possible to replace existing javascript with JQuery without major surgery to core Moodle so I see it as a more long-term thing compared with other, more immediate benefits.

I agree with what David Scotson is saying about jQuery, except that without an overarching strategy for including JS libs, we still run the increasing risk of ending up with one or more versions of jQuery loaded into a page from various mods and/or theme. That's not a large concern for one-off sites, but it is a large concern for partners who host thousands of sites. This is a good time to revisit that. It would be nice to hear from some core developers before we commit to one strategy or another.

I go away for a week, and look what happens!

Mary - thanks so much for creating this.

Been technically advising on using bootstrap in our rather ancient lms/admin system at sussex so although not up to speed with moodle, pretty hot on bootstrap at the moment.

http://epiclearninggroup.com/uk/platforms/enterprise-lms/ have started using the moodle bootstrap as their starting point for some (possibly all?) projects, so i'll get onto Mark (head of open source) about input into this as a commercial partner who builds for clients on top of the bootstrap theme.

Despite my love of javascript i'm sure you all know i have a strong belief the core/base of moodle should be able to work without any javascript libraries so anything we can do to decouple moodle from needing a whole bunch of js libs for interactions that really should be done with html/css these days would be great from my perspective.

Work wise i'm rather occupied with integrating lecture recording (http://opencast.org/matterhorn/), library lists (http://talisaspire.com/), plagiarism (http://turnitin.com/) and a whole heap of other fun stuff but will follow whats happening and hopefully do some collaborative coding with Bas again and maybe all of you? https://c9.io/ is awesome for this.

I'll be presenting at moodle dublin so able to catch up with Bas, Mark and anyone else going - otherwise add me on g+ https://plus.google.com/117151225863784084515/posts

xx
stuart

I've linked to a meta-bug that lists various issues filed against Moodle that have an impact on Bootstrap-based themes.

Does anyone know the cut-off date for contributed code into Moodle 2.5?

Yes we are building on top of Bootstrap now for our client themes, it's a wonderful theme. I have been logging occasional bugs in the Github issue tracker although there haven't been many (thanks to Bas and David for fixing those so quickly!). Happy to meet up in Dublin this week to discuss, I'm there all day Tues and Weds. Joe Barber is leading on the Bootstrap work at Epic and can contribute to any conversations on this and we may well be able to help out with some coding tasks, I am not a developer myself though so will need to pull Joe into those conversations!

Linked to a META bug about CSS name clashes between Moodle and Bootstrap.

Hi guys,

I found this issue by stumbling here via MDL-38081.
I've been working on a new moodle.org theme and as requested by Martin have been looking into the feasibility of creating it to make use of bootstrap.

These are just my personal opinions. I've not discussed this with anyone at HQ, no doubt this issue plus others like it will spur those discussions.
First up I don't think twitter bootstrap belongs within a theme. I think really if we are going to support twitter bootstrap in core, then we would be best to make bootstrap accessible to themes through core. Such that a theme can choose to use it and Moodle core code handles its inclusion.
This of course means that we will also need to support jQuery via core. But lets face it that's not a new idea.

What struck me about the use of bootstrap was that really to see benefit from it we need to be able to use its components within our renderers. Much of bootstrap is aimed around the consistency of its design, high quality look, and ease of use + styling.
I'm finding while working on the moodle.org theme there are many renderers I want to override in order to avoid a disjointed look.
It strikes me that really in order to see the most benefit out of bootstrap we would be best to adopt it as a core front-end framework, create some guidelines to using it within Moodle, and then look to convert existing output to make use of its layouts, components, and general design.
In the past we've avoided having core theme's overriding renderers. The reasoning behind it being that if a theme needs to override the renderer then likely we need to make changes to core.
At the very least any overriding by core theme's should be minimal.
Adopting bootstrap as a core framework would

In line with the above ideas, and perhaps just out of general interest as no doubt these questions will come up what are people's thoughts on the following:

1. I really like the ease of the layouts provided by bootstrap. When using them within the main content they are brilliant, however if we consider using them for the main layout there is one big issue, the fact that these layouts don't prioritise the content. The holy grail layout while difficult to work with was chosen as it provided that mythical 2,1,3 layout. I'm not accessibility expert, perhaps all of the access hidden jumpto's + content identification we are doing is enough that screen readers etc handle things correctly. Or perhaps there are other solutions. As this was such a huge driving factor in the original design I think addressing it will be important.
2. Accessibility in a more general way also needs to be considered. Bootstrap is recognised to fall short in a few areas in regards to accessibility. The nav list component for example doesn't provide any distinction for screen readers between headers and regular items. This is perhaps a moot point as we put a lot of work into addressing accessibility issues within Moodle, usually to the effect of finding solutions in HTML and there's nothing to stop us doing the same here. However it'd be great to see if anyone has any smart ideas or whether anyone has worked with bootstrap in an accessibility driven environment before and can shed light on how they handled things and whether then encountered many issue.
3. The large cross over between YUI Bootstrap; consider the following:
   • YUI Grids - Bootstrap scaffolding YUI grids was established before the movement towards responsive design really took off and as such lacks and integrated responsive facilities. There is the YUI3 grid builder which is pretty cool however at http://yui.github.com/gridbuilder/
   • Reset - both frameworks provide reset and not surprisingly they both do similar things but slightly differently. Which would we use, and do the frameworks hold dependencies to their reset CSS?
   • Components - both frameworks provide components. Many of those components are provided by both but look/act differently. Just from what I've seen YUI tends to be more accessible but much more difficult to use due to having so many options vs. bootstrap being easier to set up, better looking, and with less options/variants. Which would we use, in what situations etc etc?
4. CSS class name collisions This is a pretty prominent issue. As soon as I included the responsive css from bootstrap I noticed a myriad of issues (starting with the self registration form button disappearing) due to class name collisions. MDL-38081 is of course other collisions. In reviewing the bootstrap classes there are several classes that we use within Moodle already, things that need to be changed. hidden, container, etc collide. Are there any smart things people have thought up here or is it going to be a case of converting areas of core, scanning contrib plugins etc?

I'll leave it at that actually, this is getting pretty long. Feel free to tell me to get lost btw I am just butting in here.
I'm honestly trying to spur on discussion here and see where it goes. Presently I'm 50/50. I think adopting it as a core framework will allow us to solve many problems of the problems we have now with design consistency and ease or restyling. However we open a can of worms with two frameworks that largely do the same thing (who'll be the first to argue that).

So ... food for thought?

Cheers
Sam

Sam, that's good food. And I'll also predict that Bootstrap will be superceded by something else exciting in a year or a month.

Seems to make sense we stick to YUI ... http://yui.github.com/gridbuilder/ looks pretty good, no?

Hi Sam,

some responses to (some of) your points (btw, my numbering doesn't match yours):

1. Bootstrap in Core: I think in general Moodle should be moving away from this idea and putting everything front-end-ish in Themes where it can be examined and changed. Much like putting the front end code in renderers allows things to evolve, putting stuff into Themes lets people tweak things for their circumstances. When the next big thing comes along (even if it's only Bootstrap v3), it would be better if people could experiment with that, without having to work around hard-coded things in core. There already seems to be some move to this e.g. the filepicker images are in Base, the core CSS is in Base. If you don't inherit from Base you need to copy all that stuff across to your new theme, which is a relatively easy thing to do and makes it very easy to delete or change the bits you don't like.

2. Bootstrap in Core, part 2: I think it would be a very good idea if Moodle adopted the Bootstrap HTML conventions and rewrote the core renderers to output it. For example, if you want to add a pager go and look at Bootstrap's, if you want to add a form element go and look at Bootstrap's and copy the HTML. There's already talk about adopting standard conventions, it would be much better to use theirs than invent our own. This may seem to contradict the previous item but it's a thousand times easier to build a custom theme on Bootstrap's HTML than on what we've currently got. Note: I'm already experimenting with re-writing the renderers here: https://github.com/ds125v/moodle-theme_bootstrap_renderers and it works quite well. It also gives guidance on the ideal granularity of renderers (e.g. one for navbars, one for unstyled lists) that could then be easily be swapped for ones written to match Zurb or any other Bootstrap-alikes or rivals.

3. Grids are a surprisingly small part of moodle, it's basically one layout file. I originally did a grid with YUI when I was experimenting with an HTML5-based theme for Moodle and then redid it with Bootstrap. I don't recall any massive difference. Basically it comes down to which CSS files are you already including and what do you already have experience with. YUI was the first framework I remember doing grids, but they're ten-a-penny now. Like #1, put the decision in the Theme. (edit: regarding your accessability point, I don't recall either offering an easy way to put the content first in the HTML, I made myself feel better about it by using newer HTML5 tags and putting the main content in article tags and the blocks in aside tags, as well as header and footer.)

4. Resets: Bootstrap used to have its own reset but for version 2 they adopted a 3rd party project called normalize that takes a slightly different (and better) approach (see http://necolas.github.com/normalize.css/). YUI's Reset and Base styles are not only old-fashioned in that sense they also (and I literally couldn't believe they'd done this) add a horrid black 1px border round all table cells, working around which has caused weird bugs in Moodle (see https://tracker.moodle.org/browse/MDL-27774). This has, perhaps unfairly, turned me against YUI's reset more than the rational arguments at that github link. (Though #1 again, put the decision in the Theme, I believe there's already a bug open about this)

5. Components: (Note that Bootstrap calls some of there HTML bits'n'bobs components, I take it we're talking javascript widgets here) I'd express the perhaps luddite view that the less of these Moodle uses the better. The more like the web Moodle is, the more I like it. People sometimes get carried away with javascript and it starts to look more like a self-contained Java Applet than a web page. I'm far more interested in the HTML and CSS that Bootstrap provides than its JQuery plugins and think there's great value even without that part (though others seem to believe that's the best bit). Just to confuse matters I'll point to this (incomplete) port of Bootstrap's plugins to YUI: http://jshirley.github.com/bootstrap/javascript.html

6. Class names collisions: I've went into more detail in the related bug, but basically the Moodle classnames are semi-random, full of historical leftovers and often unnecessary if you a) organise the HTML well and b) only target modern browsers (IE8+), whereas the Bootstrap classes are clean, modern and well organised. I think the Bootstrap one's win, even when it's a bit of a pain to change the current Moodle ones. Again, even if you wanted to do something totally un-bootstrappy you'd rather start with their classes and HTML than what's there currently.

Since a lot of us are here in Ireland right now, I'd really like to make this one major focus of the hackfest on Thursday. It would be great to develop an agreed roadmap here that we can all help enable.

My own priorities are to have one consistent system in Moodle that is beautiful, responsive, consistent, performant, SUPPORTS PLUGINs and is long-lasting. A lot of themes may need redoing.

Please research and think about it! Post links and ideas here.

Could you clarify on "supports plugins"? I'm not sure what you mean by that.

I imagine what Martin means are all contributed third party 'plugins' like Course Formats, Blocks, Themes to name but a few, but generally anything that comes under Plugins Directory umberella.

Martin, thanks for supporting this initiative. It's great to see that many people are ready to help make this happen. I am overwhelmed by the support.

Good luck with the Hackfest on Thursday.

Yes, to clarify, we need to avoid solutions that require the core theme to contain hacks to fix all 3rd party plugins.

David I'm sorry you won't be here on Thursday ... I was under the impression you were here! Thanks for all the great comments from your experience ... anything more like that please write it here.

Hi David,

Thanks for coming back with those points. Its good to get a bit of discussion going here I think.
By the way I should point out that I am championing YUI, partly because someone has to stick up for past decisions, and partly because by getting these points discussed if we do decide to change then we can point people questioning any change to this discussion to show that we undertook such a change having properly discussed options.

Regarding your points 1 and 2 I still feel it should be core's responsibility to provide a "core" version of bootstrap.
I suppose the driving reason for me there is that I want to be able to use it in core. That means both core components and core plugins. It'd be great to convert forum posts to a more organised grid system (rather than the current mess).
Without a core version we could use the HTML structure we would not be sure if any of it would work as envisaged.
What I'm getting at is really that when developing something I want to know what the HTML I'm writing is going to look like. I want to know what is available to me for the version I am writing for.
For core output this isn't too important. We will know what is available as we know what is available for base.
The bigger concern is plugins as this affects not only core developers but anyone out there creating a plugin they will hopefully wish to share back to the community. Those devs will know the version of Moodle they are creating for and it'd be nice for them to have some confidence in what is being provided.
Now I understand your argument, and certainly you could get around this by having the base theme make use of bootstrap. However creating a theme without using bootstrap would lead to the developer having to reproduce bootstrap CSS to achieve the common look (because who knows what HTML has been used, we can only assume all). Personally if I was tasked with approaching the creation of such a theme I would include bootstrap and then make the changes I require in later CSS.
To summarise my views a little I see bootstrap HTML and CSS as a combination paired together one without the other only introduces more work. In effect the exclusion of bootstrap CSS from a theme would also certainly be the exception, and providing it by default a more helpful option.
Your argument that by requiring theme's to include it [bootstrap] they have more control of the version and playing around with progressing releases will be much easier is a very good point as well.
Perhaps the solution to that would be to provide a default, or "base" version of bootstrap in core that can be overridden by the theme (think of how we handle the images for instance). Through that means a themer would still be able to play around with version and we'd be able to have an organised structure for including bootstrap.
This way as well developers could bet on a particular version being available. It would however mean that should a theme include an alternative version of bootstrap that they would have to deal with any variations themselves. Perhaps that is the point my argument rests on in fact, who is responsible for dealing with the infinite combinations of HTML and CSS if we don't have a split environment coming from HTML in core and CSS in the theme.

Onto point 3: I really liked the simplicity of the bootstrap grids and I seriously think that if we were able to use them elsewhere we could achieve a more consistent look and feel much quicker. I know as a developer that really excites me as I'm not a designer
Again things like using grids to replace the existing structure of the forum posts is perhaps one example of a use of grids outside of theme layouts.
Tying this into the above argument having bootstrap in core makes this workable. Without the surety of having it there we'd create a situation of required replication in order to achieve this.
I don't disagree they form a small part of Moodle, but they have great potential I feel. I normally feel I spend way too much time on the small things - if we can shortcut the process on a few of them that would be great.

Point 4 - In summary complete agreement. Bootstrap reset is soooo much nicer than YUI reset... I won't even attempt to defend YUI's reset the table cell borders are an excellent example of why we should use bootstrap reset.

Point 5 - I'm a bit like you the fewer needless JS components we have the better. But needless is the key, components such as drag and drop are really great additions to Moodle I feel (both files and activities). I think the important thing to recognise is that they will be used... everywhere.. well way to much at least.
They are part of the package and I think adoption of bootstrap as a package is much better than just the part of bootstrap that we want at the time. Developers will use them. But that has its advantages, presently we have numerous navigation lists (my apologies I created several myself), we use countless links as buttons, and we our pagination is generally a mess. There's also the countless places we could minimise interface by hiding advanced navigation options using dropdowns.
If we accept that people will use everything available under the sun we can take comfort in knowing at least it will look consistent.
Heh not really in any form an argument to your point, perhaps we'd just need guidelines, use bootstrap over YUI if its available, don't use the bootstrap X component in core its not usable etc.

Finally point 6 - All valid points here, thanks for the work on identifying problematic areas. As I commented on that other bug I think altering core to not use such generic class names for specific actions is a wise move regardless of use choosing to import bootstrap in core.

Martin raises an interesting point in one of his earlier comments.
Is bootstrap the best front-end framework out there at the moment? what alternatives worth considering are there?

Many thanks
Sam

@Sam,

regarding "core" HTML...

edit: Actually i just re-read your point about this and I think I can sum it up by saying "The HTML and the CSS should both be coming from the Theme, the HTML via renderers" and note that this, to a large degree but with definite exceptions, is already true (or at least provably possible, I don't know how many people other than myself have pushed renderers far enough to see where they break, perhaps the MyMobile theme developer(s)). Longer, less clear, explanation follows...

So I think a key thing in my argument is that Bootstrap HTML (e.g. how they format a navbar or an alert message) is very good but is also 95% identical to any of the other frameworks you could name. They didn't invent it, it's just modern industry practice. However, the 5% is things like classnames (where obviously even a single character difference completely stops things working together) but the differences between two versions of Bootstrap are as big as the differences between competing frameworks. Given that fact, hardcoding these classnames seems somewhat shortsighted. Moodle's already put a lot of effort into the renderers system (and the layouts system), surely this is what it's for? Call a navbar() renderer with a list of links and get back the HTML, call a forum_post() renderer with a user and the content and get back a forum post. The renderer corresponds to the "thing" that every framework has, the HTML it returns has very specific Bootstrap v2.3 classnames and structure.

I'm already working with Bootstrap 3. It's in heavy development (e.g. they replaced the "badges" class for "counters" and then reversed that decision the other day) but it doesn't bother me because I have a unit tested class (several actually) that I call whenever I need a bootstrap component and I only ever have to change it in one place (well, I need to change the test's expected value too). And those classes are called from various renderers, so large swathes of Moodle change in one go. My renderers are much shorter and easier to read than the existing ones because they're more declarative, I'm not specifying what a list looks like every time I use one.

Locking ourselves to any current version of Bootstrap (and at the same time as ruling out Bootstrap 3 and 4, also ruling out Zurb and JQuery Mobile and whatever other weird and wonderful things come along) would be sad. And once you accept that, you don't have to worry about what the very, very best framework is, because if you do it with that understanding in mind the work you do will help all of them.

I actually tested this to some degree by writing a little function that intercepted all the Bootstrap calls and switched out the classnames for equivalent Zurb Foundation ones. It's not the way you'd do it for real but it demonstrated the principle.

Regarding the term "Core": So the problem about putting it in "core" (which is a fairly slippery term, are the "Base" & "Standard" theme core?) is what happens to all the core themes that don't use Bootstrap? Does 2.5 launch with one, hastily thrown together Bootstrap theme and break every 3rd party theme in existance? Or do we wait for 2.6 or .7 so that we can do it all with one big bang change where everything happens at once. And do we repeat all that when we upgrade to Bootstrap 3? Or... do we use the renderers system we've put a lot of effort into, rewrite Moodle piece by piece in a Bootstrap-based theme's renderers, while all the other legacy themes use the core renderers then, at some point, you cut'n'paste all Bootstrap renderers into core and cut'n'paste all the core renderers into a Legacy theme and it all mostly just works. Instead of rewriting the core to use Bootstrap, you rewrite it to use renderers (work which is already underway and progressing well) and since you've got both old and new renderers (possibly even some other variants) you can support both in parallel and let the adventurous take the hits so that it's solid for when the late adopters upgrade.

So since I'm not at the Moot I thought I'd lay out my vision here, in case anyone finds it useful.

So the first key point: my goal is to make the Moodle front-end better. "make Moodle lighter, faster, prettier, more consistent, more usable, more themeable, more mobile-ready, more responsive" as I said in a forum post about working on Bootstrap 3 based themes. Bootstrap itself is just a tool to achieve that goal, not an end in itself. The fact that it's got a "cool" buzz and looks nice (in an intentionally non-showy way so that it provides a foundation that can be built upon) and gets people excited for change helps, but in the end it's just a good, but mostly interchangeable, tool.

With that in mind I would really like to see 2.5 ship with a theme that includes a copy of the Bootstrap CSS. Importantly, this should be a direct copy of the upstream CSS that has not been edited in any way to fit in with Moodle (though some extra work-arounds in other CSS files will almost certainly be needed). I think having that unchangeable CSS will act as a guide for the evolution of Moodle core and provide a channel for some of the work that's been going on in the community. But apart from a few issues in core Moodle, I'd see most of this work happening in renderers, or in converting core to use renderers. Because if you can take that external 3rd party CSS that was designed with no regard for Moodle, and you can bend Moodle's HTML to fit using renderers then that basically proves that Moodle is "themeable". My experiments show that Moodle is perhaps 50-70% themeable on average(with bits like forms down at 10%, but other bits with renderers much higher).

And when I say "ship with", the key idea is that it becomes part of the QA process so that bugs or issues that can easily be fixed in both Bootstrap and Standard themes (even if it's not a visible problem in Standard themes) get found and fixed.

Now it's entirely possible that people will take shortcuts and just bash out stuff that works with that particular CSS file and fail miserably with any other theme (just like they currently do with Standard theme and its not-very-varied variants), because people are like that. But running it in parallel with the legacy theme minimises the chances of this, and even if they do the resulting code will still be 95% good. But the main effort should be in converting code to use renderers and writing renderers that implement Bootstrap HTML (with at least half an eye on accommodating changes for Bootstrap 3 or other frameworks).

I think there's a thousand other things related to this that you could have opinions on and arguments about, and I'm sure people will, but the window for getting stuff into 2.5 is closing. I'd really like it if a theme with that untouched CSS file got approved for inclusion in core 2.5 before all the other debates begin. It's all too easy for nothing to happen when people who broadly agree get hung up on the last few items of disagreement.

David Scotson When Sam says "in core," he doesn't mean like the base theme. He means like YUI. You can see that YUI is packaged in Moodle core, in /lib, not in /theme or anywhere else that plugins are placed. That is what he means. He means that a version of bootstrap would be packaged and served from /lib, and we would manage and update it as a library that is part of "core Moodle." I agree that that would be a good idea. Even if theme designers choose to change versions to meet their immediate needs, we do need some sort of baseline, something developers can depend on.

It sounds like Sam's vision would be to incorporate bootstrap into core and then revise core renderers to make use of boostrap grid system and components. I think that sounds like a good plan.

David's vision, of doing everything with renderers in the theme, leads to an ever-complexifying workload for theme designers, where writing renderers is part of daily practice. I'm not sure we can or should expect that from the individuals Mary helps in the Themes forum.

Further, I'm not sure that some of the inconsistencies I've seen in core are accessible to renderers, if the original output is not using a renderer. Others are using renderers, but the wrong ones. It might be possible to catch those with a theme renderer. But what really needs to be done is to go through and make core consistent. It makes sense to adopt a framework, update renderers to use the framework, and then clean up the places in core where neither renderers nor framework are being used.

@Amy

Do you plan to achieve the switchover from current core to a Bootstrap core in time for shipping as the default theme for 2.5? This bug started for discussing getting a usable, though not default, theme into 2.5 (which I believe is more than possible, I think it would be pretty good theme, though far from perfect) but I don't know if every suggestion is keeping within the boundaries of that assumption.

You're right there are large areas of Moodle that are not using renderers (e.g. forms, or mod_glossary, the login page etc.). When you say "clean up" these areas are you talking about converting them to using renderers? And if you are, why does it matter whether the actual renderer file lives in a theme directory or not? I think my suggesting and Sam's are largely the same with some fairly subtle differences in intent that'll affect some implementation details, so I'm not sure I've explained my idea very well if you're left with the impression that people asking questions in the Theme forum would be forced to write renderers on a daily basis with my idea but they won't if we move those same files into a different directory.

The main reason I want them in a theme directory is so they can live in harmony with a) the current "Standard" renderers, b) other renderers such as the MyMobile theme, and importantly, c) the renderers that come to replace them as the "default" at some time in the not so distant future.

It is, as you say, a question of what developers can "depend on" and I'd quite like the design to be decoupled to such a degree that Moodle can cope with more than one theme at a time, which basically requires people to work through an interface rather than make assumptions that the internals will never change. I had assumed that renderers were developed for exactly that task and, where they are actually used, they seem to be achieving it quite well.

Aha, Amy is correct in reading my woffly comments.
When I talk about core I talk about everything in Moodle that is not a plugin. All themes, modules, blocks etc are plugins and are excluded.
My vision is that we provide lib/bootstrap. It is loaded with all of its requirements in the same style we do for YUI and theme's would be given the ability to provide an alternative version should they choose.

It would be ideal to convert all output to renderer. That would be a long and arduous journey.
I'm suggesting that first we go through the renderers we do have and change their output to use bootstrap. The output is already organised in renderers so that would be a quicker process.
As for hard coding the class names, yes I think that is required. If we require theme creators to override renderers in order to integrate a front-end framework then we have already pushed theming out of the reach of many people.
If we use bootstrap HTML we need to have a targeted version otherwise we are going to end up with a horrifically tangled mess within just a couple of versions of bootstrap.

Just for interest sake Moodle ships with around 300 enabled plugins, an additional 60 disabled plugins, and has around 60 core subsystems. Each of those can have a renderer, some will have more than one, and hopefully one day will many will be making use of renderers (although there's very little active work in that area).

This couldn't happen in 2.5, I don't imagine we would have nearly enough time to address this.

Adding your bootstrap theme to core is an option, and it would provide a good example for anyone else wanting to create a bootstrap based theme.
But if we are going to adopt bootstrap into the base theme, or replace base theme with a new theme then I think the above plan needs to happen.
The same goes if we intend to create a bootstrap base theme.

You are right, we can debate everything to death and get nowhere very easily.
It is important to have a direction however, and that's what I would like to see come about.
In adding a bootstrap theme which direction are we taking a step in?
Ending up with a front-end framework for Moodle is a good goal, and that is what I've structured by view of this issue around. However perhaps the goal is to get a bootstrap theme into core as an example of what can be done, in which case I am just holding up the process
Either way the step of including a bootstrap theme is an easy decision if all we want is a theme in Moodle that uses bootstrap. That would get my +1. As soon as we consider taking it further we need a proper plan.

So I'll leave it there and just see what else comes out here.

Somewhat off topic in reading through the discussion here I was reminded of the idea of weltanschauung and enjoyed reading back through http://en.wikipedia.org/wiki/World_view

Many thanks
Sam

I'll keep this brief, as there is a lot of discussion about future development regarding a Moodle Bootstrap in CORE, as opposed to a theme, and I don't really want to miss the opportunity to get a new theme into Moodle before the launch of Moodle 2.5.

I was thinking of starting off with Bas Brands bootstrap and adding a grid layout, and then building from there.

Has anyone got any better ideas?

Just adding my two penny worth - I've been following the discussions in the forums and here for sometime with interest.
My personal opinion would be that Sam's idea of getting bootstrap into core alongside yui is the long term way to go but is an enormous job to do it right. The idea of getting a bootstrap theme into core in the meantime would be a good starting point along the roadmap, but currently it needs to be alongside the existing Base, rather than replacing it - and that this should be a goal for 2.5. I would vote with Mary's suggestion of building a 'bootstrapbase' from Bas' work with a grid layout added as the most effective way of producing something meaningful in time for 2.5

Good luck to everyone at the mootie hackfest tomorrow. I hope it gives some direction and progress towards the goal of getting a bootstrap theme in core as soon as possible

Richard

I don't really understand this bootstrap thing, but it has been really great watching while all of you who do understand it experiment. The experimentation seems to be going well.

However, it still seems rather experimental, so I am hesitant to add a new theme to core now. If you add the theme now, you have to support it forever more (approximately).

The main reason for doing this seems to be to provide 'an example' or how to do it. Why can't the example, or examples, just be in the themes database and on github. I don't think it needs to be in core. If it stays outside core, you have more freedom to continue experimenting until we have decided the right 'direction' which can then be done in core.

I'm with Mary here. Two very different discussions to be had and maybe for that reason two tracker items.

I too would like to see Bas' theme make it into 2.5. It is incredibly polished and could be used as a parent theme by other designers in the short term.

A separate discussion on the use of this as a library or changing renderers I think is an issue for a whole new ticket. Don't want to take away from the discussion (and I am following with great interest), but maybe we could relocate to a new tracker item

@Tim

my reasons for wanting it in 2.5 (even if marked "danger experimental!") are:

1. people currently using (i.e. live with students) bootstrap-based themes are shying away from using renderers because they want to stick close to core (I'm thinking of Alfonso at UCLA in particular as he mentioned this recently but I'm sure there's more, as it makes me very nervous too) which is slowing progress and fragmenting the developer base effort.

2. I'd like to know what Moodle HQ is working on in this area and help them to help us (it seems Sam has already independently rediscovered a bunch of bugs that others had already found).

3. I'd like the current energy around bootstrap to have some kind practical focus on something that is currently usable. For certain measures of "usable" various Bootstrap-based themes have been that for awhile and they get better every single day. An official moodle stamp and signal that "this is quite probably the future" would be very useful in harnessing and accelerating that process. This also comes with the need to make hard decisions about what ships and what doesn't, which is something Moodle core already has processes for doing (bugtrackers, QA routines etc.).

4. We're at the point with Bootstrap-based themes where the next steps are a) fixing core bugs that affect Bootstrap, b) writing renderers. I feel that if Moodle isn't shipping something that is affected by a "bug" then you could easily argue that it's not a bug at all. And I already covered the latter issue about renderers in point one.

5. Another point about renderers. We're writing code here. I assume Moodle HQ has a whole long list of unwritten rules about and opinions on what they want "their" code to look like. Writing "our" code out in the wilderness and then trying to integrate it later seems sub-optimal, I'd rather get the issues out in the open straight away so they can be sorted up front.

If all that can be achieved by nominating some github repository as the (semi-)official Moodle Bootstrap theme, adding a Bootstrap component to the bugtracker, decree-ing that bugs that affect this external theme really are actually "bugs" that Moodle HQ wants fixed in core, nominating Moodle HQ folk to review that code etc. then great, no need to put it in core. But at that point it might well be easier just to include it as one of the themes in the standard distribution since you'd be doing it in all but name anyway. (Again, put as many warning stickers on it as you need. There will be bugs, part of the reason I want it there is to find them.) In fact:

6. Wider exposure and bug testing is required to shake out all the little bugs.

And just to re-iterate on my point that whatever way the discussions go, doing this small thing of including the theme in time for 2.5 is a win-win-win situation: even if Moodle decides to rewrite the whole front-end in Bootstrap for 2.6 or 2.7, a whole bunch of that work will need to be done in renderers. And almost all of those renderers can (and would) be used by current Bootstrap themes. We're basically offering you an extra 9-15 months of real world testing on your code before you release it (in fact we'll write it for you too if you let us).

So it seems that the most meaningful part of my previous comment was "I don't really understand this bootstrap thing". Looks like you have good reasons for what you are proposing. I'll go back to lurking here.

Regarding plugins: are we all aware that plugins aren't a problem for adopting a theme like Bas Brand's (or equivalent)? It just inherits from the Base them and includes the Bootstrap CSS over the top. So unless the plugin is using CSS like .hidden to mean something other than "hide this item" (Currently in Moodle core you have .hidden to mean "hide this completely", "don't put a border on this", and "display this dimmed" in different places so it's entirely possible.) then there's no issue at all. You just get what's currently there but with slightly different fonts and buttons.

And the little name clashes are already being found e.g. the 3rd party turnitin module uses the rather redundant classname .row on tr tags, Bootstrap uses the same classname for it's grid. This results in the table rows being shifted over to the left a bit. Not a big problem and very easy to fix, but the plugin developers would probably be more motivated if they thought this was something Moodle HQ was requiring them to do rather than some crazy themer who could (and currently do) just workaround it in their theme.

David,

Perhaps as you know so much about Bootstrap, you could start the ball rolling an devise a theme you feel is what Moodle needs.

Mary's off to the shops to calm down.

+1 For an Experimental theme's section just like 'Site administration' -> 'Development' -> 'Experimental'.

Code can be cleaned / checked against Moodle HQ standards using 'code checker' -> https://moodle.org/plugins/view.php?plugin=local_codechecker

Although I would like this in core, pragmatically it is far quicker to make developments using contributed code when dealing with uncertainty. But having said that if there was an 'Experimental theme's section' with the caveat that it may go in the future then that is a greater vehicle for exposure.

If 3rd party plugins are causing conflicts because some of their elements are in core, then there is now a precedence for removal through tracker -> MDL-37749 and https://moodle.org/mod/forum/discuss.php?d=218947.

Cheers,

Gareth

@Mary

I think Bas Brands' theme (which I know you're familiar with but others can demo here if they're not: http://theming.sonsbeekmedia.nl/) is the best place to start from.

I think you stated earlier that it was your preference too. It seems to be the one that most people supporting the original bug ("add a theme to Moodle 2.5") are meaning, maybe that could be made more explicit if the bug gets split/edited?

We're discussing bootstrap now at the Dublin hackfest. Join us at http://www.youtube.com/watch?v=w_2v56R0uNU&feature=plcp

This worries me: http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html - It looks like the proposed Moodle boostrap theme is doing exactly this bad practice.

If the You-Tube is live now then I am agreeing with what Martin is saying re adding the B/strap CSS to Base.

What's the summary of that please Mary?

So I was having major tech difficulties this afternoon and so couldn't hear any of what was being discussed on the Hangout (well, I could hear Alex and Amy, but no-one else). But I've just listened to the full recording on Youtube.

It all seemed to go quite well, and I agreed with the general consensus at the end so my input would have been a bit superflous anyway.

Two tiny little comments on some of the later tangents:

On the topic of LESS, I've integrated a PHP port of the LESS compiler into my Bootstrap Renderers project. Which means that rather than run an external tool on the server, it acts like a souped-up version of the current CSS file concatenation in Moodle. I think it's got wider potential for use in Moodle so if anyone wants to discuss that, drop me a line or start a new bug or forum post about it and let me know.

Regarding forms, the title above the input "single column' format that was discussed is actually what Bootstrap does by default on smaller screens e.g. portrait iPads, iPhone. This doesn't automatically happen in Moodle Bootstrap themes because the form HTML isn't what Bootstrap is expecting, but I have some CSS that makes it work in my Bootsrap Renderers dev theme.

David Scotson I really like the idea of a PHP port of less. Maybe we should have a new tracker ticket to discuss/implement that?! It sounds like even Tim Hunt was willing to throw down for LESS. Are you using http://leafo.net/lessphp/ ?

I created a new tracker ticket to look at php for css preprocessing: https://tracker.moodle.org/browse/MDL-38160

@Gareth what do you mean by summary? Did you mean what are my personal reasons for agreeing with Martin, or something else?

If you want to know why I agreed with Martin, it was because of something he said last year, when I was trying to fix base so that it worked in RTL mode in IE7

I proposed something similar to what we are trying to do here, and again Martin said something similar but not so directly.

Martin Dougiamas added a comment - 18/Apr/12 1:19 PM (Quote from MDL-32412)

Based on a quick read: if the issue here is that the base theme needs fixing to make it work better with RTL, then let's fix/replace the base theme. I don't think adding a new separate theme sounds like a good idea. It was already made confusing enough with the introduction of Canvas.

Which still holds true today.

As it was I ended up changing Afterburner instead, so that the RTL community in Israel (where, believe it or not some schools still use IE7) have a theme that works.

Mary Evans You said "If the You-Tube is live now then I am agreeing with what Martin is saying re adding the B/strap CSS to Base." - I wondered what Martin was saying?

Oh...I thought everyone was watching the Hackfest 'Live' video. Martin opened the discussion and said he thought the best place for B/stap CSS was Base theme, my comment, about agreeing with this was what I wrote in the comment box on the You-Tube page, and in the Tracker as I thought they were reading that too. But apparently it was only seen by those who were watching the same video! LOL I was darting between that and chatting in Dev Chat, and then reading notes someplace else. I eventually got to the 'Hangout' just as they were closing the discussion! It was a lark...because my WebCam didn't work (it's not compatible with Win7)...so I didn't even have chance to say anything.

Thanks Mary - I was working away on a theme issue so could not divert my brain at the time. It would be good on reflection if bootstrap was in base as a style that was not on by default but could be used as required in the config.php file. Even better if jQuery 1.9.1 with 1.1.0 migrate JS (for IE 6/7/8) was in base too for all theme's to use.

Cheers,

Gareth

Further to my lost comment gareth, the thinking now is that the Bootstrap theme will be a theme in its own right, but use base as a parent theme much the same way Standard theme works.

I'm about to put this all together and submit it for Peer Review over the weekend.

Bootstrap in now up for Peer Review.

Hi All,

It was amazing to see how many ideas were discussed in this thread and it was very nice to be at the hackfest to discuss the Bootstrap theme.

Before the theme is really reviewed by HQ for the possibility to have it in core it needs some cleaning and some of the extra features need removing.

There are also a list of issues that will need to be fix and actions to be taken.

I think these are:

1. replacing boostrap jquery libs with yui libs
2. fix the layout of the file manager on mobiles
3. enable docking and fix the layout for docking
4. remove all unneeded renderers
5. check CSS in bootstrap_custom
6. test on many devices / browsers
7. create a backwards compatible version for 2.1 - 2.3
8. do performance testing comparing bootstrap with standard.

I have added a dev and test branch on github to test yui stuff and try some of the less framework magic. Hopefully I will have some results at the end of this week.

Hi Bas,

Thanks for the update.

As for creating a backwards for 2.1 - 2.3 this wont be happening for the following reasons:

1. if approved your 'bootstrap' theme will be added to Moodle's master branch, meaning it will be in 2.5 when it is released and in future versions of Moodle from then onwards.
2. we have not been updating 2.1 and 2.2 for sometime now. After 2.5 is released then 2.3 will eventually experience the same fate, and like earlier versions will only get security updates.

Hi Bas,

Is it possible to take a Fork from git://github.com/moodle/moodle.git so you get git://github.com/bmbrands/moodle.git

This way you can create a branch wip-MDL-39016-master based on your forked copy of Moodle/master and then push it to your GITHUB then I can link to it from this tracker issue using https://github.com/bmbrands/moodle/compare/master...wip-MDL-38016_master

Thanks
Mary

A summary of the plan we came up with at the hackfest last week:

1. Add a /theme/bootstrap which will be a little like "canvas" in that it is intended to be a parent theme for others to build on.
2. Include standard bootstrap CSS in this theme, plus a separate file with whatever Moodle CSS hacks need to be made on top.
3. Include layouts in this theme to implement the responsive design of bootstrap, but with a 2,1,3 order in the HTML.
4. Include renderer overrides as necessary in this theme to implement bootstrap-specific HTML in places.
5. Wherever possible, update renderers in core if it doesn't break themes much, and the HTML is not bootstrap-specific.
6. Add new renderers in core to solve other HTML problems (see 3 and 4 above).

I'd really like to see as much as possible of this in 2.5 already.

(I've not looked at your latest code yet Mary but hope others can start doing so already)

Thanks martin,

I was hoping to get Bas's latest version so that I can amend it to your above specifications.

It should not be too difficult.

As for the 2,1,3 design I could use the Holy Grail Percentage layout which I used in Afterburner which would convert to being fully responsive as there are less layers.

Note I am not 100% sure if 2,1,3 is necessary with all the ARIA support in Bootstrap, it just seemed like a good idea to keep it, and I like putting blocks after content on small screens anyway. Is anyone an expert on this?

I'm not an accessability expert but I did think that using HTML5 tags, particularly "article" for the main content but also "header", "footer", "aside", "nav" to mark up the relevant sections of the page and aria tags for more specific semantics was more important than their physical location these days.

For visually moving the blocks below the content on small screens I was discussing this with Lewis Carr and one approach we discussed was to have a sub-theme that inherits from Bootstrap and makes the tiny change of tweaking the layout.php file and putting the content in the order you wish to display it (both in HTML and on screen). This sub-theme would then be fed to mobile devices via Moodle's user agent detection script.

It's not quite as cool as resizing your browser window and having everything jump about, but it's simple and it works.

iPad sized devices are an awkward middle ground, but I have some media-query CSS that allows you to have columns on both sides in landscape mode and collapse them into a single column in portrait orientation (though this doesn't affect the source ordering, just the visual display).

Another approach is to auto-collapse the upper blocks on small screens.

The problem now is that you are running the risk of the Bootstrap theme turning into a Camel.

Surely the solution to having a theme that works well enough on a small screen, I'm talking Mobile phones here, not Tablets as they work OK with some normal theme like Afterburner and Magazine, would be to design for a Mobile device and then expand back up to a three column theme.

A simpler way would be to have two Bootstrap themes. One for a Mobile device the other as a Moodle default theme.

Otherwise what is the point of having a theme selector that allows different themes for different devices? Besides, you are very limited to what you can do on a Mobile phone when it come to Moodle. I certainly would not want school children to be ruining their eyesight just so they feel they are 'cool' and 'hip' with the latest mobile where they can do all their homework on. How stupid is this all getting!

I don't see the point of multiple themes if we are moving to a responsive design. The device based theme selector is a hangup from the early days of displaying for different device types, but if we have a single responsive theme that resizes based on screen resolution then there is no longer a need to select by device type. That's what I do with Bootstrap already - I use it as the default theme and don't select any device specific themes - there is no need to. It becomes a redundant feature.

Moodle is not limited on a mobile phone, I would say the opposite as all sorts of opportunities open up. I don't think anyone would suggest sitting through a full course on a phone, however for any short tasks that require 15 minutes or less, then smartphone is perfect. Taking fieldwork photos and uploading them to a database activity or blog, subscribing to a blog feed or podcast, accessing downloadable handouts to review later, accessing messages, there are all sorts of tasks that schoolchildren / students / employees can use their smartphones to access Moodle for.

this is how to do it with pure css and some clever classes in php (using the column drop approach)
https://docs.google.com/document/d/1MK9jFXdKSh85K99iBLhdr80OkkqX5WmkJh9Xi_Z0q3g/edit
i don't have time to code it this week though
happy to talk it through with anyone via g+ chat!

You could also look at some off canvas stuff like http://www.zurb.com/playground/off-canvas-layouts uses
(bootstrap implementation here - http://codepen.io/krichnafsky/full/cuhkL)
but maybe thats for after....

I like the codepen bootstap example where the blocks are optional, and view them by clicking on the icon in the header. Problem of course is that it needs jQuery which seems like a no-go area at the moment.

Can anyone find a link to an accessibility expert saying that these new fangled grid systems are bad because... [fill in reasons here, though specifically the lack of source ordering for content].

I've had a quick google and can't find any, which kind of surprises me because basically everything is thought to be bad for accessibility by someone. I've been using "source order" as the search term, maybe there's something better?

(I did find this link, that claims you can do it in Bootstrap just by adding pull-right and pull-left classes, basically floating things, but I tried that when I first started with Bootstrap grids and it messed up the very specific left and right padding/margins that Bootstrap puts on the columns:

https://groups.google.com/forum/?fromgroups=#!topic/twitter-bootstrap/etZK4BERci8)

Is it perhaps possible that source ordering, while maybe nice, isn't really that important to accessibility? If it came right down to it I think I'd rather lose one of the columns of blocks in Moodle, than depart too far from the standard grid supplied with Bootstrap. But if we can just do both then that's good, so worth looking into.

So... this is the top Google result for "Source Order":

http://usability.com.au/2006/01/source-order-skip-links-and-structural-labels/

A bit old in internet terms, but still, they've done actual research. Key quote:

"This paper proposes that when it comes to accessibility, the quality of the actual code on a web page is much more important than the ordering of the page content. Meaningful and appropriately marked up headings, descriptive link text and the clear identification of different levels of navigation, allow screen reader users to most effectively use their technologies when visiting a website."

Also, if you have a look at the source of this particular 3 column layout, you'll notice that the nav column comes before the central content column:

http://www.w3.org/WAI/

Some food for thought, anyway.

So following the train of thought of the previous comment, I looked up the actual guideline that a few of the posts were quoting:

http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms

It seems it may have been rewritten at some point around 2008 as it no longer seems to recommend putting the content first in the source (assuming it even used to) in fact quite the opposite (tl;dr: the source should match the visual order, top-to-bottom, left-to-right):

http://www.w3.org/TR/WCAG20-TECHS/C27.html

What it does highlight though is that your tabbing order, headings, skip links and other metadata about context and ordering should work properly as that's how people using non-visual tools will interact with your web page, not directly through the HTML code itself.

I always thought the source ordering (2,1,3 layout) was more about search engine optimisation than accessibility David?

@Richard

That does seem to be the main reason given in recent times, but older web pages talk about both as if they were one and the same.

To be honest I'm a bit dubious about the SEO advice too, it wasn't considered important enough by Google to make it into their 32 page starter guide for SEO, so if I was in the position of worrying about SEO, then I'd have plenty of other stuff to keep me busy:

http://googlewebmastercentral.blogspot.ch/2010/09/seo-starter-guide-updated.html

as well as accessibility and seo having the content first in the html is a big win on small screen.
http://www.lukew.com/ff/entry.asp?1514

did the doc i linked to above make sense in terms of how this works with bootstrap?

@Richard the 2,1,3 layout was, according to Sam Hemelryk one of the reasons Moodle opted for that style, was chiefly for Accessibility. Using nothing but the Keyboard click on the TAB key and see what happens. You should be able to navigate using Tab and Arrow Keys only.

Further to my last comment. Trying to navigate through the menu here in this page, is next door to being useless for the menu. Although the Tab takes you through the menu items none of the dropdowns work as they do in Bootstrap. The rest of the page is pretty much OK...I think.

I just found something out.

Tab Key = Navigate (LTR)
Tab Key + Shift = Back
Return Key = Select (Opens menu!)
Arrows = As indicated

So it IS more accessible than I first thought.

content first column drop html&css bootstrap layouts - https://dl.dropbox.com/u/256711/content_first.html
can be easily generated dependent on $hassidepre, $hassidepost etc...
view source.

+1 for Mark's comments above ... themes should be responsive across devices and we shouldn't be relying on Moodle admins setting up different themes for different devices. That really was just a stopgap solution.

For fully responsive layouts, including sidebars dropping below content, checkout the work in Danny's Zebra theme. He's also ported it to a separate layout scheme independent of Moodle. Its quite straightforward to adapt, so should be capable of being used with bootstrap quite easily.

@ Stuart,

ah, it's obvious once you know the answer! Very nice.

I'll put a pull request for that into the DEV branch on Bas's github if that's alright?

@david - phew - glad you got it, i would be a rubbish teacher
pull request would be super, thanks.

can do a css off canvas, but i'm unsure its suitable for moodle at this stage. Blocks need sorting out before that will work...

@ Stuart,

I've submitted that here:

https://github.com/bmbrands/theme_bootstrap/pull/31/files

I didn't implement the two blocks on the same side, just the standard three column, 2 columns with blocks-left/right, and no columns (though if that's something people use in Moodle I'll do it).

Seems to work just fine, the only thing I noticed, and you can see this in your demo version as well, is that the two blocks that swap places don't have any vertical margin between them when collapsed down. Might need to clear the float, but only when collapsed.

@david - good spot,

i'm quite into having the .first and .right classes, it means you can re-use them elsewhere. Other grid systems like less use .last and other similar patterns.

having the right floats applied to a span number inside a generic row-fluid cuts off using that span in a fluid element anywhere else in the site. Hope this makes sense...

now let me clear that float...

http://www.dailymotion.com/video/x1f2t3_dj-kool-let-me-clear-my-throat_music#.US5jki15yfE

@media (max-width: 767px) {
.row-fluid [class*="span"].right

}

Also please make sure to test with a RTL language enabled, like Hebrew or Arabic.

Does anyone here use a RTL language to help us test?

If not, is there any existing test instructions for Moodle to help LTR people know how and what to test?

edit: And for some more long term ideas on RTL see the discussion in https://tracker.moodle.org/browse/MDL-35084

My normal approach to RTL testing is to just switch one course to Hebrew or Persian or Farsi, and then play the game of 'can I still use Moodle?' It's quite fun. It is also an interesting way to look at the usability of your application in a new light. I mean, we always say 'users never bother to read on-screen text', but how far can you get if all the on-screen test is incomprehensible (and the UI is reversed to boot).

@stuart

For the float thing I tried flipping the media-query and put the column swapping inside min-width: 768px since it seemed silly to be adding and then removing CSS when the mobile case works out of the box (bonus points for "mobile first" buzzward compliance too). I'll probably need to specify the rule for .ie8 (& .ie7?) as well though since it ignores media query which reduces the elegance of the solution somewhat (oh, I need to add the html5shiv too, now that I've added HTML5 tags). What do you think?

https://github.com/ds125v/theme_bootstrap/commit/3414444d9d3719fce67b4f4ac451177f02cd6a76

I also made the rules for adding the float more specific. Do you have any explanatory links for what .first and .last would do? I'm not sure I'd want to encourage anyone else to be messing with the order of display beyond the top level.

Also, your phone solution broke the hack I was using to combine the two block columns into one to give the remaining two columns more room in portrait iPad dimensions. Any bright ideas? Perhaps slide the right column "off canvas" once you get down to a certain width?

I opened an issue about feeding some of the renderer changes back into core, in case anyone is interested in following what the process might look like:

https://tracker.moodle.org/browse/MDL-38260

Had a quick look at it in RTL, there's a couple of issues that are obvious even to me and which are no big deal to fix. I think it might take someone used to using RTL to spot further issues beyond those.

I have already added our current RTL expert, Nadav Kavalerchik who has done countless fixes for Base theme. So don't worry about that.
What we could do with is a seperat rtl-undo.css so that we can lump all the RTL css in one place.

For reference All RTL CSS fixes are prefixed with body class .dir-rtl.

I am watching this issue silently. And was actually waiting for the (magic) dust to settle down before I fix and RTL issues. If you all think it is the right time to get involved, I will be happy to jump in with fixes and testing ( I was busy with other parts of Moodle lately, but I am coming back to all the RTL issues that I already marked and assigned to myself. )

Adding RTL label to this issue, so I can see it on my "RTL Todo" list.

@Nadav,

Any idea why these lines don't use the .dir-rtl class? (too early in the install process maybe?):

https://github.com/ds125v/theme_bootstrap/blob/24_dev/less/core.less#L1137-L1149

(that's a lightly modified version of core.css from the base theme).

Currently they're floating right something that's not floated left in ltr, so the behavior differs by more than just which side it goes to, but I don't understand what those lines are doing enough to fix it.

The link in the previous comment no longer points to the right place as I've reformatted those files to make them easier to work on.

The lines I'm wondering about are these:

html[dir=rtl] .breadcrumb,
html[dir=rtl] .headermain,
html[dir=rtl] #page-header {
    float: right;
}
html[dir=rtl] .formrow label.formlabel {
    float: right;
}
html[dir=rtl] .configphp {
    direction: ltr;
    text-align: left;
}

@David there is no point in doing any RTL fixes until we have an updated copy of Bootstrap to work on. I've asked Bas to create a branch off Moodle master so that we can get something ready for testing.

Is anyone familiar with rewriting core code so that it uses renderers?

I'd like to do that as a first step towards making the "tabs" API and output in Moodle a bit simpler and more consistent. But the documentation doesn't seem to cover that particular case (it does cover using existing renderers in core code, and overrulling renderers in themes, but not how to move stuff from lib/weblib.php to a renderer. It does kind of suggest that there shouldn't be anything left in weblib that echos output directly, since it should have been moved to lib/deprecatedlib.php, but there is in the tab functions, as far as I understand it.)

I've opened a bug about it here, any help welcome:
https://tracker.moodle.org/browse/MDL-38309

regarding jQuery modules:

• someone has already ported several of them to YUI: http://jshirley.github.com/bootstrap/javascript.html
• I think we'll need to extend our YUI build to full use them though

regarding a responsive 2-1-3 template:

• Yes it's primarily for SEO
• Yes it makes using Moodle "easier" on a small screen (at least for consuming)
• I've already created an HTML5 2-1-3 responsive template based off the one Moodle Base uses, we could use it as a starting point:
  https://github.com/thedannywahl/Antioch_HTML5
  http://htmlpreview.github.com/?https://github.com/thedannywahl/Antioch_HTML5/blob/master/index.html

Hi Danny,
Just pointing out that Base theme uses a different layout than the one you linked to, although they share the same Holy Grail name, Base uses the Holy Grail Pixel layout whereas you have used the Holy Grail Liquid Layout (percentage layout) which is the same as Afterburner

So if we want a liquid layout to start with we could use theme/afterburner/default.php and your @media responsive design as a base from which to build!

Hi Danny - I did refer to your layout work (which I am a big fan of) in this discussion back on 27/2 but it wasn't picked up on and headed off in a different direction at the time

I still think, as I have mentioned before, that someone needs to draw a line around what the expected progress is for this for getting it into 2.5 or further down the line. It seems to me that the idea is growing and growing - not necessarily a bad thing - but that this 'feature creep' is going to result in nothing being ready for 2.5.
Please could we have some direction on what is planned for what stages of Moodle development: is the aim to get a basic theme incorporating bootstrap css with (possibly) reusing existing layouts, whether those are from afterburner or zebra or wherever, ready for 2.5 with future devlopments to refine/replace/extend core renderers, or is the aim now to forget 2.5 and essentially get a full bootstrap theme in place for 2.6+ including all the renderers?

Does this tracker need to be split, or am I on the wrong track altogether with my understanding of the aims/timescales of this discussion?

Richard

David Scotson, the RTL CSS rules you refer to

html[dir=rtl] .breadcrumb,
html[dir=rtl] .headermain,
html[dir=rtl] #page-header {
    float: right;
}
html[dir=rtl] .formrow label.formlabel {
    float: right;
}
html[dir=rtl] .configphp {
    direction: ltr;
    text-align: left;
}

are used on the "Install pages" during the install process. where there is no theme selected (it seems like theme/standard is selected but it is not a real full theme. see install/css.php)
So, the above rules, justify some of the fields and labels to the right.
Actually, some seems to be missing. I remember I added more rules.

btw, how about adding http://designmodo.github.com/Flat-UI/ ontop of bootstrap ?
(hope I am not throwing too much wood into the fire )

Regarding 2.5, the freeze date is the end of March, so not too much time to get it in.

I would suggest aiming to have a simple, clean and functional /theme/bootstrap as ready as possible in two weeks, which would allow two weeks for it to clear integration and perhaps have a few more fixes before being integrated.

Nadav, I suggest you should do a /theme/flatui which uses /theme/bootstrap as a parent.

Sure, let's not push too much

I will have a go with /theme/flatui which uses /theme/bootstrap as a parent.
And let you all know how it goes.

@ Richard everything is in hand, pleas don't worry. The idea is to get a Bootstrap theme in place before May/June when Moodle 2.5 is released.

Currently I am waiting for the OK from Bas Brands who is working on updating his version and getting it ready for Peer Review. Until that happens nothing will be done. If it does not meet the deadline then we will push for 2.6.

I suppose, I could always add a copy of my Tiny bootstrap, that Amy and I have been working on, if that's what people want to see?

At least we would get some feedback from HQ if this is the kind of thing they want in Moodle.

Of course there are other aspects of Bootstrap, like responsive layouts, form controls, typography to name only a few of its components. Not to mention the work, in Moodle itself, with renderers that are major if we are to develop a Moodle bootstrap, so that in time we have a sleek, intuitive, and powerful front-end framework for faster and easier web development.

We have already split this to deal with other aspects of Bootstrap. I think David linked to it.

OK...so now we have less than three weeks.

The Bootstrap theme found here (in a dev branch of Bas's Github):

https://github.com/bmbrands/theme_bootstrap/tree/MOODLE_24_DEV

is pretty much ready to go. It has the 312 layout (using Bootstrap's own grid), responsive forms etc.

I think the only real showstopper is the drop-down menu (and that header area at the top of the screen generally), which needs to be hooked up to YUI instead of the JQuery but I think Bas is looking at it.

It should be ready for wider testing this week and submission into whatever process you go through to get into core but if you're the kind of person that comments in bug trackers I'd suggest git cloning it and having a poke around right now. Remember to file any bugs you find.

And regarding Flat UI, we've already got all the swatches from http://bootswatch.com working nicely. Flat UI would work almost as easily since it's the same idea. If Moodle's HTML matched bootstrap's (which is a long term goal) then you'd be able to just add the CSS and go. Since the HTML isn't (yet) like that, you need to do a bit more work, but all the hard stuff is done for you. There's examples to follow in the less/bootswatch (at least in my tree, not sure if it's in Bas's yet). The bigger complication is that Bootstrap and Bootswatch use LESS, while Flat UI uses SASS, which are two different takes on the idea of a CSS compiler, so some translation may be required.

edit: about the branch name, 24_dev, the theme should work on 2.3/4/5 and perhaps even earlier. There's been a few minor bug fixes in 2.4 and 2.5 core, but since the workarounds were already thought up and put in place there's no reason why the theme can't be used in older Moodle versions too.

nice omni template for bootstrap http://viget.com/inspire/an-omnigraffle-stencil-for-twitter-bootstrap-2

@David: Do you know if we can modify some of the less bootstrap variables to fix the minimum and maximum block width? Currently the calendar overflows the block boundaries and block regions are very big on wide screens.

@Bas,

I think media query tweaks can solve most of those problems, variables are a bit a heavy duty change for this, though I should note that personally quite like the look of the wide blocks (though again tweaks can make it look better).

For the calendar there's padding in the day cells of the table that can be reduced to shrink the whole thing as the screen width reduces to make it fit. It should only be needed between 768 and say 900-ish pixels wide.

For wider screens a simple max-width: 300px on the calendar table looks okay as the block expands further. If you really want to narrow the blocks, even in iPhone mode, then another max-width and margin: auto should center them between whitespace. Give it a try, it's fairly easy to mock-up with browser developer tools. It effectively makes the gutters flex to soak up the space (which I think the fixed grid does automatically, but we're using the fluid grid).

@David: I need this theme in a branch based on moodle/master not MOODLE_24_STABLE as it is not being back-ported. You need to ensure it will work in master.

When ready I need it in this branch format:

https://github.com/bmbrands/moodle/compare/master...wip-MDL-38016-master

The commit message for wip-MDL-38016-master needs to read as follows:

MDL-38016 theme_bootstrap: ADD new Bootstrap theme to Moodle CORE.

Can you ensure that is done by the end of this week?

Hi Mary,

I don't think Bas has a fork of moodle in github yet, but here's a dry run on my github:

https://github.com/ds125v/moodle/compare/master...wip-MDL-38016-master

How does that look? I've been primarily testing against the master branch as getting it to work with other versions isn't as time-boxed as getting this in for 2.5.

Because this is starting off in Moodle 2.5 (moodle.git/master)it needs to be tested in that branch that's why you base a branch off master to add the theme to it.

It's good that it works in Moodle 2.4, but this is of no immediate concern to Moodle as it's not going into MOODLE_24_STABLE.

It's not easy I know and it's going be a hard slog from now on. It would be better if it's in Bas's repo then he will get the credit for it.

I'll add yours for now David, so that we can get someone to Peer Review it. But be aware it will need to be rebased by the end of the week when Moodle master is updated (probably Thursday).

Cheers

Will Font Awesome be in the theme? http://fortawesome.github.com/Font-Awesome/

Okay wow, why this rush? I was working on fixing the Yui stuff, already fixed the docking and a bunch of other fixes before the theme was ready for review, then we would need testing and doing fixes. Does this mean we just wait for the review results and it's all out of our control form now on?

I am not really happy with how this is going right now

The rush is only if you want it in 2.5.

If should be the case that for anything you submit for integration, you are confident that it is good enough to be integrated. You should not speculatively submit something, and wait for the reviews.

Sorry Bas, my mistake. We can wait, just let me know when you have finished the work you are doing. In the meantime I'll remove the link to David's github.

I will warn you though, things are not going to get easy, as there are some very stringent testers out there, and you may feel that they are pulling your work to bits, but it is all for the good. Just don't let it get to you.

You were asking about the calendar earlier. Take a look at the theme I sent you earlier today. The CSS for the calender is in style/core.css and resizes to whatever size the block is.

Bas Brands said:

Does this mean we just wait for the review results
and it's all out of our control form now on?

Not in the least, you will have full control over this theme until it gets integrated. After which, if it is successful, you will have every opportunity to be able to add to the theme, via Moodle tracker, if you want to improve it, or fix things.

The process of getting a new theme approved and integrated can be a long and drawn out one, but usually a time where you learn a lot about Moodle, and your own personal resilience when the going gets tough.

I hope this answers your questions?

Thanks Mary for explaining this. It does answer my questions.

I was afraid the current "dev" branch of the theme would be reviewed and rejected because it still has some very obvious bugs and there was nothing we could do about that anymore.

The last week(s) David has done an amazing amount of work for the dev branch and if there is anybody that deserves a lot of credits for this theme it's him.

So to make sure we do create a version that is ready for review I suggest we create a Roadmap document with issues and tasks to work on. Last week David, Stuart and I had a conf call and worked on a task list. We can share that list with you and Moodle HQ to set priorities and assign tasks. I had a short chat with Martin on this and he told me that on some issues HQ might be able to help.

Currently this list is in Google docs, I can add the items as milestones on Github if that works for everybody or is there a way we can use this tracker for that?

Gareth asked: "Will Font Awesome be in the theme?". The short answer is no.

You can of course layer something like Font Awesome over the top of any theme for use in course content, by default the Glyphicon icon sprite is available for that purpose. But for replacing Moodle's built in icons it's only half-possible. The issues are a) you have to rewrite the img tags to i tags, this can be done in renderers, but only about half of the places that icons are written out are using renderers, b) even if you can change it with a renderer, some of the javascript was written to expect an img tag and fails if it doesn't find it (e.g hiding/showing course activities) and c) Moodle has a lot of very specific icons, even Font Awesome doesn't come close to covering all that are required so you'd end up with a mixed bag anyway.

Given all that, and the much better SVG icons introduced in 2.4, we just use those.

I've put in an issue about converting the current SVG icons into an icon font, which might be done for 2.6. Stuart made the suggestion in that bug that merging the Moodle font and the Font Awesome font might make sense. See https://tracker.moodle.org/browse/MDL-37231 for more.

@Bas: We all appreciate the work you are all putting into this, but what we are really needing right now is just a working copy of a bootstrap theme, so that we can get it into Moodle 2.5 ready for the launch. The problem is we only have 3 weeks to get this sorted out. David copied the 2.4 dev theme over to a master branch which is all we need. We can test this to see what works or needs fixing, and also what doesn't work and can't fix.

There is nothing stopping you personally working on your Moodle2.4 dev which, if you wanted to, you can release to the community via the New Plugins Directory. As some people will not upgrade to 2.5 straight away, so having a 2.4 theme available would be good for that group alone.

@Mary: The name Moodle 2.4 dev might be confusing. It might as well simply be called dev since it is supposed to work for multiple versions. Please be patient for a few more days to give me some time to fix a few issues and add in docking etc.

On the other hand, If I can add fixes later it might as well be tested asap.. I have setup a fork of mood.git:
https://github.com/bmbrands/moodle/tree/wip-MDL-38016-master that has the theme and hopefully the right commit

Requesting Peer Review ASAP please.
Thanks

Hello Mary, I have quickly looked at the patch:
1/ what are you doing with the doctype in theme_bootstrap_core_renderer?
2/ I do not understand the hacks in theme_bootstrap_core_renderer::heading, it should be at least fully documented so that the changes may be applied to core later (ideally with MDL issue number)
3/ the inclusion of jquery is problematic because it will not work with custom theme dir, it does not have proper headers, it will have caching problems during upgrade - I started working on jquery integration for core today - no need to change it now, I will comment here if I create some patch for testing next week

this is not a full peer review

Hi Petr,
I'm just loading this onto my server so I can test it out, and run it through CodeChecker.

Not sure about the Doc Type perhaps Bas or David can answer that

hi @petr

1/ in the versions of moodle this theme was developed for used old doctype declarations - e.g. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

this caused an issue with ie which forced it to run in compatibility mode http://msdn.microsoft.com/en-gb/library/cc288325(v=vs.85).aspx

for the original bootstrap theme, which was developed for in Feb 2011 while bootstrap was still in beta for moodle2.0, this doctype needed to be fixed.

If bootstrap is only intended to work with versions of moodle that have the correct doctype in core, we do not need this, but for older versions of moodle this may still be needed.

anything else to add @bas / @david ?

Thanks for looking at this Petr,

I took the doctype stuff out and added doctype='html5' in the theme config.php. It's only needed for 2.3 and below support which we can keep in a different branch outside of core Moodle.

I took the header hack out too, it's looking for certain headers and not outputting them but it's easier to achieve with CSS by just making them invisible. Plus, I'm not sure that Moodle even outputs those headers anymore.

Javascript's not really my area, I believe Bas is still working on plugging in the YUI port.

There's now a moodle_25_dev branch (which only needs stuff for 2.5) and a moodle_all_dev branch (which should work on 2.3/4/5 at least) at Bas's github.

As I keep say this version of Bootstrap is for Moodle (master) branch which will branch off into Moodle 2.5 in a few weeks time. So if you want this to happen, can we have some clarity here.

If you have code in there that need not be in can you take it out? Also The files need to go through Codechecker as there are some errors that need fixing.

Did someone say the dock is not working? That's possibly because of this code...

<aside id=region-pre class="span4 block-region">

region-pre should be enclosed in " " like so...

<aside id="region-pre" class="span4 block-region">

I've been using Bas Brands bootstrap theme and have items in the custom menu setting from site administration... When width is scaled down to switch to the btn-navbar in the top right, the button does not function... My menu items go away and when I click the button which would normally cause a dropdown using bootstrap in a regular website environment, nothing happens at all. Is this a known bug with the theme or is there something I need to do to get it to function?

@mary

i'm not sure how up to date your codechecker is mary, but these days we don't normally use "" unless there is more than one item in the selector.

id=region-pre is generally excepted as best webstandards practice on the web today.

have a look at the style guides for googles developers - http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

@Stuart: The codechecker is for the php and is standard practice in Moodle. There are currently 55 errors in general.php alone. I forget what the others are now, but they need attending to.

My query about id=region-pre was more to do with how the dock works.
Sorry but having spent nearly four years messing with Moodle code it just came naturally to suspect it was a typo.

I got the dock to work, it just needs some better styling.

Is there a reason bootstrap has chosen not to have base as its parent theme?

@Richard Bakos:

It works OK with this version, or at least it did a few moments ago when I was testing it. You do have to enable the jQuery in the Bootstrap custom settings page though.

@mary I have been working on fixing the dock too my fixes are already in The bootstrap dev branch. The key was to add a hook to the dock.js in the theme. To prevent having to style the theme again I pushed in te block class using yui javascript. I am still working on the right way to resize regions once they are all docked. With our new 2,1,3 layout that has become much harder to get right.

See https://github.com/bmbrands/theme_bootstrap/blob/moodle_25_dev/javascript/dockmod.js

@Stuart, I don't understand this bit:

i'm not sure how up to date your codechecker is mary, but these days we don't normally use "" unless there is more than one item in the selector.

• https://github.com/moodlehq/moodle-local_codechecker is up-to-date. You can see from the most recent commits that Eloy (one of the integration team is) actively working on it now.
• As you can see from the URL, is the the Moodle project's checker, not Mary's.
• It does not check all aspects of the Moodle coding style, but the things it does check it gets right. (99%)
• If you think any part of the coding style should be changed, file a MDLSITE bug in the tacker. (There is a component for coding style.) Please don't waste people's time with bikesheds.
• The link you give to Google is useless. Where, specifically in all that, does it say some that validates the point you are trying to make?

Oh dear, I knew I should have commented before the code formatting wars started.

First, @Richard,

the Bootstrap collapsing menu requires javascript. Bootstrap uses JQuery by default, but we're in the process of looking at replacing it with YUI. At the moment I think it's broken because that transition is still underway.

Onto HTML attribute quoting:

The question of whether to quote or not in HTML(5) has always been contentious, with one slightly obsessive side arguing that it looks neater with quotes and another, equally obsessive, side arguing that it looks neater without.

People come up with all sorts of other arguments like XML compatability and smaller download size to support either opinion, but I've always thought most people just decide which they think looks neater and then use those arguments to back that up.

I will happily do the work to change all HTML attributes to be quoted if that's what's required by Moodle core. The documentation I found on this topic (which was a few months ago now) was recommending XHTML, which I thought (going by the response in the bug I filed about switching to an HTML5 doctype: https://tracker.moodle.org/browse/MDL-34299) was out of date advice.

In case anyone cares, I'd generally leave them out, I find it's a great deal easier to output HTML from PHP if you skip unnecessary quotes and use variable interpolation, plus it looks neater!

On to the PHP codechecker:

I actually have this (or at least the XML file that specifies the coding rules) set up to run every single time I save a PHP file in my editor (since at the time I was strangely hopeful of getting some of my PHP code into Moodle core). While it's a great tool for catching issues in pure code PHP files I had always assumed that it was simply unsuited for the kind of PHP file found in the layout directory since it gets confused by the formatting (or lack of it) since you're usually fit the PHP in while trying to follow the general flow of the HTML document. Maybe I'm using it wrong

Quesion for Tim: have the actual code guidelines changed at any time in the last 12 months or are those commits to the Moodle integration side of things? If so I'll need to update my editor.

Re code-sniffer:

The actual coding guidelines have changed slighly in the last 12 months, mainly in the sense of clafiying things that were previousely undefined - acutally there are fewer changes than I thought: https://tracker.moodle.org/issues/?jql=project%20%3D%20MDLSITE%20AND%20component%20%3D%20%22Coding%20style%22%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20ORDER%20BY%20updated%20DESC

The changes Eloy has been doing recently (https://tracker.moodle.org/browse/CONTRIB-4144) have been about:

• Automatically checking more of the existing rules that can be automatically checked.
• Fixing some things what were wrong - like "the kind of PHP file found in the layout directory"
• Detecting PHP things that work now, but which we know will cause problems in PHP 5.4 etc.
• Updating the codesniffer library used, and generally cleaning up the code.

So, either now, or once CONTRIB-4144 is finished, you should update your ruleset.

I missed Mary's question on the last read through:

Is there a reason bootstrap has chosen not to have base as its parent theme?

Good question, the answer is "Yes". The Base theme includes lots of layouts and CSS that the Bootstrap theme doesn't need, unfortunately mixed right in with stuff it does need. The Moodle theme inheritance system only allows you to include and exclude entire CSS files. So if it inherited from Base, the first thing Bootstrap theme would need to do would be to specify in the config.php that it doesn't want to inherit anything from Base, which would make the whole thing a bit pointless.

The other alternative would be inherit from Base and then write what would effectively be a "reset.css" to go through and return nearly every style specified in Base back to a neutral default, in order to build up again from that foundation. That would be a simply staggering amount of work, for no extra benefit over just not inheriting from Base in the first place (and the extra downside of large amounts of CSS for users to download onto their phones that does nothing but cancel itself out).

This also enabled some other cool stuff (smaller, simpler, more readable, understandable and theme able code) that simply wouldn't be possible if building on top of Base.

I think, if accepted into core, that Bootstrap can in future replace both Base and Standard themes. Both filling the role of Base, in giving people something simple to build exciting themes on top of, but also of Standard, in giving something that is clean and inoffensive out of the box for people who don't want to muck around with things too much.

@David:
I agree that there is a lot of CSS in base theme that could do with being put into separate files. This would make it easier to manage and also help when excluding css too. From memory in the early days of Moodle 2.0 this was in place, but as things developed much of the css ended up in core.css.

Hi Mary,

indeed one of the ongoing tasks in the Bootstrap theme is to break up the styles into more manageable, logical chunks (a file for buttons, another for forms etc.). Certainly a great deal of work was done in Moodle to allow this to happen with styles.php and it's well used in some areas, but perhaps no-one wanted to mess with the core CSS in case the whole jenga tower came tumbling down? That's one of the benefits of starting again with a (initially) non-default theme, you get to make big changes and refactorings without feeling trapped by past decisions.

David, I am worried now that Bas is having problems with the layout. Is it absolutely necessary to have so many if statements to change the structure of the layout so that the block-regions have the correct span class?

I didn't need to do any of that in Tiny Bootstrap I did it in CSS using .side-pre-only, .side-post-only and .content-only like so...

/* Pagelayout
-------------------------*/

.side-pre-only .container-fluid .tiny-row-fluid .span3.left,
.side-post-only .container-fluid .tiny-row-fluid .span3.right {
    width: 23.404255319148934%;
    *width: 23.351063829787233%;
}

.side-pre-only .container-fluid .tiny-row-fluid .span6,
.side-post-only .container-fluid .tiny-row-fluid .span6 {
    width: 74.46808510638297%;
    *width: 74.41489361702126%;
}
.content-only .container-fluid .tiny-row-fluid .span3,
.side-pre-only .container-fluid .tiny-row-fluid .span3.right,
.side-post-only .container-fluid .tiny-row-fluid .span3.left {
    width: 0!important;
}
.content-only .container-fluid .tiny-row-fluid .span6 {
    width: 100%;
    *width: 99.94680851063829%;
    margin: 0!important;
}

Hi Mary,

it's the combination of supporting responsive, RTL and having the center content first in the HTML that complicates matters as each requirement interacts (as Bas is also discovering with integrating docking and content first). There was also discussion about supporting two columns of blocks on each side. The current code was built up over time so it's possible that knowing all the requirements we could return to something simpler.

I've also already tidied up the if statements recently to re-use the logic that decides on the body style class id so it's more like a PHP equivalent of what you've got there in CSS, though it's not public in github yet. It's a bit better than it is right now, though RTL stuff still makes my head hurt.

David:

The RTL side-swapping was only added to Base theme, Nadav wase not allowed to add it anywhere else at the time. The only themes that uses it currently are Standard theme, because that takes its layout direct from Base theme, and the Afterburner, since that was a theme I was working on so the RTL community had a theme that works in IE7. Other than that no other themes use that side-swapping layout in Moodle, because Canvas theme is not set up to use the side-swapping PHP. So for what it's worth you could perhaps drop that, just as long as Bootstrap works in RTL, meaning the general appearance, and that the .dir-rtl CSS is kept up-to-date, I do not suspect any problem. Besides, there was talk to get the RTL side-swapping code fixed at source in Moodle.

I think the priority here is getting the Bootstrap to work, you can always go back and make a RTL version, which may be a solution in itself. Thinking about that, there is no reason you could no do that now. Two sets of layouts in theme/bootstrap/config.php and one IF statement defining the the layout, using two layout files default-ltr.php and default-rtl.php may just be the answer.

David:
Further to my last comment, looking at the code that adds different span classes when in RTL mode. Why change the span class from span3 to span4 when there should be no need to change the column size at all, as all that's happening is that the content is changing NOT the column itself.

Hi Mary,

I've rewritten this a few times and it's proving tricky to talk about without diagrams but...

for the 3 column layout, the left block column and the center content column are nested inside their own bigger column. They are span4 and span8 which together make up the full 12 spans of the outer span9 which along with the span3 column make up the full 12 spans of the outer row.

This is necessary so that we can switch the content column into the middle at desktop sizes, even though it comes first in the HTML (and on mobile devices)

does that help?

David, If that is the way it would work normally, forgetting the RTL for the moment, then that explains it. However, Unless I miss read the layout code, it looks very much like you are changing the layout for RTL only.

I discovered a simply fascinating bug while testing this theme, logged as MDL-38441.

In short IE6,7,8 & 9 will ignore some of your CSS if you have more than 4096 selectors in a single file, and due to the system that combines CSS into a single file, this seems to apply to every Moodle theme I've looked at so far.

Can anyone comment on the chances of it getting fixed for 2.5, because otherwise I'll need to work around it.

What if we leave out all module CSS and only load it when the module is used? would that limit the CSS enough for now?

Also: I noticed this Tracker issue changed owner. What does that mean for the review process?

The CSS from (default in 2.5) modules styles.css accounts for 1796 selectors so the numbers are about right, but how would you control this from the theme?

So with the current ie specific code in core (actually, I'm not a 100% sure what particular core code is responsible, the stuff I found doesn't seem to actually be called, so this may not be fully correct) we only have to worry about the number of selectors in our own theme code, which is currently 4875 or 760 over the limit, a much more achievable number than the 2000 or so too many I thought we had based on the full CSS being downloaded.

Skipping responsive support on IE9 (IE8 and below don't support it anyway) gives us 434 of that, leaving 326.

What about splitting theme/base/core.css? That way theme/bootstrap could use base as a parent and exclude the CSS it does not need. Either that or add some of your css into base.

By the way I took myself off this case as I don't have the time to manage it. If you have no objections David I could assign it to you?

Hi ho,

Mary do you mean you can't work on this at all at the moment?

I'm playing with the current code as linked at the top of this bug and have a few comments and issues so far:

Comments:
1) Overall looking very clean and I'm excited.

2) New forms layout that puts labels above form elements on small screens is awesome.

3) Custom menu working pretty well.

Issues:

1) Custom menu still using jquery obviously.

2) Block regions get very wide on large screens, meaning less room for content and funny-looking blocks. Can we add a maxwidth on blocks?

3) Any chance of a mid-size format with one block region only? Eg, push all the left blocks over to the right side on a tablet size screen. That would make docking even less necessary.

re Martin's issue #3
Mentioned before, by myself and Danny, but things seem to have gone in a different direction (I hope not reinventing the wheel, I presume there is some reason for it, just that it hasn't been shared on here) - Danny's layout in Zebra (Antioch) is built to have 3 stages - single with content at the top and sidebars below, 2 column with side-post content below side-pre (to be precise and considering rtl as well, this may be right hand column content under left hand column content, I'm not sure?) and then the full 3 column layout.
Richard

Martin, there is nothing I can do here other than twiddle my thumbs, while David goes on his wild goose chances trying to fix Moodle so the bootstrap theme will work.

I just feel that I don't understand Bootstrap enough to be able to help. What's happening here seems to me, to be very complex in that is affecting the whole of Moodle CORE code in one what or another, although I did not feel that when I made my own Bootstrap theme. (See attached: tiny_bootstrap.zip)which works like any Moodle theme.

If you want me to over see MDL-38016 then I will, but I would feel happier if one of the DEVs took this on, as I feel totally out of my depth.

Would it help if we would have a online session ( a hangout or whatever ) to discuss a roadmap, put that in a Moodle docs page and set some milestones ?

I am not a project manager at all but for this project we might need one!

Richard see MDL-35217

Milestones would help. Hangout too, but I still need to fix web-cam etc.

I have edited the Bootstrap Moodle docs page and tried to describe what we have now and started a Roadmap (todo) list.

Could you check if it's okay like this? http://docs.moodle.org/23/en/bootstrap-Theme#Current_development

Hi Mary,

getting things fixed in Moodle is always the long-term strategy, and I'm prepared to put a bit more effort in the short-term to achieve that, but for the > 4095 selector thing, I think I've got a sufficient workaround that will work from within the theme and not be particularly ugly or hacky.

Hi Martin,

glad you like it, regarding your numbered issues:

1) we were thinking of just removing the custom menu as that's easier in the short term than rewiring it to use YUI. How important is this feature to you? My testing suggests that it's something that could be really useful if Moodle was re-designed around it (possibly replacing the nav/setting blocks in a mobile setting), and is generally a bit "woah" for people who haven't seen that before, but not actually vital to the effective use of a Moodle with the current setup. I'm thinking the more adventurous early adopters might be changing the header to add a bit more personality and branding anyway.

2) Could you be more specific on this one, possibly including a screenshot? It's tricky to know what people are talking about with responsive design as it changes depending on which device they're using, exactly how big their monitor is, how their blocks are set up etc. (and that's assuming that they're not looking at a bug or a mistake). But for one example, when you use it on a phone or portrait iPad, the blocks go to a single column at 100% width which is as much as 3x larger than Moodle blocks generally go to. Bas has mentioned he thinks the blocks are too wide in this scenario and we discussed centering them and adding a max width with some padding on either side. I didn't really mind the blocks themselves expanding, what was more problematic was the content of some blocks, which was making assumptions about maximum block width. So for example we now stop the calendar from expanding to more than 300(-ish) pixels width and center it within the larger block while allowing other content to stretch. There are other areas where limiting the width of the block simply makes the screen longer which is a trade-off, so I personally would suggest that people make less assumptions about the width of blocks and let the content take advantage of what is available. Again screenshots (or better a screen-sharing session in a hangout) might be useful to tease out exactly what people dislike or want to change. Actually changing it once that's understood and agreed shouldn't be a problem, I've prototyped some solutions already while discussing it with Bas.

3) I had it set up like this before we made the switch to the content first 2,1,3 layout in the HTML. When I tried the same technique with the new layout the right hand blocks stacked below the middle column content if it was longer (which it often is) which left a big gap between the first and second set of blocks. Before it just attached to the bottom of the previous column of blocks. So yes, good idea, and when it works it works well and looks nice, I'm just not sure of how to make it work with the current setup. Maybe Stuart or someone else has an idea.of how to approach this and combine both requirements? I can only think of using position:absolute to shift it to the top-left and then some javascript to measure the height of the first column and adding that as "top" to shift it down below, which is less than elegant. I'll go and have a look at Danny's solution mentioned by Richard above, to see if it can be applied.

I had a look at Danny's Antioch system. It's using fixed pixel width columns to let it shift things about and line them up precisely with margins, so it's making a different set of trade-offs and is somewhat incompatible with "the Bootstrap way" which usually lets spans flex and spreads the extra space around between content and gutters, but it fits in more with Moodle's traditional assumptions where the blocks are fixed widths and the center content soaks up all the extra space. I wonder to what degree you can combine the two approaches, or whether just ditching the Bootstrap grid layout facilities is simpler. I'd kind of hoped to use the Bootstrap grid for headers, footers, laying out forms and educational content but that's a bit further in the future and may still be possible even if the main layout isn't using it.

So on the 4095 selector limit, I think that I've worked around it for now. I tried a couple of different things a) I moved nice-to-have but not necessary for function styles to nearer the end, so if IE ignores them it's not a catastrophe and b) I looked at what was creating the most selectors.

The latter turned out to be buttons and tables. Bootstrap expects all buttons to have .btn class and all tables being used for tabular data to have .table and it adds a fair few selectors to make them look nice. I was telling it to repeat every one of those selectors for each of the multiple different ways that Moodle uses to mark up the same thing which was rapidly getting out of control. Taking a bit more care with how I specified those massively reduced the number of selectors being used.

I'm a bit unsure of exactly how many selectors we're down to now, I've got two different tools telling me either 3,600 or 4,400 but we're mostly back and functional across various platforms and can tweak our way out of trouble if we need to now that we understand what's going on.

As a thought with the 4095 selector limit in a file, could the caching code break and produce a second, third... file upon the 4095 boundary? This is because styles come from loads of places like modules, so any such combination could inadvertently push this limit over the top. So I consider this to be more of a generic rather than bootstrap issue.

In a further exciting twist to the 4095 selector count issue, it appears IE8 and IE9 count selectors differently. As far as I can tell, IE8 doesn't count selectors within media queries, because it can't support them anyway. So as it stands, IE8 is reading the whole file right to the end and applying all the styles (well, at least the ones it supports) while IE9 is ignoring the last 400-ish selectors (which are specially chosen to be ignorable without anything terrible happening).

@Gareth, yep there's definitely non-bootstrap related stuff that could be slightly improved (mostly for better theme loading performance), but the bug's much less serious and widespread than I first thought, and it's probably only oddball themes like Bootstrap that are currently affected by it in the sense of breaking, rather than just loading a tiny fraction slower.

Starting Peer Review

Hi David,

Sorry, I have been lurking on this ticket but really wanted to add my 2c to one of your points.

I think every core theme must have custommenu. It will cause great confusion if a core theme does not support a core functionality. Of course MD may disagree, but that's my view for all it's worth.

Another lurker here - based on my experience of creating a mobile first Moodle course site (http://uxfundamentals.com/moodle/course/view.php?id=2) using the Bootstrap theme, I second the importance of custom menus especially for a responsive theme.

As you can likely tell from the above link (esp. when viewed on a mobile device), custom menus can become even more critical when accessing a site on smaller screens. Looking down the road, having the ability for each course to define its own custom menu would be also quite beneficial. Just my two cents of course.

Thank you,
Paul

@david: in regards to the layout we could probably easily adapt Antioch to any of Matthew James Taylor's "Holy Grail" layouts (px, %, em) in a matter of minutes.
http://matthewjamestaylor.com/blog/perfect-3-column.htm

Custom Menu: really must be supported ... a lot of sites use it for alternate navigation eg see the menu on http://research.moodle.net Of course if anyone doesn't like it, they don't need to use it. I didn't think it a was huge deal to do the JS using YUI or using CSS menus? http://yuilibrary.com/gallery/show/bootstrap-dropdown

Blocks: saying that all blocks must not make assumptions about width is easier said than done. There are just so many out there and we've always had an explicit max width. Fixing these will take a lot longer than we have, so I'd say we put that off to a later release and try to make this look OK with legacy blocks for now.

I find I'm starting to get a bit more used to the wide block look, but on a 2560px screen it's still a bit weird (screenshots attached). I'd still prefer some sort of maxwidth but it could be bigger than it used to be. I'm happy to be outvoted on that though.

Hi Martin,

The jshirley YUI ports of the bootstrap jQuery js libs seem to work fine for dropdowns. I'm still experimenting with all the other YUI js libs for bootstrap.

I have just pushed a working version onto github: https://github.com/bmbrands/theme_bootstrap/tree/minimax_dev
(This version has all the YUI libs for bootstrap and does not need any jQuery!)

Quick comment on the wide blocks, generally I'd be happier to set a max-width on the .container so that once your screen gets past a certain size the extra space just gets soaked up by the far-left and far-right margins with the content columns centered in the middle. This also indirectly limits the size of the blocks.

I have to admit I've had this this fixed-size block conversation, both internally and externally, and I don't think I've ever managed to successfully convey why I think the blocks should flex in the standard Bootstrap manner and why just letting the center expand instead is a bad idea. But the list generally goes: educators (and Moodle devs) creating wide content layouts that look good on their expensive desktops that doesn't work well on netbooks or iPads (or vice versa), it breaks the grid's rhythm, the skinny blocks look a bit weird floating in wasted space once you collapse down to the 1-column version, especially on landscape phones or tablets (and if you don't do that and go 100% on smaller devices, which seems to be the standard, then you already have to deal with wide/stretchy blocks so you can take advantage of that on the desktop as well).

One compromise is that all legacy block's .content (the invisible wrapper between header and footer could be given fixed max-width and margin: auto, so it'll float within the larger block, this could then be removed as each individual block is reviewed. This is essentially what we did with the calendar block and I think it worked quite well visually. I'll mock up a few images for the alternatives if I get a moment.

Talking of images, did the screenshot go missing? I've only got a 1680 pixel wide monitor, so I'd probably not even get the full effect if I could see it. For me on my monitor the blocks are about the size they are on an iPhone held in portrait e.g. the smallest they would be on a mobile device if we let them use 100% width.

@Daniel,

could you combine Stuart's simplified demo page of Bootstrap 2,1,3 layouts and Antioch to see what happens? The current live Bootstrap stuff and Antioch are both complex enough that I wouldn't be sure I was doing it right.

He posted it up thread, but here it is again:

https://dl.dropbox.com/u/256711/content_first.html

I just got my hands on an actual iPad for testing purposes. It turns out I was 1 pixel out on some of my assumptions so the vertical iPad doesn't look like I thought it would. With 3 columns it looks quite squashed. I had assumed it was going to the phone layout at iPad vertical sizes (which it does 1 pixel smaller).

I'm wondering whether I should tweak it to fit my assumption, or if losing the second column would give sufficient space.

@david here's my attempt at marrying Moodle layouts + responsive + bootstrap:

http://htmlpreview.github.com/?https://gist.github.com/thedannywahl/5174598/raw/1ce057c3291e09b3231e3740073b6914c90bcfe1/index.html

here's the original gist:
https://gist.github.com/thedannywahl/5174598

this layout allows you to still use the bootstrap responsive stuff by moving the page header and footer out of the page-content area, while handling page-content in the "moodle way". I only did header, etc... for the first section, but the following 4 give the examples of possible Moodle page layouts, all using the same set of css rules.

In the future this could probably easily be extended for the following:

• shift rtl columns to the right
• allow both asides on right or left via settings
• shift region-post to the right on 2-column layout if there's no region-pre

but this is a good start I believe (good enough to go live)

Also, I switched it to be 'em' based but still 200px (12.5em @ 16px/12pt font) block regions and 481px, 769px (in em) breakpoints - which enables zooming:
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

Thanks A LOT to Bas for combining things.

We are centering efforts around this version:

https://github.com/bmbrands/theme_bootstrap/tree/moodle_25

Please restrain yourselves to comments about this version and fixes for same.

Bas, fire away when ready about what you've done to it recently!

Thanks Martin,

David Scotson has done A LOT of work on this version of the theme too for which he deserves a huge medal.

I will update the moodle docs wiki to describe what we have done for this version.

http://docs.moodle.org/23/en/bootstrap-Theme

Assigning it over to Bas then he can ask me to submit for integration when ready.

I'll also assign David Scotson as Peer Reviewer.

Hi Mary,

I'm not sure if it's appropriate for me to be a peer reviewer as I've been working on parts of this and because I've never done it before. I would have thought that getting a fresh pair of eyes to look at this, and from an "insider" familiar with the Moodle process, is part of the reason for having peer review.

Having said that, I'm not sure the existing peer review guidelines are ideally suited to this kind of change, as opposed to a tightly targeted bug fix, refactoring or new feature. So even if there's a Y or N below, there's probably more nuance (I've added some of that nuance in brackets afterwards).

Following http://docs.moodle.org/dev/Peer_reviewing_checklist

[Y] Syntax
[Y] Output (XHTML compliance has been intentionally not complied with, I believe that's an out-of-date bit of documentation and that existing Moodle code already breaks it anyway. Similarly, simple static HTML isn't using renderers--ironically there'd probably be more renderers in this initial theme if the current renderers themselves followed this guidline. Instead changing a button often required cutting and pasting screenfuls of unrelated code, so we just used the two simple renderers and another two for the custom menu. edit to add: in a further layer of irony, I actually wrote renderers for most of the Bootstrap HTML, but thought getting them into core would be a further obstacle, so rewrote their output manually for this submission.)
[Y] Whitespace (it's all new files anyway)
[Y] Language (nearly n/a)
[-] Databases
[N] Testing (This is not a small, localised change. It will almost certainly have impact across the whole of Moodle (though only if you use this theme) and the scale of testing required is simply beyond the current developers, a scenario the current peer review guidelines don't seem to cover. On another note I'd love to run whatever functional tests Moodle has against this theme but haven't found the time. I think it's more likely to find unwarranted dependencies in the functional testing harness than problems with the new theme though.)
[Y] Security (mostly n/a)
[N] Documentation (I'd like to request a qa_test_required (and just more wider testing in general), but not sure who has the authority to do that) I'd also like to see (and help write) a whole bunch of documentation if this theme is taken as a new direction for 2.6 development). Again, giant task.
[N] Git (the theme is still in its own github, but since it sits in its own directory shifting it across is very simple, don't foresee any issues getting this to Yes)
[Y] Sanity check (though this is just the start, there's dozens of issues opened as a result of this work. You have to draw a line somewhere.)

In that case I'd just request Peer Review and hopefully Martin may suggest someone.
Thanks

(Sorry Bas and Dave etc, I wasn't crediting code yet, just the repo!)

A lot of devs are looking at this issue and trying it out informally. In particular Andrew Nicols and Petr Skoda have been working on some of the subtasks of MDL-38284 which are about a clean way to load YUI gallery stuff from plugins (like themes) so will directly affect this. But that's essentially under the hood and just for the menu at this stage.

I fully agree with you Dave that it doesn't need to be perfect, and that it is just a start. But it should be solid enough to run a site on.

At the moment I think most of the testing should be about obvious visual errors in the interface (on various devices) and in the HTML. Performance comparisons would be good to look for possible big bugs there.

I guess with a collaborative peer review like this, with comments here, assuming Bas and/or Dave can respond with fixes in git, that we could submit for integration sometime next week.

Just having a look at Daniel's re-ordering stuff.

Relatedly, I noticed the other day that Bootstrap 3 is set to have source ordering of columns built-in. But a quick look at their dev branch suggests they've not actually got around to doing it yet.

So one thing I've noticed is that the comparison between the two layouts needs to be chunked by screen width. For example, currently they're effectively identical up to 480px (any diff is just some padding/margin and should be easy fixed). I think they probably should continue to be identical up to as much as 767px, as currently Danny's stuff can have the center column down to 2/3 the width of the block column, so the switch to 1 column should probably happen wider than it currently does.

The differences happen at 768-900-ish. The current bootstrap jumps straight from 1-column to 3-columns at 1 pixel above the iPad portrait while Danny's stuff goes to two columns at 481px (though as I said I think that should be higher, say 767px) and flips to 3 columns at 769px. I'd perhaps shift that up to 900-ish (it's hard to tell without the actual padding all in place) to take advantage of the two column setup at netbook sizes.

Above that size the bootstrap stuff has smoothly increasing block columns and spacing (with an increased rate of change above 1200px). That could be simulated with more media-query steps in Danny's stuff, and we've put a limit of 1680px on expansion for Bootstrap, which is easy to add to Danny's stuff too (though in that case it would be to prevent the center column expanding, rather than all of them).

So assuming my changes to the media queries, the big differences are in portrait iPads and netbooks (that aren't running IE8) and to a lesser degree the way it looks at larger sizes.

Regarding the two bugs reported in the summary:

Could someone explain how to reproduce the activity completion one for someone (me) who isn't familiar with completion tracking?

And is the second one the same as this bug:

https://github.com/bmbrands/theme_bootstrap/issues/23

Hi David,

1. You need to set Completion Tracking in the course when editing course page settings.
It can be either manual or conditional, either way the box will appear. After setting that option in a course you need to run cron.php.

http://docs.moodle.org/23/en/Course_completion_settings

2. Yes that is the same problem but you need to set Static Student in Admin settings
Administration > Grades > Report settings > Grader report

Base theme's report grader page is OK so unless you have set some extra margins or padding in the rows or columns, or used Canvas CSS (big mistake) then you will have inherited the problems. I've cleaned up a few themes, but Splash theme is a mess due to too much padding and is a pain to get right.

When using Bootstrap on an iPhone, there are quite a few areas (deeper in activities) that can look odd. Fixing them will probably require a combination of HTML and CSS changes, and I want to get HQ developers onto all of them at some point.

Any volunteers to start cataloguing the issues (with screenshots)?

On a similar topic, what course data do core Moodle test against? I've found various test data generators, and example courses, but they're all quite basic. It would seem easier to test if there was one, or a small handful, of courses that covered the main areas of Moodle e.g. at least one quiz with at least one of each question and at least one student attempt etc.

There is an excellent add-on for FireFox called 'Override User Agent' - https://addons.mozilla.org/en-US/firefox/addon/override-user-agent/ - in which you can set the user agent to 'iPhone'. This is even more effective when used in combination with 'FireBug' to decipher and solve issues. Really helped me with fixing issues on the 'MyMobile' theme.

@Gareth,

unless Moodle itself is doing anything based on the user agent (I know it can, but I don't think it does by default) then the Bootstrap theme should mostly just react to screen width. So using the Responsive mode in Firefox dev tools or equivalent should be enough to get a reasonable experience of the theme on an iPhone.

Hello, I have just looked at the patch lined above and I think it is using the <?php echo $OUTPUT->standard_head_html() ?> incorrectly, it should go right after the favicon and the theme should not be duplicating the encoding (missing content type) and X-UA-Compatible (which is set via headers). Do we want to force chrome=1 there? If yes we need to patch core.

Dear David Scotson,

In '/lib/moodlelib.php' there is a function 'get_device_type()' among others that can be used by anything to adapt themselves based upon the result of the function call. Therefore it is prudent to have an appropriate user agent string for testing without the real thing.

Cheers,

Gareth

Hi Bas,

Thanks for all of your hard work here - it's looking really good.
I've just got some peer review comments on the JavaScript side of things. I haven't looked at the theme side of things.

At the moment, the way you're including Gallery is fine. We'll have to tidy it up later when we get back to supporting Gallery properly again. Hopefully we'll be able to help Jay improve the gallery-bootstrap bits as we discussed on Jabber.

config.php

• Incorrect spacing for the theme javascripts array - should be four spaces
• I personally prefer it to have the final element in the array also with it's trailing ',' - it makes subsequent additions not affect that line so the blame/annotate/diff is much easier later.
• html5shiv:
  • I'm still not 100% sure what this is needed for. The documentation on html5shiv is pretty poor (https://github.com/aFarkas/html5shiv) and I can't see anywhere we're actually using it.
  • As I understand it, the CSS side of things is already handled by the theme's existing normalise stuff
  • If we really do need it, I think that we should probably use the YUI Loader config to only load it if the browser is believed to be IE<9 rather than guess based on UA in PHP.

js/moodlebootstrap.js

• For clarity, it would be better if you move the YUI().use to the bottom of the file. Using things before they're created can be a bit confusing
• The contents of the YUI.add should be indented 4 spaces
• We should probably keep this to using existing moodle naming schemes: moodle-theme_bootstrap-bootstrap. I know that this isn't quite right at present, but I hope that in time we'll be able to correct it
• Namespaces. At present, all of the Moodle modules are on the M namespace (e.g. M.core.notification). I'd quite like to move to use the standard YUI Y namespace instead, but I'd like to enforce proper namespacing from the off. Therefore, if you intend to use it, make it work with the module name - Moodle.theme_bootstrap.bootstrap
• console.log still present but commented out
• You're calling dropdown_delegation but that function doesn't exist
• In the Y.delegate, you're calling an anonymous function. It would be better if that was another function on the Namespace (expandable_handler or something) to make the code a bit easier to read.
• Spacing around () - e.g. if (!target.collapse) {
• You should use 'body' rather than document.body - IIRC, we add document.body and it's not necessarily available, but I could be wrong there.
• Since you're using delegation, you shouldn't need to wait until domready before initialising. If you do need to, then you can have it as an argument to YUI() on line 1 - see http://yuilibrary.com/yui/docs/api/classes/config.html#property_ {Object|String}

  delayUntil for how to do so. Then you need to change your use call to:

  YUI({
    delayUntil: "domready"
  }).use('moodle-theme_bootstrap-bootstrap', function(Y) {
      Y.Moodle.theme_bootstrap.bootstrap.init();
  });
  

• you need to add a dependency on selector-css3 for IE6-8. CSS3 selectors are an HTML5 construct. YUI does the right monkey patching though so it'll only include the selector-css3 module if it's required. This is for the [data-toggle] CSS selector.

Sorry if the above looks a lot - it's not really, it's mostly small things and I'm good at being wordy.
I've not had a chance to actually try the branch yet - hopefully if I get a chance later this evening I will,

Andrew

Ah - I've just seen that you're using the dropdown_deleagtion in the gallery module. Just need some time to look at how this works, but my gut feeling is that it's not quite the right way. Instead, if you maintain our existing namespaces rather than using the Bootstrap one, you can call the following in your initialiser:

Y.Bootstrap.dropdown_delegation();

By depending on bootstrap-dropdown, that should add Y.Bootstrap as an object to the Y in your initialiser.

If you ping me on jabber/googlechat I can discuss further.
A

Regarding the HTML5Shiv, it's needed if you want to use newer HTML5 tags like header, footer, main, etc. in IE7 and 8. It "touches" these elements via javascript to workaround an IE7&8 bug so they will let you apply style to them, otherwise they just collapse and act like unstyled spans. Any method of only serving it to IE<9 is fine, we previously had it inside a conditional CSS comment in the head tag, but issues with getting the correct path to files in the theme made us move it in with the other javascript based on user-agent detection.

I've pushed some fixes for the activity completion and gradebook issues mentioned upthread. Some further testing from people who know those areas well would be appreciated.

@david for testing of the gradebook and quiz module I have added a anonymized course with real users and quizzes and real results. check out: http://theming.sonsbeekmedia.nl/course/view.php?id=9.

The HTML for the gradebook is a bit weird, with a left_scroller div containing a table and a right_scroller div container table that align okay in standard mode but the alignment breaks when editting is turned on.

It would be nice if anybody could explain why gradebooks are build this way using tables in divs.

Fixing it should not be too difficult but I was thinking of doing a little tweaking as well.

It would be nice to have a gradebook that uses fixed columns for users / module names or any other fix that would make big gradebooks easier to use.

Gradebook is indeed a funny beast. CLAMP has produced a grader report plugin that does away with the static column on the left and manages to have the gradebook content scroll both directions without losing the student (and extra columns) or the item name (and extra) column headers. Rewriting to deal with large classes is troublesome because of the model (based on a very large form with 2-4 inputs to be submitted per grade item).

@Bas:
We really need to think about getting this ready for Integration Review this weekend. So it needs to be in the correct format, that's to say in https://github.com/bmbrands/moodle/compare/master...wip-MDL-38016-bootstrap-master

I've been checking out the branch that Martin says is the branch we are to test and submit when ready. We have 10 days left, if we miss this weekend we will be cutting it fine as the deadline is 31st March, which is a week on Saturday. After which there will be a freeze on any new code going into Moodle.

Here are some fixes for the Grader report with static students when editing:

.editing.path-grade-report-grader .grade_icons {
    margin-bottom: 0;
}
.editing.path-grade-report-grader td.grade input.text {
    padding: 0;
}

Please fix theme/moodle/bootstrap/lang/en/theme_bootstrap.php where it makes a reference to Canvas theme in this line...

   <h2>Tweaks</h2><p>This theme is built upon both Base and Canvas, two parent themes included in the Moodle core.

Thanks
Mary

Actually, I thought the new feature freeze was this coming Friday which gives us 5 working days really, not 10.

Martin said end of March, which in my book is Sunday 31st. Working day's as opposed to non-working days, is something I am not familiar with as I work everyday. Friday 29th March, sounds about right, so since today is also a Friday, you have approx 6 working days left including today. or 10 actual days left if you count weekends as I was doing.

Either way we are running short of time.

Hi Mary,

I don't think gettting it into the correct form to be pulled from git is a big worry, Bas can do that in under 5 minutes.

I think the grader stuff should be mostly fixed now, if you could test it that would be great as it's a fairly complex bit of Moodle that I'm not overly familiar with.

Talking of which, I don't think that text about Base and Canvas has been in the theme for a while, so make sure you're testing against the branch that Martin pointed to earlier:

https://github.com/bmbrands/theme_bootstrap/tree/moodle_25

cheers,

dave

@Mark
My tests indicate some css will be needed to align the LAE Grader but generally it came out better than I expected with Bootstrap.