Will test it out next week. Will make the transition much easier then to J4.

Personally I'd suggest creating a separate CSS file and only call it when Joomla is in Development status. This will give extension devs the chance to test when they should be (alpha/beta/RC).

Like so:

$version = new JVersion;

if ($version::DEV_STATUS === 'Development')
{
	JHtml::_('stylesheet', 'bs2-grid.css', ['version' => 'auto', 'relative' => true]);
}

Last thing we want happening is people sticking with their BS2 grid which may be somewhat buggy in Atum with all the other BS4 classes

Extensions will end up with mixed markup for BS2 and BS4 when we don't provide such a legacy way:

<div class="row row-fluid"><div class="span6 col-md-6">Foo</div></div>

Or are you really suggesting that we go again the way to have an if in every view to to load the proper layout if we are on j3 or j4? Which leads us to have duplicated code. I think we should learn from the past and do better and not having the same problems as we had between j25 and j3. I'm aware that it comes with an extra cost of additional CSS loaded but we can't force to break all extensions if we can provide such a lightweight migration path. What we have to do is to clearly document it, that it is for migration purposes only.

we can't force to break all extensions if we can provide such a lightweight migration path

A. Lightweight? It's nowhere near lightweight, bootstrap on it's own is a css catastrophe, adding more staff on top of it is even worst.
B. Devs convenience is something that should be always within reasonable limits. J4 is a major upgrade and things WILL break naturally! HTML markup and css has evolved a lot since BS2, Joomla should not keep the old code for the next 5 years just to make 3RD PD happy and not update their views.
C. Obviously this path that Joomla is following is not the best either for users or developers. There is a solution, half baked already in J3 and is called overrides. I'm saying half baked because overrides should have 2 inputs, one for a descriptor of the final markup and another one for the data from the model. This way the template is always responsible for the final markup (in a programmatically way, right now it's just static, means someone has to code that override, time and time again).

I certainly wouldn't load that rules by default and also not in debug mode. Maybe offer it as a standalone "migrate.css" file which may be optionally loaded by extensions if they need/want it.
I fear that when we load it by default, it will give a wrong signal for extension devs and they may not spot errors in the layout files.

Maybe offer it as a standalone "migrate.css" file

Possibly the best solution. Loading in just debug mode means extensions potentially display differently depending on the mode.

@Bakual @ciar4n @C-Lodder In his comment he meant DEV_STATUS === 'Development' no debug mode = on. Please see the code in #17190 (comment)

I'd say the best 2 options are:

1. Load the migrate.css when in Development status

2. Don't load the migrate.css at all. Primarily because if we do, extensions dev may see that their extension works fine and may not both updating to the BS4 grid classes. If we provide a migration plan on JDocs, this would probably be the best approach.

Load the migrate.css when in Development status

Honestly, that would be a very bad idea and wouldn't solve the original issue.

wouldn't solve the original issue.

So what is the original issue here?

@Bakual and the original issue being.....?

I understood Allon that he likes a way to ease the pain for 3rd party devs when adjusting the layouts so they work both in J3 and J4 (since extensions are supposed to work in J3.9 and J4.x).
Back when going from 2.5 to 3, we had to write and maintain two layouts which were loaded based on the running Joomla version. That wasn't especially nice but worked of course. However if you plan to support both versions in your extension for a longer time, then that's going to bite you back.

From the original PR comment:

which will make it easier for 3PD to test their extensions on Joomla 4

Then please read my comment again:

Last thing we want happening is people sticking with their BS2 grid which may be somewhat buggy in Atum with all the other BS4 classes

I do get where you're coming from however BS2 grid with Joomla's core using BS4 is not a good approach.

1. Let's try not to mix logic from 2 major versions of one CSS framework (which is borderline two totally different frameworks at this point)
2. I would not try to emulate the span* classes personally but instead direct map them to col-md-* and leave it be (or even col-* since BS2 doesn't have the notion of different grids at different sizes)
3. We are never going to be at a point where you can write one layout file that works with two major versions of anything. That's just not practical, unless you really want to litter that one file with a massive crapton of conditionals. I would still suggest, even having done this myself with my own code, that maintaining a separate set of layouts per template is going to be the most optimal solution. Ya that might be a painful choice if you've got a large extension or numerous extensions, but in the long run it will be the cleanest solution unless you're going to write an abstraction layer in front of the templating layer (Akeeba Strapper for example).

I do get where you're coming from however BS2 grid with Joomla's core using BS4 is not a good approach.

Don't get me wrong. It's not something I want. ?

First thing is that we are talking here about the back end, where performance is not that important. If we have a migration layer then there is a unified way of supporting legacy extensions. If we don't do that then every extension needs to do it's own thing, which will end up in a big mess.

If you can't install a Joomla 3 extension on J4 then we will not gain much acceptance for the new major version. We really need to take care about our eco system. We have to rewrite all templates for J4 allready and we are now driving into a direction where all extensions need to be rewritten when we upgrade to Joomla 4. That would definitely be then a cut we are not going to survive. Extension devs, site integrators and template devs will just run away.

Honestly for me it is very frustrating that there is so much resistance against a legacy mode for the output layer. IMO we should work for the big picture, when all is upgraded and migrated to have the superfast and slick system. But for the transition period there needs to be some compromises we have to make. Having a legacy layer would be for me an acceptable solution.

We have to rewrite all templates for J4 allready and we are now driving into a direction where all extensions need to be rewritten when we upgrade to Joomla 4. That would definitely be then a cut we are not going to survive. Extension devs, site integrators and template devs will just run away.

It was clear from the very beginning that extensions will have to rewrite their layout files for J4 (and thus templates have to follow), at least to adjust to BS4. I'm a bit surprised you see that as an issue.
And yes, for the "transition period", you will have to maintain two layout files. How long that period is, is the choice of the extension developer. Personally, I will have only a few versions which work both in J3 and J4 and successive versions will drop J3 and adopt J4 features.

I'm a bit surprised you see that as an issue.

So we are doing the same mistakes for every major version again and again? A very bad signal to the Joomla community.

And yes, for the "transition period", you will have to maintain two layout files.

I really don't see the point when the core can provide a migration layer, why we should not do it.

I really don't see the point when the core can provide a migration layer, why we should not do it.

If we're about to provide such a migration layer, then that one needs to be for css framework/markup agnostic, otherwise we don't solve the real problem here, we just quickly patch it:

Obviously this path that Joomla is following is not the best either for users or developers. There is a solution, half baked already in J3 and is called overrides. I'm saying half baked because overrides should have 2 inputs, one for a descriptor of the final markup and another one for the data from the model. This way the template is always responsible for the final markup (in a programmatically way, right now it's just static, means someone has to code that override, time and time again).

needs to be for css framework/markup agnostic

How can we do that when we switch from one framework major version to another? As far as I understood your web components concept this is the target we are working to it. But it doesn't solve the migration problem as we are still dealing with the transition from BS2 to BS4. That's what we are trying to solve in this pr and nothing more.

@laoneo I've already described how such a thing could be implemented: https://medium.com/@MIT5O5/lets-build-it-then-ca6541b2cc93

Web components are just a part of the big image of decoupling Joomla from any css framework, the fundamental elements are still bonded to the markup of any css framework is chosen, which bring us to the infinite loop of breaking things whenever the css framework is altered!

PS. It's not that far away from @nibra Joomla X content blocks (I think that's the right term)

Yes and that's nice and wonderful but as long as the core doesn't have such a feature we should not talk about it as a possible solution for the transition layer. The back end got converted to BS4 and on J3 it is BS2. So we have to find a solution to make that transition as painless as possible for the current situation and not for something which perhaps will be implemented somewhere in the unknown future.

@laoneo we agree that this needs to be addressed. We disagree on the implementation, you propose a short term patch, I propose a long term solution ?

imho both are valid.
The short term issue is reducing the pain points for extensions designed for J3 running on J4
The long term issue is removing any framework dependency

I dont see these aims/issues as mutually exclusive

I dont see these aims/issues as mutually exclusive

They're not, but implementing them (let's say) sequentially we introduce more workload to the 3rd party devs as they'll have to do almost the same work twice

I propose a long term solution

I guess everybody from us has a long term solution for Joomla. The fact is that we need to deal with the current situation. I stopped believing that we should work against a concept when it is not implemented and did not made it into the core. So I try to deal with the current situation. If there will pop up a better solution in the future then I have no problem to change to it. But as long as this does not happen we should see what we can do with our limited resources in a most practical way for the current situation.

but implementing them (let's say) sequentially

I guess this is the only way such a volunteer project can move forward. Step by step.

I guess this is the only way such a volunteer project can move forward

I would expect a different approach here:

• admit that the hard coded overrides layouts is not flexible or fit for the project
• realise the problems shortcomings of our current implementations
• seek for proposals
• accept the best one
• assign the work to a small group of capable programmers
• merge the code to the core!

Job done!

and I want to win a million dollars in the lottery

but I am realistic and will most likely only win a dollar

@brianteeman every dollar counts ?

@dgt41 I guess we all know that such a procedure will take time. Just try to be practical here. Joomla 4 really starts to appear on the horizon so we should not make it dependent on such projects with an unknown time line.

@laoneo oh, come on, you delivered the new media manager in a 6 month timeframe with only 2 more devs contributing there. If there a will there will be a way!

I honestly don't see practical benefit in creating a BS2-to-BS4 bridge layer. The jump is too big for us to sanely make it work. Web components and whatnot help to try and improve that situation at a later time, but you're right it's not helping right now. Without rolling the Joomla CSS Framework, what practical options are there to ensure there isn't this "I can't write a layout that's compatible with 4.x and 5.x" conversation when that time comes? Because even with web components and abstraction layers from all the things, something will still end up with a hard break leaving developers to either maintain two sets of layouts, create excessively complex layouts with numerous version conditionals, or creating complex abstraction layers of their own which come with their own set of problems and pain points.

Seriously, if maintaining two sets of layouts is the worst thing developers have to do with their code to migrate from 3.x to 4.0, I think we've handled this upgrade just fine (remember the only code changes you are absolutely required to do is to address uses of deprecated APIs).

Keep in mind that if you want to support both J3 and J4 in your extension, you will want to adjust the layouts so they fit into the respective UX style of the CMS version. Eg J4 may have no sidebar anymore in core and you want to follow that UX in your extension. Just looking at my own component I already had to adjust several things in my layouts so they fit into the 4.0 style.

Imho, you're likely building two layouts anyway if you want to properly support both CMS versions. The changed bootstrap markup is just one of the things you'll deal with.

Are we still largely against a Joomla CSS framework? Both web components and CSS grid take a large chunk out of the reasons to use Bootstrap. I am not suggesting resurrecting #15225 but instead maybe a separate Github project. A CSS framework would largely avoid us from repeating this conversation in the future.

Also a separate CSS framework project might have some marketing, onboarding and testing value if that framework was to get popular outside of the Joomla community.

Well, let me be frank here. If you, Charlie, and Dimitris dropped off the face of the earth in a freak accident all at once, how many other contributors do we have that have your respective levels of CSS and JavaScript skills? Our PHP needs are covered to varying degrees, but when it comes to working with other languages in Joomla (JS, SQL, CSS and any syntax or compiler involved in creating it, etc.), the number of active contributors specializing in those areas is a much smaller number. If we have the resources to maintain the solutions, and they're viable long term answers to our problems, then I don't want to shut it down before it even gets started, but I also want to remain realistic about where we are now and the resources we have as a whole.

I understand completely and in truth I suggest it reluctantly knowing there is work involved in both code and documentation. A perfect scenario would be that such a framework as a separate stand alone project might encourage both users and contributors outside of Joomla. It is late in the day and I am probably been overly optimistic! :)

Instead of introducing our own CSS framework, we should move that to the templates completely. It should be possible on per-template base to choose a framework. Then everybody can use whatever they are comfortable with, and we never again have something keeping us from being up to date.

I'm not against an own framework per se. But it didn't work in the past. That's why we adopted Bootstrap, a well documented and maintained 3rd party framework.
If you can create a framework of same quality (subjective, I know Dimitri) and document it in the same quality and make sure it can be maintained, then have a go at it.
Even if you manage to do that, eventually you will likely want to do some B/C breaks in that framework as well since CSS is evolving. So I doubt we would indeed gain much here.

Personally I seriously doubt we can create a framework of same quality as one of the existing ones out there. And even if we could, the question remains why we should if we don't gain much by doing so.

But it didn't work in the past.

That didn't work because of classing classes between components/modules/plugins!
I was discussing an idea with @ciar4n in London where we provide the very basic as a framework and views build upon that. Now with the very basic I mean some already available code (e.g. Neckolas's resets) and some basic styling of the core (as platform, w3c) elements. The advantage here is that even if you write something like <button>I am a button</button> it will display nicely. Of course for buttons, forms etc, we need to have some classes (I don't see why not the ones from bootstrap 2.3, so really easy migration path)!
Both Bootstrap and Foundation were intended as an easy way to rapidly create prototypes and not ship that thing in your final product! We are doing it wrong!

@nibra The problem isn't so much a core coupling to a single framework (I think most everything is now in an overridable location, even if some of the override paths are very PHP heavy, like JHtml). It's that the default set of layouts are built against our default templates which are designed against a single framework (Isis and Protostar being Bootstrap 2 with Atom and Aurora being Bootstrap 4). So for at least the backend, you still have to design your extension layouts to a specification for things to sanely work, and there really aren't many other admin themes out there so you aren't trying to build layouts that should be usable with dozens or hundreds of templates.

The only way to fix that is to make the system templates default, redo the layouts in an agnostic manner against that, and move the existing layouts to be template overrides in the fully themed Bootstrap templates; or, the core templates are agnostic or built against the Joomla CSS Framework which if we're lucky has enough styling definitions to be usable, but we're back to the days of there being no guarantee that the template providers are supporting the core style rules (at least with a Bootstrap heavy ecosystem, even with BS2/3, there's still a good chance layouts can be dropped into a template and work pretty sanely more often than not).

This pr turned again into a "how do we solve the universal CSS issue in Joomla" thread. Instead of it should just provide a migration layer for extensions to work almost out of the box on Joomla 3 and 4. We are loosing again focus.

I mean we are talking here only about the grid, not the whole Bootstrap 2 styling. So what is the real issue with that approach?

So what is the real issue with that approach

The real issue is that those two grids are totally incompatible.
Also since CSS Grid has landed for every browser (except IE11) do we still want to trap the project in some very opinionated, very limiting old grid system (that's either BS2 or BS4, both are already outdated!)
Also since the web is moving towards modularity how clever will be that joomla still depends upon a monolithic and really bloated CSS Framework?
And lastly, whatever the solution here might be, how disruptive will be now (migrating from 3 to 4) or for the future upgrades (e.g. 4 to X)?

Unfortunately the real issue goes way deeper than providing some fallback classes...

I understand that and all your points are absolutely true and it should be the target we are heading to. What we should do is to make the transition easier, to show the community that we learned form the past mistakes. We will loose trust, if we we are repeating the same failures.

I guess we all agree that web components is the future and we should already work into that direction by migrating the core. But we CAN'T force an eco system which is now working for 5 years with the same code base to break just because of some ideological point of views. We need a painless transition to let extension devs convert on their pace and not on our dictate.

I mean I'm not proposing this here just for fun. It's all based from my day to day experience dealing with Joomla site admins.

@laoneo - If it were from BS3 to BS4 then I'd think differently, however seeing as the difference is 2 major versions, I think a dedicated JDocs page, with a step by step migration process would be more appropriate.

I say this cause I know there will be devs out there that will test their extension on J4 and think, "oh yeah, it works, now they're starting to make everything B/C, which means I have to do sod all". As mentioned before, we don't want to have BS2 and BS4 markup combined as it could cause a potential cluster****

As much as that would be nice, I think that should be considered for J5 which a whole new approach to list/edit views. For me personally, 3PD's shouldn't need to write any markup for standard list and edit views in the backend.

Is 1kB of CSS really such a bad thing? Sure it allows some bad practices however that is the 3PDs choice. This is just cosmetics to stop J3 extensions looking a total mess and avoid 3PD and their clients thinking their extensions are totally FUBAR due to Joomla 4.

This pr turned again into a "how do we solve the universal CSS issue in Joomla" thread. Instead of it should just provide a migration layer for extensions to work almost out of the box on Joomla 3 and 4. We are loosing again focus.

You're looking for a "how do I make two templates designed against two different CSS frameworks compatible with one another" solution. From a practical perspective, there isn't an answer to this that I would consider good. Not all markup snippets are built to be universally plugged into any template. A "your Bootstrap 2 layouts will work with zero change in our new Bootstrap 4" message might sound encouraging to users and developers, but it will create a maintenance hell (if you've never had to work in a project where you have two competing CSS frameworks in use, consider yourself lucky; that's what BS2 and BS4 are at this point). Even if we do implement a compatibility layer for just the grid aspect of BS2, there are still many other design changes in the new template that by the time you account for them all it's just not going to be practical to try and use one layout file for both templates. This isn't even a Joomla 3 versus Joomla 4 issue to me, it's the fact there are totally new templates which are not compatible with one another in a large number of ways.

@ciar4n Any intentions on dealing with row-fluid?

if you've never had to work in a project where you have two competing CSS frameworks in use, consider yourself lucky

As extension developer you have to deal on a daily basis with BS2/BS3/BS4 and UiKit. Guess I know what I'm talking about.

Just to be clear here. We are talking about the back end. We are talking here about the situation to support <div class="span5"> and to prevent situations like <div class="span5 col-md5"> and to prevent the need for extension devs to write code like if(JVERSION == 4) $loadTheBS4default.php; else $loadTheBS2default.php;. It is not about front end and it is not about that we want to encourage devs to mix BS2 and BS4.

BS2 and BS4 markup combined as it could cause a potential cluster

I guess @ciar4n found a way to introduce the BS2 grid in Joomla 4. Or do I miss here something?

I guess @ciar4n found a way to introduce the BS2 grid in Joomla 4. Or do I miss here something?

He emulated a small subset of classes if I read the issue description right. Like I said before, I'd really just map those to another set of existing classes instead of trying to recreate them.

It is not about front end and it is not about that we want to encourage devs to mix BS2 and BS4.

It's still 2 competing templates with 2 competing structures that aren't 100% compatible, it doesn't matter how many compatibility classes you add to the CSS, if there are markup changes then it's game over. A component with a subnavigation menu (i.e. com_content) has a different markup structure in J3 and J4 so at least your main layout file is going to have to be version conditional or you're going to have to hack up a solution to make that work right on both versions without a conditional, that's just one example I have off hand.

The only real way you're going to get layout compatibility between the two major CMS versions is to use the same template in both. Even if we used a new BS2 template in J4, the odds are high that you would still have to have conditional behavior because a new template would not be a 1-for-1 duplicate of Isis. As long as we change the template, developers are going to have to review their layouts and make appropriate updates; there's no getting around that, and it's even happened with updates to Isis in 3.x.

Honestly, if

<div class="span5 col-md5">

works and allows to build a single layout, then that is by far the preferred option in my eyes.
But again, I doubt those spans are the only issue you need to solve. There will be many more and you end up with two layouts anyway.

if(JVERSION == 4) $loadTheBS4default.php; else $loadTheBS2default.php;

Nothing wrong with that as well of course. What I did in J2.5 > 3.0 was like this:

if (new JVersion()->isCompatible(4.0))
{
	$this->setLayout($this->getLayout() . '40');
}

That worked perfectly fine.

if there are markup changes then it's game over

The purpose of this pr is to make some compatibility efforts which will work for most of the standard Joomla 3 extensions. The markup of the grid will not change between BS2 and BS4. The target is NOT to make a complete BS2->BS4 bridge.

new JVersion()->isCompatible(4.0)

I guess that's what almost all extensions did. Now you want to force them again to do that? Really?

I'm sure this pr helps almost 90% of all extensions to work out of the box in J4. It's so minimal effort. But honestly what frustrates me here most is that two extension devs, which are running an extension based business, are proposing a solution and have to fight with people which are doing it as hobby. Did somebody here wonder why it is that way?

Oh, and one more thing: we're very optimistic that there will be a Bootstrap 4 stable (or even Beta) before Joomla 4. We're betting way too much on BS and I hope to be proven wrong here, but probably we're gonna loose this bet

@mbabker As I see it there is a bit of a b/c 'issue' with mapping span classes to the current flexbox classes (eg. col-md-). Flexbox classes are a lot more strict regarding markup. With the old BS 2.3 span classes devs got away with nesting spans and still managed a reasonable outcome...

An example directly from Joomla 3.7 com_articles..

<div class="span12">
  <div class="span10">...</div>
  <div class="span2">...</div>
<div class="span12">

With flexbox (bootstrap 4) this is no longer possible. So instead I floated the span# grid so to still allow for the old (arguably incorrect) markup.

As pointed out correctly this pr does not account for row-fluid.. i'll fix that the first chance i get

The markup of the grid will not change between BS2 and BS4.

The grid markup doesn't change. But the markup we're using to build pages has changed. There are subtle changes in the HTML structure which means that there are more changes required than just mapping a subset of classes and creating a compatibility layer for CSS. So even though this might help keep some aspects of the grid system working, in and of itself this doesn't mean that it's going to mean your Isis BS2 layouts are going to just work on Atum BS4.

I guess that's what almost all extensions did. Now you want to force them again to do that? Really?

The only way to stop this cycle is to redo the admin template in a Joomla platform specific build and to never change the admin template again going forward. As long as we have a process where the entire template might change (irrespective of the underlying framework), everyone is going to be left in a spot where they are going to have to adapt their layout generating code. So are you saying we should just leave Isis and BS2 in J4 and avoid the problem altogether?

I'm sure this pr helps almost 90% of all extensions to work out of the box in J4. It's so minimal effort.

Yes, this helps. But this is not a complete solution. And I've looked at the J4 backend as one of those hobbiests you seem to be talking down on and an extension solution provider, I see what areas of my backend layouts are working fairly efficiently with zero change in the new template and I see areas that are going to require updates. To me, it is acceptable that I'll need to make minor updates as it is a new template, I don't have a what I consider to be unrealistic expectation that I can take a layout designed against Isis using Bootstrap 2.3 standards and drop it into Atum using Bootstrap 4 standards and it work with zero effort required on my part. So long and short, this bridging layer for the grid may help, but let's not kid ourselves here, you are not going to have properly compatible layouts between the two major versions without reviewing each of your layouts and the components involved in generating them (form XML) and making minor adjustments. I do not want to see anyone trying to tout that by the time J4 releases existing backend layouts will be 100% compatible because quite frankly that's going to be a complete lie.

Below is a screenshot of a company component's backend installed into the current J4 nightly build with the CSS changes of this PR applied. The grid for this layout is now fine, but stylistically, my layout is still massively wrong as it relates to the new template's design. If this were a distributed component, I would not be satisfied with shipping this to users as I know it is broken, I will have to make changes (either by adding CSS classes or adjusting the markup) to adapt it for J4. If this were a distributed component, dependent on the scope of change this may result in having separate layouts conditional to each version, or it may be as simple as just including the extra CSS classes to make things display fine (one quick change I made after grabbing this screenshot was to change the main list container to <div id="j-main-container" class="span10 j-main-container">, the markup structure here sucks but it is functional and is backportable to J3 without needing version conditionals, so who cares if I have CSS classes for the two major version in my markup other than purists?).

I'm aware that it will not work 100% and that minor adjustments are needed, but I'm confident that we lower the barriere for extensions to work on J4 out of the box and that it is not needed to have duplicate layouts. Don't get me wrong, I don't want to block the progress to web components or new frameworks. The target was to make J3 extensions work on J4 without rewriting all the layouts.

Initially I'v talked with @ciar4n, if it would be possible to make some grid bridge between BS2 and BS4 and according to this pr it worked out.

The target was to make J3 extensions work on J4 without rewriting all the layouts.

That's the target I'm concerned about. It's a new template, it should be expected that updates in the layouts will have to happen. We can help with that transition to an extent, but I don't think it is a realistic goal to make Isis layouts just work in Atum with zero effort from developers, and I get the feeling there is some push to make that happen.

All of this has me thinking of another possible issue.

<div class="row">
    <div class="span5 col-md-5 col-lg-4">
        <p>Foo</p>
    </div>
    <div class="span7 col-md-7 col-lg-8">
        <p>Bar</p>
    </div>
</div>

With this span class mapping layer, how does that affect the layout if a developer does try to use the classes for both grid systems to natively use features of whatever is the active template?

It should continue to work as is however my guess now is that there is no need to float the elements. In fact that float is probably been ignored due to the display:flex of the parent row. It allows nesting simply because it sets a width property compared to col-md-. If this is something that is going to be considered, I will have to test it further (im out atm). Initially I hadn't considered this as something that would allow the same markup and classes in both 3.9 and 4.

This is fine as is and will work in all scenarios I can think of. The float is required if the spans are not parented by a flex element (eg, class="row"). In cases where both span# and col-md-# are used the BS4 classes will be applied presuming the classes exist in the framework (BS4/J4).

Can not be a problem the row as it is different in BS2 and BS4? In Joomla 3 we use row-fluid, when we add here row, it's get messed up then on Joomla 3 or not?

@laoneo This is not a problem. In BS2 the items within a grid are floated. In BS4 the grid uses flexbox. Any floats inside flexbox are ignored by the browser.

Here is a screenshot how it looks without the patch

And here with it

Just for the record, that it works with the web links package.

Instead of adding it into the main css file of the template can we provide it as a separate script. So an extension can run the following code:
JHtml::('script', '/media/css/system/bs2.css');

In J3 this will do nothing as the script is not available and in 4 it adds the migration script. Like that we do not pollute the main template's CSS file in J4 but J3 extensions will look ok in J4.

So is this ready for testing or not? Just to add my two pence. In my extensions I use PHP classes e.g. $rowClass $columnClass $columnSize. Then when i want to make a Bootstrap 2, 3, 4, Gantry 5, Helix, whatever, they all commonly have row and columns so I can just set the variables. Wouldn't that solution work here and make the code maintainable in the future? I know it doesn't take anything other than grids into account including components and all the other stuff, but to solve this one problem?

It can also work for flex / grid I think (haven't checked in any detail).

As another solution... perhaps there could be an installer validator which would install and state "it appears you are using an older version of Bootstrap, please see this documentation for instructions on how to update"

In any case, how do we bring this PR to a conclusion in one form or another?

Closing... can be re-opened if required.