Yep, fixing it once in the renderers is the plan, that's actually part of why I'm looking at Bootstrap v3 and Pure. It's a compelling demonstration of why the bits of renderers that control the HTML shouldn't be intertwined with the bits that control core Moodle logic if you can easily serve those three end goals (and Base!) at the same time.
I'm just looking through all the renderers now trying to figure out where a good place to start would be. Somewhere you can make an immediately noticeable difference both to the code and the end user but without being such a big change that it's impossible to get it into core Moodle. Currently hand coded forms are looking like a strong candidate for this but we'll see what else turns up.
Oh, and in regards to your question about progressive enhancement vs substantial changes, the stuff I would like to see happen in renderers would get added to Bootstrapbase and improve any theme that inherits from it automagically.
Anything that remains outside of renderers is pretty fragile though, and may require re-work as part of the upgrade to Bootstrap 3, but all that work should again, be confined to Bootstrapbase.
David Scotson
Beiträge von David Scotson
Moodle in English -> Designs -> Bootstrap v3 -> Re: Bootstrap v3
von David Scotson -
Moodle gets released every 6 months, and supports multiple versions in parallel, so duplicate work and work that gets superseded is part of the game. Having said that, I wouldn't particularly want to spend my time on getting one version of one framework pixel perfect via hacky CSS tricks, if I can find a way to fix it properly for any version of any framework by allowing themers access to the HTML. I had assumed the latter would be the direction of 2.6 dev and maybe it still will be. If it isn't then Moodle may well be stuck on Bootstrap 2.3 and any work done on it will have a long life ahead of it.
The "fake" grid system I was referring to was the fact that (like every other modern framework) Bootstrap uses it's grid for laying out basically everything, not just the basic 3 column outer structure which we were able to use via the ability to change layout/general.php.
As part of the Bootstrap 3 upgrade they've elected to use the same standard grid to lay out the forms since they're a prime example of a responsive-grid usecase.
We can't control Moodle form HTML via a theme, so I need to target the existing HTML with clever CSS in order to make it look like Bootstrap, and make it stack vertically on small devices. It's a bit of a fiddly pain, particularly as there's few different varieties in Moodle but thanks to the magic of LESS it's (mostly) possible.
I've not been following MDL-40065 much as the combination of RTL and Moodle's block system isn't really my strong point and it all seemed to hinge on Sam's cleanup, which I've also not really followed (we've been upgrading recently so lots of fire-fighting going on).
It all seems like the right idea though, as the logic in that single file was torturous before, and something that applies to any version of Bootstrap as well as any other type of them. Is it stuck waiting for peer review?
The "fake" grid system I was referring to was the fact that (like every other modern framework) Bootstrap uses it's grid for laying out basically everything, not just the basic 3 column outer structure which we were able to use via the ability to change layout/general.php.
As part of the Bootstrap 3 upgrade they've elected to use the same standard grid to lay out the forms since they're a prime example of a responsive-grid usecase.
We can't control Moodle form HTML via a theme, so I need to target the existing HTML with clever CSS in order to make it look like Bootstrap, and make it stack vertically on small devices. It's a bit of a fiddly pain, particularly as there's few different varieties in Moodle but thanks to the magic of LESS it's (mostly) possible.
I've not been following MDL-40065 much as the combination of RTL and Moodle's block system isn't really my strong point and it all seemed to hinge on Sam's cleanup, which I've also not really followed (we've been upgrading recently so lots of fire-fighting going on).
It all seems like the right idea though, as the logic in that single file was torturous before, and something that applies to any version of Bootstrap as well as any other type of them. Is it stuck waiting for peer review?
I'd like to create a new renderer that can be called by other renderers when they want to create forms/inputs/buttons etc. (MDL-40181)
Does anyone know how to go about this?
I've read this page but I'm still a bit confused:
http://docs.moodle.org/dev/Output_renderers
I just want some functions that you give values to and get back the appropriate HTML, and which can be overridden to deliver slightly different HTML. How do I tie that in with Moodle's renderer system?
edit: I recalled that tabs had been moved into a renderer recently in MDL-38309, but in that case they'd just got moved into the core_renderer. I suppose I could just do that for the time being but it seems a bit more elegant to have them in a dedicated class.
Does anyone know how to go about this?
I've read this page but I'm still a bit confused:
http://docs.moodle.org/dev/Output_renderers
I just want some functions that you give values to and get back the appropriate HTML, and which can be overridden to deliver slightly different HTML. How do I tie that in with Moodle's renderer system?
edit: I recalled that tabs had been moved into a renderer recently in MDL-38309, but in that case they'd just got moved into the core_renderer. I suppose I could just do that for the time being but it seems a bit more elegant to have them in a dedicated class.
What are these things that are assigned as ids in the HTML:
#yui_3_9_1_2_1371120805796_23
What are they for? Why are they on some things but not others? How do they actually get there, is there a bit of PHP adding these to the HTML or is it javascript?
#yui_3_9_1_2_1371120805796_23
What are they for? Why are they on some things but not others? How do they actually get there, is there a bit of PHP adding these to the HTML or is it javascript?
There seems to be something wrong with your node setup.
This command:
recess --compile moodle.less
i.e. without the > at the end to tell it which file to put the output in, should just echo the output to the terminal. If it's working you should see lines and lines of CSS go past.
You appear to get an error about node at that point so it's giving up the first part but still carrying out the command to write the output (unfortunately in this case a blank file) to the output location.
This command:
recess --compile moodle.less
i.e. without the > at the end to tell it which file to put the output in, should just echo the output to the terminal. If it's working you should see lines and lines of CSS go past.
You appear to get an error about node at that point so it's giving up the first part but still carrying out the command to write the output (unfortunately in this case a blank file) to the output location.