David Scotson

I see this too. I'm doing major surgery on my theme though, so I assumed it was just me breaking something. I always forget about it until I'm upgrading and then it takes me by surprise. I'll try and remember the next time and see if I can figure anything out.

Copying the login in the header is something I'd like to do as well. I've currently just got the non-functional text fields there for show, so if you get it working it would be great to add that to my code.

I've added a file called undo.css to my theme for tracking things that need reset because of class-name clashes, though I'm hopeful that more of them can be avoided by using renderers.

I've also got a (currently empty) file called javascript.css that's for tracking javascript that breaks when you start renaming stuff. I figured out a way to fix the embedded PDFs etc. from disappearing just with CSS, so I'll work around these issues where possible, but so far all the one's I've looked at could be fixed better in core.

My theme's more for developers and documenting and tracking the pitfalls and workarounds of Moodle themeing so please contribute any you stumble over.

The grid system is the bit of Bootstrap I have least knowledge of because I learned it by theming Moodle from the inside out. I think it could be very powerful but don't have any big ideas yet.

We don't use docking at our institution so I know next-to-nothing about it. My bootstrap theme used to be called simple because one of the sub-goals of my initial project was to simplify Moodle so that e.g. you'd only need one theme for desktop and iphone and ipad (possibly responsive, but possibly not). One target of that simplification was to pretend docking didn't exist. Though that opinion was developed without ever using it, maybe it's really useful. (edit: what about docking them into the navbar, with a javascript drop-down, similar to the one called "dropdown" here)

One other aspect of the 'simple' plan was to reduce the number of layout.php files down to one. It seemed like having different php layouts for each type of page was a PHP solution to a CSS problem. I've only got one such file for my own institutional theme. But I'm happy to go with whatever makes most sense to other themers for now.

What are these csspostprocessors used for, just swapping out variables like colours and image paths? Or can you do any crazy thing you want to? What do people actually use it for? It looks like it might be somewhere you could plug PHP LESS into: http://leafo.net/lessphp/docs/#php_interface

I actually saw that variable the other day in someone's theme config and assumed it was to to hook up external css compression tools.

For the layout I was thinking of something like this:

http://twitter.github.com/bootstrap/examples/fluid.html

or

http://twitter.github.com/bootstrap/examples/hero.html

But with two columns, one on each side, each fixed width at say 180px and the centre fluid (though maybe a max-width to give some extra padding on *very* wide screens). I've found that if you try to get any fancier than that e.g. fixed width, 2 column, then you soon run up against things in Moodle that were hard-coded with different expectations. And rather than fight with those issues as well, I'd rather focus on the renderers right now.

I've been coding on the assumption of HTML5 and think that's the best idea.

Medium term I think fixed/static navbars, white/black navbar, custom logo, bootswatches and 2/3 columns are all fairly do-able just by reacting to variables in the layout that are set in the theme preferences (actually I've never done this before, all my themes have been hard-coded for one look, so maybe someone else can take the lead on that). With Bootstrap these things are often a case of just switching one class name so it shouldn't be too intrusive. Long term I'd like to integrate LESS compilation to allow for more sophisticated choices of color and font etc. by giving the user control over everything in variables.less and recompiling the CSS from that.