Is there some way I can mark bugs in the bugtracker to show that they'll need to be fixed in order for people to use Pure? Maybe a META or something? (edit: or a label, I've noticed that I can create them)
e.g. if you want to use Pure's pagination widget you'd want to fix the issues in bug MDL-35367, perhaps based on the renderer code I submitted as MDL-38260
or if you wanted to use Pure's vector icons then you'd need to include Font Awesome somehow which is MDL-23493 and if you went further and tried to use it for Moodle's action icons too you'd hit some of the issues mentioned in MDL-37231.
And there's a whole stack of bugs that prevent you properly using Bootstrap (about controlling what the form, button and table markup is for example) that I've not filed yet that apply equally to Pure. If I could tag them in some way so that people working on Pure-based themes can work together on them then that could be good.
David Scotson
Forumindlæg af David Scotson
But since you bring up LESS, I think the fact that we currently need to use LESS should be considered a bug, as it is basically a failure of Moodle's theme engine in not allowing us to control the HTML. Sufficient work on renderers could make this entirely unnecessary (though still sometimes useful for advanced themers) in time for 2.6.
I started exploring this in my Bootstrap Renderers theme (https://github.com/ds125v/moodle-theme_bootstrap_renderers). The basic lesson from that was that the exsting renderers aren't built to be overridden and need to be decomposed into standard components implmented by small, focused renderers.
If this work on renderers was not done then I have no idea how people would approach adopting any other framework (Zurb, Pure etc.) without first being forced to recreate the tedious and difficult mapping work that was done with LESS for Bootstrap using SASS or whatever tool the framework uses. For frameworks like Pure, which don't natively use such a tool, the work would all need to be done by hand.
For example, how would someone make the forms in Moodle look like Pure forms ( http://purecss.io/forms/ )?
I started exploring this in my Bootstrap Renderers theme (https://github.com/ds125v/moodle-theme_bootstrap_renderers). The basic lesson from that was that the exsting renderers aren't built to be overridden and need to be decomposed into standard components implmented by small, focused renderers.
If this work on renderers was not done then I have no idea how people would approach adopting any other framework (Zurb, Pure etc.) without first being forced to recreate the tedious and difficult mapping work that was done with LESS for Bootstrap using SASS or whatever tool the framework uses. For frameworks like Pure, which don't natively use such a tool, the work would all need to be done by hand.
For example, how would someone make the forms in Moodle look like Pure forms ( http://purecss.io/forms/ )?
What do the minuses in your diagram mean?
You seem to be suggesting that overriding the the Bootstrap renderers in core will require some extra effort beyond writing their replacement, but I can only understand that if you think I am proposing leaving the renderers as they are now, where logic and HTML are all mixed up and it's a complete pain to make small changes to HTML output without effectively forking large bits of core Moodle logic. Instead I propose taking the Bootstrap pattern library as a template for modular functions which can be easily updated or replaced and having those small modular units represented by newly created renderers.
e.g.
Good current renderer:
https://github.com/moodle/moodle/blob/master/lib/outputrenderers.php#L2329-L2335
Bad current renderer:
https://github.com/ds125v/moodle-theme_bootstrap_renderers/blob/master/renderers/core_renderer.php#L46-L116
Overriding the first is easy whether the HTML content is compatible with Bootstrap or any other framework as it does one fairly standard thing in isolation. Overriding the latter is a complete pain regardless of what the default HTML looks like since the decisions are all hard coded and presentation is intertwined with logic.
You could of course tease all those hard-coded decisions out, then rebuild it with nice modular code that can represent both Moodle's traditional choices and allow people to make their own decisions about how the login info should be presented. It might be quicker and easier to just shift the old renderer in one go into the Base theme for those who require or desire backward compatability though and not waste time attempting to recreating something that already exists when you could put the effort into making sure the new code is useful.
And where is the diagram for your proposal?
You seem to be suggesting that overriding the the Bootstrap renderers in core will require some extra effort beyond writing their replacement, but I can only understand that if you think I am proposing leaving the renderers as they are now, where logic and HTML are all mixed up and it's a complete pain to make small changes to HTML output without effectively forking large bits of core Moodle logic. Instead I propose taking the Bootstrap pattern library as a template for modular functions which can be easily updated or replaced and having those small modular units represented by newly created renderers.
e.g.
Good current renderer:
https://github.com/moodle/moodle/blob/master/lib/outputrenderers.php#L2329-L2335
Bad current renderer:
https://github.com/ds125v/moodle-theme_bootstrap_renderers/blob/master/renderers/core_renderer.php#L46-L116
Overriding the first is easy whether the HTML content is compatible with Bootstrap or any other framework as it does one fairly standard thing in isolation. Overriding the latter is a complete pain regardless of what the default HTML looks like since the decisions are all hard coded and presentation is intertwined with logic.
You could of course tease all those hard-coded decisions out, then rebuild it with nice modular code that can represent both Moodle's traditional choices and allow people to make their own decisions about how the login info should be presented. It might be quicker and easier to just shift the old renderer in one go into the Base theme for those who require or desire backward compatability though and not waste time attempting to recreating something that already exists when you could put the effort into making sure the new code is useful.
And where is the diagram for your proposal?
I wasn't talking about LESS or other CSS pre-processors, I was talking about a minifer/compressor, namely the PHP port of YUI CSS compressor.
https://github.com/tubalmartin/YUI-CSS-compressor-PHP-port
These are very tricky bits of code, and Moodle currently has two homegrown ones, one of which has no tests and the other was still marked as experimental because it was breaking some code the last time I looked at it. We should just plug in that one as it's based on a very widely used methodology and it's got comprehensive unit tests.
https://github.com/tubalmartin/YUI-CSS-compressor-PHP-port
These are very tricky bits of code, and Moodle currently has two homegrown ones, one of which has no tests and the other was still marked as experimental because it was breaking some code the last time I looked at it. We should just plug in that one as it's based on a very widely used methodology and it's got comprehensive unit tests.
I've read over all the posts on this again and I'm still totally baffled by the collective response.
How can you introduce a new Moodle front-end, which you yourself seem to acknowledge as "the way forward" without at least implicitly deprecating the other, older method?
Isn't deprecating just the official way of saying, "this is no longer the way forward"?
All the concerns about people needing to make long term plans are exactly why people use deprecation. So that people know that a change is coming and can prepare for it appropriately to align with their own internal timescales and priorities.
It was the least interesting part of my post, just a reminder to clearly communicate decisions that appear to have already been made so that everyone has sufficient heads-up for future plans and is on the same page. Keeping those decisions and plans obscure isn't helping anyone.
How can you introduce a new Moodle front-end, which you yourself seem to acknowledge as "the way forward" without at least implicitly deprecating the other, older method?
Isn't deprecating just the official way of saying, "this is no longer the way forward"?
All the concerns about people needing to make long term plans are exactly why people use deprecation. So that people know that a change is coming and can prepare for it appropriately to align with their own internal timescales and priorities.
It was the least interesting part of my post, just a reminder to clearly communicate decisions that appear to have already been made so that everyone has sufficient heads-up for future plans and is on the same page. Keeping those decisions and plans obscure isn't helping anyone.