David Scotson

Regarding RTL, here is the Bootstrap 4 plan for that:

https://github.com/twbs/bootstrap/issues/19555#issuecomment-197549158

I would highly recommend this "tool-assisted" approach. One such tool they mention that I like is this one:

https://github.com/MohammadYounes/rtlcss

And here is a post-css plugin that uses it to create Moodle-style combined RTL & LTR CSS. (Note, I don't think that's a good idea or best practice, better to send RTL or LTR depending on the current page direction, but since we already do it, I thought it would be interesting to note that it can be partly-generated).

I've implemented an earlier version of this in a Bootstrap 3 theme and the big blocker was core Moodle's requiremnet to send both LTR and RTL to every page, but this newer tool could work around that if it really needed to. But ideally only the CSS required for the current page would be sent, and this could have a dramatic impact on Moodle's total CSS download size, so that's an important co-benefit.

Is the idea to create a new theme within the current limits of the theming system, or to use the experience of building a new theme to help fix/expand the themeing system to better support theme work?

The existing Bootstrap 2 & 3 themes push the boundaries of the current system and are much harder to work on than they should be as a result. Something as simple as every standard form button in Moodle consistently having a ".btn" class (and removing it from anything that isn't a standard button!) so that you could change a few Bootstrap variables and see the change reflected in all buttons  across Moodle would be nice.

Several people have commented about Mahara's adoption of Bootstrap making it very pleasant to do theme work, since it adopted Bootstrap wholeheartedly. Moodle has always avoided making any long term commitment to Bootstrap and this has slowed progress in themes by forcing a series of elaborate workaounds to fake standard Bootstrap behaviour via theme code, while core code continues to do it's own thing(s) when it comes to choosing classnames or standard web patterns.

I would suggest the first step, assuming you actually choose Bootstrap for this new theme, would be to add some bootstrap classes  to core code that is not yet in a renderer or template. This would avoid  you having to repeat the complicated and annoying work to shim Bootstrap so that it is compatible with the existing HTML, and avoid any designers brought in to work on this complaining "that's not Bootstrap" when they get to see the Moodle HTML they have to work with.

The paypal accessability additions are out of date, since Bootstrap core has massively upgraded their accessability during the Bootstrap 3 cycle after they recruited an accessability expert to work on it. This probably also explains why it does not exist for 4 too.

For more info:

https://github.com/paypal/bootstrap-accessibility-plugin/issues/74

https://github.com/paypal/bootstrap-accessibility-plugin/issues/81

I'm sure Bootstrap would welcome any accessability improvements we can offer, as many other projects also return their suggestions and improvements to be shared by other Bootstrap users, but I think we should be up-to-date on what the actual problems are. The open issues tagged with accesability are here:

https://github.com/twbs/bootstrap/issues?q=is%3Aissue+is%3Aopen+label%3Aaccessibility

And their lead AX dev has some issues assigned to him that seems like accessability but aren't tagged as such:

https://github.com/twbs/bootstrap/issues?q=assignee%3Apatrickhlauke+is%3Aopen

Grunt gets installed in two parts, one called grunt-cli that is installed with something like "npm install -g grunt-cli", the -g means global so it can be used anywhere on your system and doesn't need to be installed multiple times.

Then you need to run "npm install" in the directory to set up the Gruntfile. That needs to be done once for core moodle, and once for each theme that you're working on.

Running grunt in  a directory will search for a Gruntfile, working it's way up the directory structure, stopping at the first one it finds.

Now that core ships a grunt file, the themes that use grunt should probably alter their gruntfiles to pass on any commands they don't understand to the core Gruntfile. I think currently it'll mean that the core grunt commands will fail if you try to run them inside a theme directory. My colleague has done this, I'll ask him to post details here.

Hi Richard,

I believe that Atto avoids this problem entirely, so one solution to not having a comprehensive editor.css file is to switch the default editor order so Atto is first.

This is the default and has been for a few version, I think Dom's site might be older, and so this may not be of any help to him, but just fyi in case it comes up again. (edit: it seems that Dom is using a Clean derived theme, so switching to Atto may be a potential solution for him)

cheers,

Dave