David Scotson

I'm happy to see core focus on missing renderers (and consistently using the renderers we already have). This was the most obvious problem discovered while creating the original Bootstrap 2 Moodle theme back in 2012 , and didn't get the attention it needed then or since. I'll dig out the various bugs I filed at the time and add them to that tracker.

It would be nice to see some commitment to following the standard front-end best practices that are encoded in Bootstrap (of any version, and they're shared with most popular alternatives) but for whatever reason that seems a hard sell. We already have Bootstrap 2 as the default theme but struggle to follow their best practices in things like semantic alerts so I suppose a shift to 3 wouldn't necessarily fix that either.

There would definitely be benefits to the wider Moodle ecosystem of a clear frontend vision committed to following Bootstrap, with enough forward planning to cope with upgrades, like many other comparable projects have, but frankly, compared with the lack of renderers and the prehistoric state of much of the core HTML (We still have tables for layout!) it's a minor problem.

My main worry is, that without the guidance of Bootstrap's design decisions, the API for the newly created renderers will be terrible. Again, in theory we already have Bootstrap 2 as a core component, but it's not helped so far with attempts to rationalize the existing renderer APIs into something simple, sane and modern. Though that, like renderers generally, has not been a big focus of work so far though there was some discussion about it. Hopefully any new renderer work will start with figuring out the right way to do it, and not be too constrained by existing practice in Moodle, down to the level of recreating obvious bugs and design flaws in new code.

Bas's Bootstrap3 theme already uses postCSS to automatically add the browser specific -webkit etc. CSS for you, using a tool called autoprefixer. It's very cool tech.

I'd picked this up wrong, and thought BS4 was the one that was going to be PostCSS based, looks like that won't happen till the version after.

Regarding hardcoded bootstrap classes: it was always a shortcut, and I think it still has it's place e.g. I've been looking at adding a few bootstrap classes to the mform output to help layout the forms. Ideally a renderer based forms library used across Moodle would be coded, but in the meantime a bunch of ugly .less and CSS could be replaced with a few well chosen classnames, which would just be ignored by themes that don't need them.

One thing I learned at the Moot (from Andrew Davidson) was that Bootstrap have announced that version 4 will be just CSS, no .less or SASS. I think that's a very cool decision, but it does mean that the .less based workarounds we've used in Bootstrap 2 & 3 will no longer be available. As I pointed out in the issue I filed suggesting we add a YUI Pure CSS theme (MDL-40148) that requires near universal renderer coverage so that every bit of HTML can be changed. So, even if they do announce it tomorrow, we'd have no good way of using it till the renderer work got done.

A renderer is a a bit of code that spits out HTML, and which lets themes replace it with a new bit of code that spits out a different bit of HTML if they want to.

This gives themers flexibility, and makes it easier to upgrade Moodle's HTML as time passes. The biggest issue with renderers is that not all code in Moodle uses them, so people either need to do core hacks, or use complex CSS to make things look consistent.

There are no good answers until we improve our renderers in Moodle enough that it becomes easy and reliable to quickly swap frameworks.

At the Moot, the consensus was that more renderers was also the only sensible way to implement Bootstrap 3, so there's a strong overlap between the short term and long term goals here.

Bootstrap 3 based themes are already being put into production by organizations that place emphasis on the UI experience, who often hire people with a front-end focus to achieve that goal. They'd prefer if Moodle had more renderers so that they could deal with Bootstrap HTML, as they're used to from other projects, rather than try to fake it with complex CSS targetting Moodle's core HTML output. So it seems that co-ordinating that potential energy is key, as the work to expand renderers benefits everyone using, or working on, Moodle, regardless of whether they prefer Bootstrap 2, 3, 4 or something else entirely.