I am developing a lot of extensions and this information would be very helpful.

? it is not a framework level responsibility to make changes based on the CSS framework in use by the template, if one is in place. It is also not a framework level responsibility to broadcast what UI tools are active. Also, what happens if you are using a hybrid of multiple frameworks (I do have projects in production that use components of Bootstrap and Materialize since the primary framework missed features that the secondary framework filled in wonderfully)?

No it not a change its just an information that is provided to help extension developers.
I want to clarify once more because there is a misunderstanding: no changes! just an informational var.

There is no practical benefit to it, even as an informational variable. And it wouldn't cover the case of either not using a framework or not using a full stack framework and selectively including components to fill your use case. It stops becoming an informational variable as soon as extensions start doing $app->getTemplate()->framework === 'bs4' style checks and change their behavior based on that reported framework.

It's really not my job as an extension developer to provide an out-of-the-box solution to have a working UI for every possible framework. It's the site owner's responsibility to make that seamless integration by overriding the layouts I provide and adjusting them to their needs. The extensions which have backend conditional behaviors to load jQuery, or load one of several CSS frameworks, or generate markup for one of several CSS frameworks are to be honest far too complex and over-engineered. I worry an informational variable like this would result in more end users expecting extension providers to provide out-of-the-box support for a high number of CSS frameworks and the end result is annoyed extension providers with bloated software packages because CSS frameworks are a dime a dozen these days or providers telling users no and losing business because they won't support every single thing out-of-the-box.

I would see it practical. because instead of changing settings in n-Extensions you set it up once at one place and the extensions can get their informations there. If they don't provide anything for the framework its fine, they will show the default they provide... This variable is not forcing anyone to do anything.

On its own not yet, but there are several other proposals adding this exact same variable and expecting core to use it. As soon as it merges those same proposals are going to come back into discussion and it's going to be harder to say no on those because we're already exposing the information.

And again, this only works if you use a full stack framework, as in your template imports the full Bootstrap build, or Semantic UI, or Materialize, or whatever your taste is. This info var becomes useless if you only use select components of a framework, or multiple frameworks. Again, my company has production sites which use a in house framework with various utilities and custom flexbox based grid system and select components generally from Materialize and Bootstrap frameworks. How does this information variable work in that type of scenario? Do I put a <framework>custom.bs4.materialize</framework> tag in my template manifest and expect someone to understand that? Or do I put each component of the frameworks in use in that tag, which becomes a hot mess to maintain (and what if those components don't include something an extension expects to work with)?

JLayout is already prepared to do just that (suffix). Now we only need one central place where we can define that. Since the template seems to me the most logical place.
In Your szenario you leave it blank.

Or better, put in what you like, because you can make overrides of layouts with your own suffix ;-)

^^ That's the exact proposals I was saying would show up.

^^ misunderstood.

If you can't define a framework your template is basically based on leave the variable blank
you can still do overrides.
no one is forced to to anything.
Extension developers that render for example Forms see already that the form has to be rendered with xy Framework markup.
I am open to any other solution that does not force the user to set 5 times the same setting instead of saying it once as an information and whoever wants to use it can use it.

As mentioned by Michael, what happens if a template decides to not import the entire CSS framework (a likely scenario)?

I agree with Michael here, it is not the responsibility of the framework/cms to "control" the UI.

• the information is set by the template developer, so if he decides not to use a framework he does set it to none?
• there would be no control character in this, only informational character
  @mbabker you had once also a great idea to register the grid classes somewhere, can you reference to that ?

there would be no control character in this, only informational character

then it is useless

I am open to any other solution that does not force the user to set 5 times the same setting instead of saying it once as an information and whoever wants to use it can use it.

Well, in my experience, I have not seen this type of setting outside of form building extensions, and even then only inside the Joomla ecosystem. I've not seen this type of setting or informational variable in any platform I've worked with and at a technical level I don't think there is a need for one to exist in any of the platforms I've worked with. So personally, I think if you've got 4 or 5 extensions installed on a site that is setting that type of framework variable, I would personally say there is some major over-engineering going on in those extensions, and I would almost suggest that those extensions probably make it difficult-to-impossible to efficiently use layout overrides to have fine grained control over the markup structure (actually, I do know at least one form builder makes this pretty damn painful).

there would be no control character in this, only informational character
@mbabker you had once also a great idea to register the grid classes somewhere, can you reference to that ?

It wasn't for the grid classes. It was the layout modifiers that are trying to replace things like the column count for category blog layouts. #18319 (comment)

And then we have to update this every week as a new framework is released because if it's not complete then it is useless.

We could do it just like @mbabker proposed it for the colums in blog here: #18319 (comment) Template developers can, if they want, provide the same for rendering fields and we are fine

That system (carried forward into #21106) is designed to remove a bunch of the UI options in favor of using CSS classes to modify layouts (if you look at the modifiers added in #18319 it really has nothing to do with a CSS framework). It has nothing to do with exposing what framework is in use.

I am fine if we provide the same for forms and form classes (labelclasses, inputclasses) - then extension developers can make use of it.

That concept doesn't really apply to forms at all. The concept from that PR is framework agnostic, it does rely fully on a template adding whatever CSS they choose to create element modifiers (such as all the options added in that PR which use nothing but CSS classes which can be easily duplicated into any template).

Forms are very heavily coupled to a CSS framework. And because the form builders are written in a way where you are building everything in the backend UI and (at least with Chrono and RSForms the last time I personally had to do any work with either of those components made it pretty difficult if not outright impossible to manage the markup structure in layouts of any kind), the only thing you MIGHT be able to do is basically exactly what was suggested at the beginning of this thread, expose some kind of informational variable that says what framework might be in use by the template for rendering forms and hoping that every extension provider buys into reading and using that informational variable and every template provider buys into setting that variable. At face value, it's just a flawed variable for way too many reasons, and IMO at the end of the day it's just not going to work because in too many cases by your own suggestions a lot of us would have to leave that variable empty because we don't just blindly import the entirety of one framework but selectively import bits and pieces (and even use multiple frameworks) so the extensions are still going to have to have their options; there's very little gained at the end of the day.

We could do it just like @mbabker proposed it for the colums in blog here: #18319 (comment) Template developers can, if they want, provide the same for rendering fields and we are fine

Isnt that the whole point of layouts and custom-elements so that the template developer can swap them out. - I don't see how having a global var stating the template framework would help in any way.

please don't

we already need to update our extensions for J4 and BS4

yes, if we had infinite time
we would love to have everything being CSS framework agnostic
and also implement N layouts (potentially already complex layouts) for N frameworks

while at the same time they would be -conflict- free in all scenarios

also how many bug reports ?
once you add this, you will have extensions called broken
and even worst Joomla will be called broken ...

really how much of the workload you would expect this to cause ?
to developers and to Joomla core itself ... ?

workload will happen because of user expectations,
please do not blackmail more time out of extension developers

Better we try for something like the work described here:
#20623

and after the above,
and after Joomla form elements are also CSS framework agnostic

then something like this might be considered,
but still it should be limited to 2 or 3 options

Ok, I think the whole request is misunderstood.

It's not about anchoring in the core how and if a css framework is specified in the template manifest.
It is the idea to offer the possibility to specify this centrally somewhere. Here I consider the template manifest to be the right place, since the template developer knows best what he uses.

If nothing is specified here, everything stays the same as before. If a css framework is specified here, it can be specified as a suffix in JLayout. JLayout can handle this without breaking everything, because if there is no file with the suffix, the default is taken (without suffix). Everything stays the same as before too.

Nobody tells the extension developer to implement his layouts for all css frameworks, but if a developer wants to do that, he has the option now. Because if JLayout does not find a file with the suffix, the default will still be loaded and every developer has to write it anyway.

Some bad-mouthed speakers would now say, because anyone can write whatever he wants, right, but I'm sure that will be settled by itself.
Maybe we can make suggestions to name css framwoks uniformly, for example
Bootstrap 2 => bs2
Bootstrap 3 => bs3
Bootstrap 4 => bs4
UIKit2 => uikit2
UIKit3 => uikit3
Gantry X => gantryX
Helix X => helixX (is based in Bootstrap)
and so on

By implementing this feauture I see only benefits and none of the arguments mentioned above shows clear disadvantages, except the laziness of the developers to be able to respond.

So I do not understand why such a simple feature, which brings in my opinion only benefits, meets so much opposition.

@degobbis

In general i agree that

• this is not bad from the users perspective
• in fact i had similar thoughts and i see the benefits
• already working on this (BS2 and BS4)

but the following is a real joke

..., except the laziness of the developers to be able to respond.

exactly what i was taking about, thanks for confirmation
not quickly agreeing to do (and to support) e.g. in our case 50 layouts x 7 frames = 350 layouts (or much more) and we are called lazy

but whatever, please update everything in joomla forms , JHtml, etc to support the above and we will also try it

As stated so many times above, this request should not force developers to provide all those frameworks. No no and again no. Its just a service to them to grab the information WHEN needed.

Instead you prefer the user to search for the settings around your extension instead of grabbing it automatically.

You even don't need to provide anything framework specific. You can just deliver a default that works for all frameworks. If you have a special bs4 layout you will be able to say "if framework == bs4 -> do this".

Now we have on one side extensions that ask:
What framework are you using?
What framework are you using?
What framework are you using?
What framework are you using?

This request is changing this to:
I am using no framework.

OR:

My Template is based on UiKit3

Again:

1. Not forcing anyone to do anything with this information
2. It decreases only the number of parameters in the system
3. Instead of asking n-Extensions to one it's distributing the information to all
4. When a template is not based on a specific framework the setting is set to "none"
5. This setting does not have to have all available frameworks listed, i never saw extensions using something else then the above mentioned ones. Even Helix is based on bs4 as far as I saw... So it would be enough to have the most used ones
6. Increasing UX by decreasing settings and parameters

Other solution would be the ability for the template developer to specify own framework specific classes for containers, rows and columns and form specific layouts in a template that can be used accross extensions. That would decrease workload for developers a lot because they would not have to worry for any framework and just build their layouts like

div class="$templatecontainer"
div class="$templaterow"
div class="$templatecolumn-1-12"
/div
/div
/div

If nothing is specified here, everything stays the same as before. If a css framework is specified here, it can be specified as a suffix in JLayout.

That is the part I wholeheartedly disagree with. Our PHP framework should not be making arbitrary global changes because a template specifies a certain CSS framework is in use. This is not needed, at all. And again, this proposal focuses so heavily on using a single framework and all of its utilities, it does nothing to support workflows that many use, to include not importing a full framework or importing utilities from multiple frameworks.

Nobody tells the extension developer to implement his layouts for all css frameworks, but if a developer wants to do that, he has the option now. Because if JLayout does not find a file with the suffix, the default will still be loaded and every developer has to write it anyway.

It starts that way. But if said variable actually picks up popularity or use with templates, then end users are going to expect developers to support it and go to extensions who do and abandon extensions who don't.

Maybe we can make suggestions to name css framwoks uniformly, for example
Bootstrap 2 => bs2
Bootstrap 3 => bs3
Bootstrap 4 => bs4
UIKit2 => uikit2
UIKit3 => uikit3
Gantry X => gantryX

Gantry's not a CSS framework and if we're going to start putting the bloated Joomla template frameworks in this parameter then IMO you're making this beyond unusable, which it already is if you're not building templates against a single framework and importing all of its stuff (even if not used).

It decreases only the number of parameters in the system

This assumes every vendor buys into supporting this system. Are you aware that there are quite a number of vendors who have distanced their code as far from the Joomla framework as practical (both from a PHP and UI perspective) and would never support such a thing?

When a template is not based on a specific framework the setting is set to "none"

Defeating the purpose of this to begin with, because, every extension still has to have its own setting to make it work right!

This setting does not have to have all available frameworks listed, i never saw extensions using something else then the above mentioned ones. Even Helix is based on bs4 as far as I saw... So it would be enough to have the most used ones

That's a short sighted view. I do work commonly with Semantic UI and Materialize frameworks, by this argument you're basically saying "oh nobody uses them in Joomla so they don't matter".

Other solution would be the ability for the template developer to specify own framework specific classes for containers, rows and columns and form specific layouts in a template that can be used accross extensions. That would decrease workload for developers a lot

Not really an option. Not every grid system is based on the Bootstrap 12 column grid or even compatible with it and trying to create a grid abstraction layer is a level of insane even I'm not willing to attempt.

So I do not understand why such a simple feature, which brings in my opinion only benefits, meets so much opposition.

Because it is the wrong way, it is not the resposibility of the framework/cms level to control the UI.

I think all arguments have been exchanged.