Where is the info on the December release of Bootstrap 4 coming from? There was speculation that it would be released *last* December, but obviously that didn't happen. There apparently has been work going on in a private repo for a good while, so in theory they could release it tomorrow. On the other hand they usually have months of public alphas before release, so this December seems more likely as a release date, I've just not actually heard anyone state that as a target date. I've not checked recently so if there is new info on potential release dates it would be good to have a source for that.
But I'd like to keep emphasising how much Bootstrap 2 and Bootstrap 3 share, because if you believe everything you read on this forum you'd think they were two entirely separate projects, and (based on nothing more than speculation since it's not been publicly shown at all yet) how much they both will share with Bootstrap 4. The core of Bootstrap is just industry best practice, they even share a great deal of their basic HTML with every other competing framework, as well as between versions. I never wanted Moodle to adopt Bootstrap 2.3.2, I wanted us to adopt "Bootstrap" and to grow with it as time passed, that includes the upgrade to 3 we've been putting off for a couple of years, and a future upgrade to 4 whenever it gets released.
The opposite of that point is to emphasise what Bootstrap 2,3,4 don't share with current Moodle. They won't use tables for layout, they won't lack a responsive grid for layout, they won't let people use any random classnames for alerts that they want and magically hope that it works somehow, they won't expect every element to be hand-coded in subtly different ways every time it's used. All those things need fixed regardless of Bootstrap version.
The unspoken assumption seems to be that Moodle is so bad at planning upgrades of 3rd party components, that if we start working on Bootstrap 3 today, then Bootstrap 4 is basically off the table forever so we need to choose now and forever which exact version to support. Why don't we just commit to "Bootstrap" and plan for upgrades as and when they arrive?
David Scotson
Příspěvky uživatele David Scotson
The actual proposal from the group at the Hackfest was to *add* Bootstrap 3 to core, not to upgrade the existing Bootstrap theme. Bootstrap 2 would still exist and any theme's based on it would work unchanged.
The many people already using Bootstrap 3 based themes wouldn't be deterred if it wasn't the default in the first version, or even if it had a "warning: not quite ready" label on it. But having it in core would be helpful for various reasons outlined in this thread, chiefly that the limits of what you can achieve within a theme have been reached and fixes to core code are required to advance, and importantly that it would signal that we're actually planning ahead and not just burying our heads in the sand about this and hoping that Bootstrap 3 will go away if we pretend it doesn't exist for long enough.
I could have a long and interesting conversation about why the integration of Bootstrap 2 caused so many issues, but let's just say that I don't think it was anything to do with Bootstrap itself, more to do with the fact that the obvious route forward was ignored repeatedly until popular pressure built up and forced a change. De-ja vu?
The many people already using Bootstrap 3 based themes wouldn't be deterred if it wasn't the default in the first version, or even if it had a "warning: not quite ready" label on it. But having it in core would be helpful for various reasons outlined in this thread, chiefly that the limits of what you can achieve within a theme have been reached and fixes to core code are required to advance, and importantly that it would signal that we're actually planning ahead and not just burying our heads in the sand about this and hoping that Bootstrap 3 will go away if we pretend it doesn't exist for long enough.
I could have a long and interesting conversation about why the integration of Bootstrap 2 caused so many issues, but let's just say that I don't think it was anything to do with Bootstrap itself, more to do with the fact that the obvious route forward was ignored repeatedly until popular pressure built up and forced a change. De-ja vu?
Yes, I've seen this work, in at least one case it's involved rolling back changes I made in order to make the new code 100% compatible with Standard theme and the old Moodle way of doing things rather than using the design principles of Bootstrap 2, which is the current default theme of Moodle. Which worries me greatly as it'll be the second perfect opportunity to fix the frontend APIs that's been missed.
In general it seems we're chasing the *shiny tech* rather than do the boring stuff like make the front page or login page a renderer so that people can change it in themes without core hacks. I have nothing against the actual changes in themselves, but I think the process of setting priorities must be very broken for that to have happened before the basics that need done. (Did I mention we still use tables for layout?)
I personally use the Element Library that Totara released a couple of years ago. It got offered to core but they wanted to write their own, but it's been a great deal of help to me when working on themes, and still seems far more comprehensive than the one currently in core.
In general it seems we're chasing the *shiny tech* rather than do the boring stuff like make the front page or login page a renderer so that people can change it in themes without core hacks. I have nothing against the actual changes in themselves, but I think the process of setting priorities must be very broken for that to have happened before the basics that need done. (Did I mention we still use tables for layout?)
I personally use the Element Library that Totara released a couple of years ago. It got offered to core but they wanted to write their own, but it's been a great deal of help to me when working on themes, and still seems far more comprehensive than the one currently in core.
It's a little bit sad that I noticed that my comments from January 2014, when Bootstrap 3 was previously decided against apply so neatly to the current situation, and even then it was just a repitition of what I'd suggested a year before that when 2.6 planning was happening:
I would have thought that if a task takes longer than a single dev cycle then the obvious thing to do is to break it into smaller tasks that can be shipped individually. If we delay starting on this for another 6 months (note when this bug was filed) then that's just 6 months more work being done on older Bootstrap without clear guidance on what's going to happen next dev cycle.
My institution upgrades every (northern-hemisphere) summer to the even versions i.e. we're still on 2.4 and moving to 2.6 this summer (with the intention of using a Bootstrap 3 theme), with 2.8 planned for next summer, so I'd be happy to see some advance thought given to what's going to happen in that time frame so that work can begin now rather than be delayed again in 6 months time because it's been left too late to get it all done in a single dev cycle.
When the FRONTEND team asked in the forum for input on their plans for 2.6 I suggested (amongst other things, like upgrading to Bootstrap 3):
- Copy current renderers into Base theme
- Rewrite all current renderers with Bootstrap compatible code
- As part of above, break current renderers into modular logic and display parts...
- ...and tweak renderers API to better suit modern frameworks (might need simple API translation layer in Base renderers)
- Shift a few more bits of code into using renderers that already exist (alerts etc.)
- Shift a few more bits of code into newly written renderers (grids, a-z pickers, forms, ...)
and that still seems like work that needs done to help the front-end and are easily broken into bite-sized chunks of progress that aid those working on Bootstrap 2.3 and/or Bootstrap 3 and/or YUI Pure and just generally makes life easier for Moodle devs and themers.
What can we do to avoid having this conversation for the fourth time in another 18 months?
Framework agnostic Moodle isn't one solution, it's an infinite number of solutions.
Bootstrap 2 and 3 aren't 2 different solutions, it's more like 1.1 solutions since they share so much code and design philosophy (though people keep telling me how difficult the upgrade will be, two years after we did it and shipped it).
Moodle has been following the pipe-dream of supporting any and all frameworks for a long time, while not even doing much to make that happen, and it has achieved almost nothing. Only an elaborate series of hacks even allows Moodle to look vaguely like Bootstrap. Has any other attempt even come close to implementing a third party front-end system into Moodle? Not beyond demos and proof-of-concepts. Yet both Bootstrap 2 and 3 Moodle Themes are used widely in production. It's not a coincidence that basically every comparable system to Moodle (and thousands of others that aren't) has adopted Bootstrap as a core framework to build on.
Even if we achieved this lofty goal, of supporting Zurb and YUI Pure at the same time, it would add no value to teachers and learners using Moodle. It won't even help devs who all walk in off the street knowing JQuery and Bootstrap. We shouldn't let the perfect be the enemy of the good here. Bootstrap gets the job done, I'd would be good to see some commitment to it, and plans for fuly integrating it, not vague and unworkable plans to replace it at some point in the future with some unspecified other.
Bootstrap 2 and 3 aren't 2 different solutions, it's more like 1.1 solutions since they share so much code and design philosophy (though people keep telling me how difficult the upgrade will be, two years after we did it and shipped it).
Moodle has been following the pipe-dream of supporting any and all frameworks for a long time, while not even doing much to make that happen, and it has achieved almost nothing. Only an elaborate series of hacks even allows Moodle to look vaguely like Bootstrap. Has any other attempt even come close to implementing a third party front-end system into Moodle? Not beyond demos and proof-of-concepts. Yet both Bootstrap 2 and 3 Moodle Themes are used widely in production. It's not a coincidence that basically every comparable system to Moodle (and thousands of others that aren't) has adopted Bootstrap as a core framework to build on.
Even if we achieved this lofty goal, of supporting Zurb and YUI Pure at the same time, it would add no value to teachers and learners using Moodle. It won't even help devs who all walk in off the street knowing JQuery and Bootstrap. We shouldn't let the perfect be the enemy of the good here. Bootstrap gets the job done, I'd would be good to see some commitment to it, and plans for fuly integrating it, not vague and unworkable plans to replace it at some point in the future with some unspecified other.