I have tested this item ✅ successfully on 1786095

I fully agree with this change. This way we keep this nice and important feature and it is consistent with parameters like the "menu class" and "header class".
That being said, those two parameters should be renamed to "Menu Class Suffix" and "Header Class Suffix". The menu one had that suffix as well in J3 and got changed in J4, the header one for some reason was missing it already in J3.

@ciar4n you might wanna comment here

Changing the existing functionality break pretty much every site I created without a good reason. So this PR is really appreciated.

Before reverting this change it is important to review the comments on the original PR where this was created.

@Hackwar That someone was me

A suffix promotes a completely un-modular form of CSS. It is rightfully rarely used for this reason. If this really is an issue for you then, to give your own advice, you can create an override. This is a lot easier now since the module class was moved to a single place (#17447).

That change was mostly done in #18300 after that one was merged #17026

This PR brings Joomla 4 to the dark ages, again. You should seek modularity not tight couplings, you're doing it wrong!!!

@dgrammatiko Please stop arguing with "you're doing it wrong" and "dark ages". That's a completely subjective argument.
Also, the possibility to use suffixes doesn't stop you in any way of creating your "modularity" approach. Just add that space into the box. While the current state mandates a class and prevents a suffix which removes a nice, simple feature and breaks backward compatibility for no real reason.

@ciar4n Overrides have a big drawback as you have to check after each update if the original file got changed, and if so update your override with the changes (if needed). So if you can use a suffix instead of creating an override to achieve the desired result, it's much better.

It is rightfully rarely used for this reason.

On a sidenote: Apparently it's used more often that you thought. Just because you only use it rarely (or even never) doesn't mean it's not used often.

I think the issue goes back to when this feature was first added into Joomla. Technically, a suffix is a letter or group of letters added to the the end of a word. I dont know if Joomla's intention was to support a "module class suffix" or just a "module class" (separate class) but it would appear that both have been used in different scenarios.

It's a shame this single space wasn't added when the feature was first added

@Bakual sorry you're wrong here. What the initial PRs did was to enforce best practices for element classes. You want to undo this because there are people doing CSS wrong in the community. So degrade the whole product to keep the few ones that don't really understand CSS...
Great, I see this pattern all over this project: ignore best practices because people are used to do things on a very awkward way...

@ciar4n Overrides have a big drawback as you have to check after each update if the original file got changed, and if so update your override with the changes (if needed). So if you can use a suffix instead of creating an override to achieve the desired result, it's much better.

That sounds like double standards. Overrides has always been used as a get out clause for many previous arguments. As soon as that argument is flipped, overrides become a bad thing.

@dgrammatiko so you think its better to change the behavior that exists since ages and break many pages because "you are holding it wrong"?

I have not a problem to introduce a new parameter and deprecate the old one but if you like that joomla 4.0 is a one click update (which it should) then you can't do a b/c in the frontend modules.

@HLeithner Joomla 4 update realistically will not be a one button, if you think your old Bootstrap v2.3.2 will work out nicely when moved to Bootstrap 4 you're misinformed. Your sites are already broken just because of the CSS framework update...

@brianteeman The PRs where this was done don't meantion backwards compatibility at all. I don't see any good argument for changing this in the PRs.

@ciar4n A suffix might be rarely used and be unmodular, but the field is named suffix and it is used as that heavily throughout the Joomla community. If you don't want it to be suffix, then add a new parameter that is not named suffix. The way it is now, you might as well have changed the parameter with the name "show_title" and used that. Parameter names have a meaning and when it is called a Module Class Suffix or a moduleclass_sfx, then that has the meaning of a suffix, not of a field to add classes. That you can add such a class by prepending the field with a space is a nice feature, but doesn't change the original meaning of the field.

@dgrammatiko There is a difference between best practice and reality. We are not sitting in an ivory tower where we can simply enforce best practices without regard to existing infrastructure. This is a change for the sake of change and means a hard b/c break for most sites, which forces them to rewrite template CSS and edit a lot of modules. And all of that because you think it is nicer to enforce that. No, that is not the way to go here.

If you want to write your own CMS from scratch, you can introduce changes like this if you want. But in a CMS like Joomla, you can't break an 11+ year old behavior like this without it being an actual bug.

Overrides have a big drawback as you have to check after each update if the original file got changed,

Thankfully this is now automated in Joomla 4

I have not a problem to introduce a new parameter and deprecate the old one

Please no more params

It's a shame this single space wasn't added when the feature was first added

True, but in the days that it was added the common convention was to create new classes not add additional classes. So a typical usage at the time was to create -red, -blue, -green variants of the existing classes and not simply add an addition class just for the color

@ALL Times change, coding standards and best practice change

@dgrammatiko You will be astonished how well sites will update to 4.0 with the one button update. But regardless of that, there is a difference between updating the central CSS once or having to edit potentially thousands of modules.

@brianteeman I'm not questioning that a parameter named module class would be the better solution and current best practice, but I'm saying that changing the usage of a parameter is a no-go. If you are so keen on adding that space, add an additional parameter named module_class and add that to the module chrome. Mark the module class suffix as deprecated if you want, but there is no way that we can ship this the way you did it now.

but there is no way that we can ship this the way you did it now.

Not me

You will be astonished how well sites will update to 4.0 with the one button update

Yeah sure! Most of Joomla sites a lot of devs are delivering is a plain Bootstrap out of the box. These ones will probably work nicely, but ask yourself if actually this is a good thing for the platform in the long term...

@Hackwar - J3 to J4 requires:

• removing calls to scripts that no longer exist
• changing calls to scripts that have changed
• all template overrides to be re-done
• all modules to be reassigned to new positions
• all extensions to be updated (assuming they even support J4) for UI purposes
• probably more

You've already got major B/C breaks. Reverting the space in this PR isn't going to make upgrading to J4 much easier in the long run.

There was already a PR that @ciar4n did to start adding BEM type classes to core extensions for you to target in CSS. I'm not sure how far it covers all extensions but it would be wise to move to this approach.

Ideally Joomla needs one big shift to start progressing. I can't see it happening over multiple major releases as this would be a cluster****. So it needs to happen now or it never will. Once it happens, upgrading to future major releases will become easier. If it doesn't happen, well you'll have the same B/C breaks every major release.

@C-Lodder Yes, and the "probably more" in this case is a non-obvious change that could go unnoticed for years before the site owner notices that that one module, where he used that feature once. What you listed are obvious changes, this one is completely non-obvious, especially since the parameter is named the same, but now behaves differently.

having to edit potentially thousands of modules.

@Hackwar That is been a little dramatic and untrue. Create a single file override (module.php) and remove a space. And that would be a minority of cases. Offhand I can't think of a template provider that has used a suffixed class in this field in the last 5 years. Checking major template providers, they all either create an override, adding a space or require classes to be appended with a space within the field. Sure the later is the out of the box solution but no one can argue that this is somewhat strange, especially to first time users.

And I take your point about creating a new field rather than amending the current one, but that is just creating new options when we are supposed to be trying to reduce them. And all to keep a largely redundant field that is very much from a bygone age.

It's a shame this single space wasn't added when the feature was first added

It was intentionally done this way. Because it offers more flexibility.

That sounds like double standards. Overrides has always been used as a get out clause for many previous arguments. As soon as that argument is flipped, overrides become a bad thing.

No, not double standards. But having to write an override just to remove a space is ridiculous.

What I honestly don't understand: Why do you want to change a behaviour which already allows to do what you want, but will prevent other people from doing what they want?

I strongly believe it's our job to support "best practice". It's not our job to enforce "best practices" (which btw are outdated in two years).

@Bakual

Best practice in this scenario is adding support for a custom class. You type it in, you know the name of the class, you can thenadd your custom CSS to target this class.

A class suffix has always been somewhat pointless IMO. Adding a suffix to a class that already exists, meaning that if Joomla ever changed the core class in an update (which we have done in J4), the user would automatically lose their styling.

Using a suffix rather than a separate class couple you in to Joomla's class set.

The fact that we've alredy changed the majority of default classes in Joomla means that the majority of suffix's will already be broken anyway.

If you genuinely want to remove the space an go back to the odler approach, then by all means, carry on, but make sure you do it properly. You will need to look back at the entire commit history and add any classes that were removed. Only then will you prevent, and I quote, "a hard break in B/C for 4.0."

No, not double standards

Em.. yes... this is a double standard. Quite a perfect example. The stance on overrides has always been a double standard, changing depending on the point being argued. I'm pretty sure I used it both ways myself.

But having to write an override just to remove a space is ridiculous.

Equally having to create an override just to add a space is just as ridiculous. Something templates often do to simplify the use of variation classes.

What I honestly don't understand: Why do you want to change a behaviour which already allows to do what you want, but will prevent other people from doing what they want?

The point here is that the 'Module Class Suffix' ideal has become very much the minority use case. @C-Lodder is correct in saying that it probably best it wasn't added. If it wasn't, we certainly would not be here having this discussion to add a suffix.

all template overrides to be re-done

Then someone has screwed up royally. In moving my own site from 2.5 to 3.0 (yes, this site was an early adopter), I was able to copy in the 2.5 based layouts where my template was not overriding things and the 3.0 markup was just too far incompatible with that template and aside from a couple of quirks with hardcoded markup was able to retain my template until time could be invested in a full UI upgrade. If the upgrade from J3 to J4 mandates that the template be changed at the same time then the product upgrade has been mismanaged (and no, I'm not talking about potentially minor edits or pulling that same trick with copying the 3.x layouts in as overrides in a 4.0 install, I'm talking about if the core platform has changed so much that any template designed on 3.x cannot run on 4.0 at all).

The 4.0 project should not be approached in a way where someone says "hey, B/C was already broken for this, screw it let's just go all in". Unless you really want the project to put out another 1.6 style update. Anyone who was using the product in 2010-2012 remembers how well that went over.

@mbabker the trick you did with 2.5->3.0 is what @ciar4n repeatedly offer as the solution here but people for some awkward reason don't won't to use overrides...

Or, here's a bright idea. WordPress is effectively a headless CMS. Drupal is effectively moving to be a headless CMS. Why doesn't Joomla get with the times and stop having such a highly opinionated and painful as all hell UI layer already? Every proposal to decouple the "core" UI from the default template of the month gets shot down because "overrides are evil, Bootstrap all the things!".

A class suffix has always been somewhat pointless IMO. Adding a suffix to a class that already exists, meaning that if Joomla ever changed the core class in an update (which we have done in J4), the user would automatically lose their styling.

Ideally, the class where the suffix is applied is some generic class like "module" or "newsflash". Those are not likely to change in an update. Unlike a Bootstrap styling class like "well" or "card". However adjusting the CSS to take care of those would be simple with a suffix as well - just search/replace the "prefix".

The latter case is also an example where the suffix shines. You want to remove the "well" styling of that module chrome (which is hardcoded as default chrome into the position) but want to keep the HTML structure of the chrome, just add a suffix and the styling is gone. No CSS or overrides used at all.
You can then still follow "good practice" and add a second class for your own styling. But in your own styled class you don't have to revert all the stuff from ".well" first, you can concentrate on your own design. With the "class" approach, you have to revert all the styling first in your own CSS for the added class, or you create an override.

As said, it's about flexibility. If you don't like it, fine. It's simple to add a space before the suffix to get an own class.
If that concept is confusing for users, maybe it can be explained with a tooltip/placeholder/whatever. But the word "suffix" should actually be clear enough.

But why have classes like well and card in core layouts in the first place? I know they exist at the moment but I really don't agree with them.

For a start they couple the core layouts to Bootstrap in areas that are unnecessary. Surely better to not have such classes in core? Then if a user wants card styling, they add 'card'. They want a well, they add 'well'. With what you are suggesting, a user must first figure out what class is in the layout and then decide if it needs to be removed to add their own class. It really is not intuitive that if a user wants a card they have to add something like '_remove card'.

Your base class should have just minimal styling and should not really need to be removed.

But why have classes like well and card in core layouts in the first place? I know they exist at the moment but I really don't agree with them.

Here we agree ?

But let's assume my template uses .module to style it's module chrome. This is a perfectly valid class name, not tied to any specific framework. Now the user doesn't like the design and wants to adjust it. If he only wants to adjust the color of the background, he can add red-background and give that class a red background color. If he however wants to style the chrome a bit more differently, he now just adds -customstyle and can use .module-customstyle to style the whole chrome or its content fresh.

It really is not intuitive that if a user wants a card they have to add something like '_remove card'.

If currently there is eg a well class and you want to change it to a card, then I would actually prefer to be able to use your example (giving well-remove card over just adding the class which ends up with well card.
However if there is no such well class defined and he just want to add the card class, he doesn't need to add _remove at all. He can just write card and it works since nothing needs to be removed first.

Btw: An override doesn't help at all in that case, as it only overrides the module output - not the module chrome (which comes from the template).

Your base class should have just minimal styling and should not really need to be removed.

Since we're talking about module chromes here (The module class got rightfully removed from the module output in J4), I don't think that's a valid statement. The module chromes are part of the template (they are the "Module Style"). The classes used within those chromes are there for the (default) styling of those chromes. If your template has minimalistic styling on those, that is fine of course. If another template wants to have more sophisticated styling on the chrome, that's fine as well.
I'm sure you agree with me that core shouldn't mandate what a template dev has to do ?

Here we agree ?

I'll raise a glass to that ?

Sure I understand the concept and why it was deemed a good idea but in reality, it causes way more hassle/confusion than it is worth.....

• I think we both agree, your .module class should not contain any opinionated styling that a user would want to remove. It should only really contain properties that effect the module within the overall layout (display, flex-grow, flex-basis, grid-column, grid-row etc.). You would never want these properties removed, otherwise, you are expecting users to include such properties in their new class.
• I'd happily retire if I had a penny for every time I got the following... Q. Why does the template variation class not work / mess up my site? ... Did you add a space before the class?... No...... - For good reason I now add the space in the layout.
• The only good reason I have heard for the suffix concept is to allow the user to remove the base class. Let's not forget that it only allows the user to remove the class beside the moduleclass_sfx echo. What if the module contains multiple classes? Admittedly this only a problem in J3 as it is largely fixed in J4 with #17447 (in core at least). Still, considering the first point this does not seem like reason enough.
• Every example given for the benefits of suffix seems to require some CSS knowledge and how it cascades. Otherwise, this field and the whole 'you need to append the class with a space' for an additional class idea is just weird and let's face it... in the vast majority of cases, a user simply wants to add an additional class.

in reality, it causes way more hassle/confusion than it is worth.....

Here we disagree. But maybe there is another way to lessen the confusion around a class suffix.

I think we both agree, your .module class should not contain any opinionated styling that a user would want to remove.

No, I don't agree. My .module class in my template module chrome has by definition already template specific styling.

What if the module contains multiple classes?

We're not talking about the output of the module. The class/suffixes are completely removed from those in core and thus that issues is gone. If the chrome has multiple classes, then the suffix should be applied to the one which holds the most of the design. But that's up to the template developer and highly subjective.

Every example given for the benefits of suffix seems to require some CSS knowledge and how it cascades.

Of course. Since we're dealing with CSS classes.

in the vast majority of cases, a user simply wants to add an additional class.

I want to see that statistics you cite here. I have a completely different experience.
But then, I don't say you're experience is wrong. It may be the truth in your experience and for your templates. For others it is not and the suffix is used without troubles. It may boil down to the users, documentation and whatever. For me and the single template I created and support, I never had any trouble explaining the concept of the suffix.

Whatever...

I could not have cared less yesterday and will hopefully return there tomorrow. Do as you must. I have attempted to explain my reasoning as best I can. Next time someone attempts to change something, people should push their opinions in the original issue/PR. On this topic the option was there for both. It might save the next person some heartache.

To be fair, I wrote the same thing already in the original issue...

You are not the one opening this PR.

Create a single file override (module.php) and remove a space.

Considering we have gotten so fastidious, this should be 'chrome' not 'override'. My mistake.

Module chrome doesn't support overrides and core only supports chrome discovered in a template's html/modules.php file, so you can't even add chrome without hacking a template. #20864 detailed the issues with it and some ideas for change but we all know how much attention pure PHP changes get around here.

Module chrome doesn't support overrides and core only supports chrome discovered in a template's html/modules.php file, so you can't even add chrome without hacking a template.

Then I am mistaken. If a template is using the Joomla core chromes, this gets a little more complicated.

I want to see that statistics you cite here.

@Bakual You are basically asking me who properly writes modular CSS and who doesn't. If you are using the 'Module Class Suffix' field as you describe and how it was originally intended, then your CSS is not modular.

CSS frameworks are all modular written. So if you are using a CSS framework and this change affects you then it is your own CSS that is to blame, not the frameworks. Imagine for a second Bootstraps codebase if it was class="btn_btn-primary_btn-lg" instead of class="btn btn-primary btn-lg". It's size would increase 1000x. If this is how you write your CSS, then you are perfectly free to do so but I personally would sooner if Joomla did not promote it in it's options.

ALAS... Removing the suffix was always going to be a soft b/c break for old templates. This is the only reasonable reason to merge this PR and honestly I am ok with that. But lets not kid ourselves, removing the suffix is certainly not ...

removing a rather powerful (if misunderstood) feature because "it's too confusing".

All the suffix shows up is our own ignornace in correctly coded CSS... not everyone elses!

All it shows up is our own ignornace in correctly coded CSS... not everyone elses!

Ignorance is a bliss...

All the suffix shows up is our own ignornace in correctly coded CSS... not everyone elses!

The suffix is not about someone who writes a template. It's a user parameter. It's about how a user can adjust template chromes for a specific module. That templates module chrome may be modular written or not, that doesn't matter at all. And stop blaming people of ignorance.
It allows the user to disable existing design and/or adjust it to his needs. Some templates may offer various suffixes for predefined module styling, but that's actually not the main reason for it (a template could achieve that as well with multiple chromes).

And again, we're not here to tell our users and other template devs how they have to do their stuff. We're here to enable them to do whatever they want. Be it top-notch CSS or last decade CSS doesn't matter. We're not the CSS police, we're a CMS:

The suffix does not change the module chrome. To change the module chrome you change a different field all together - not at pc but iirc it is called module style

Be it top-notch CSS or last decade CSS doesn't matter

Actually it does matter and for me it's really painful to see people fighting hard to keep Joomla at a very bad position: "producing sites as bad as WIX"
https://discuss.httparchive.org/t/cms-performance/1468

@dgrammatiko Honestly, stop it. The suffix behavior doesn't stop you at all from doing what you want, because it has nothing to do with how you do your template. You can already do whatever you want in J3 in that regard.

Ok, can we please delete all messages here except for the first 3 and then get a decision by the maintainers? This is a useless discussion and @dgrammatiko has no interest in arguments but just to force his opinion on us. I have no interest in such a discussion.

Since every rule we have is being put up for discussion, I'd like to have a general discussion about this and this PR is the wrong place for that. Things that I would like to discuss:

• Since when are we allowed to change the meaning of existing parameters?
• What is the ranking system in Joomla that allows some of us to shit on B/C and others being scrutinised to hell and back in regards to that?
• Are we changing stuff in 4.0 for the sake of change or do we have to have good arguments for our changes?

Where should we discuss this? joomla-dev-general?

@dgrammatiko has no interest in arguments but just to force his opinion on us

I'm not trying to force anything here or anywhere in the project. I just happen to follow the best practices on the web an propose changes that align Joomla to those. I guess you're better on your own lonely path that is in a parallel universe to the rest of the world...
I guess some peoples vision is to get a Joomla 3 with new looks as Joomla 4 without solving the problems that turn people away from the project. I'm fine with that, you know, there are plenty alternatives out there...

You know what I hear from people all the time? "Joomla is running an update and I have to check all of my site AGAIN and change stuff that worked fine before." I've never heard someone complaining that they had to put a space in front of their class by hand. No one is claiming that the suffix is the right way to go and that separate, modular CSS classes are wrong. But we are saying that we can't simply change something like this the way you guys did due to B/C restraints. Similar example: We are not forcing people to all trash their gas engines right now and switch over to e-cars, even though it would be the right thing to do. But reality would result in chaos and turmoil. Likewise we are not changing the labels on the gas pumps to diesel without telling people. Otherwise they will wreck their cars with the wrong fuel.

Again: Deprecate the suffix thing for 5.0 and add another parameter with a new name and a new title and introduce your feature that way.

Are we changing stuff in 4.0 for the sake of change or do we have to have good arguments for our changes?

I dont know about the PHP side of things but one thing I do know about the frontend (when I was active) is that everything was heavily discussed and brainstormed. Countless hours on skype calls to try and come up with a good solution.

Unfortunately you will always have pros and cons with everything, and not everyone will be pleased with the result.

That said, the frontend group did everything they thought was in Joomla's best interest.

If everyone feels that J4 is "shitting on B/C" too much which seems to be the case with many PRs, then (and I dont mean to sound like an arsehole) but you may aswell revert all frontend related changes and keep the Isis template.

I get that people are worried about B/C breaks...so am I to some extent, but without B/C breaks....nothing will ever truely progress easily.

you may aswell revert all frontend related changes and keep the Isis template.

There was a lot of good things done in frontend. Also for the suffix stuff. Eg removing the suffix from all core modules (hopefully 3rd parties will follow) so it's only applied once in the module chrome / style.
It's just this small whitespace change we're discussing here that imho went to far (since it removes flexibility and causes more issues than it solves) and I honestly can't believe that this one generates that much posts.
It's in the nature of changes that not all like them. Sometimes it's good to push them through. Sometimes however it's also good to let it stay as is. You can discuss it in your group as much as you like, there will still be things were you as group are right, and there will be things you decided wrong.
And here may be things like this one were you fully believe you were right, and others fully believe you did wrong. And there is nothing wrong about this as long as it's discussed while keeping the respect for the others and trying to understand their reasons.

Since when are we allowed to change the meaning of existing parameters?

Consider that the alternative was to delete the old parameter and create a new one. That would have been a B/C break for all templates that used this field, not just templates with non modular CSS. An initial goal of J4 was to reduce the parameters which is why we never considered deprecating the suffix field which just created more fields for J4. I am happy to admit that this may have been the mistake.

What is the ranking system in Joomla that allows some of us to shit on B/C and others being scrutinized to hell and back in regards to that?

@Hackwar You are the very guy that argued relentlessly for the continued coupling of Joomla to Bootstrap, Joomlas biggest and repeated B/C break. You can't take the higher ground now and accuse us of shitting on Joomla's B/C. It is either freeze development and focus on security updates or consider that to move forward, some breaks have to be considered. Both options sound perfectly fine to me. But unless a definate statement is made by Joomla on this area, dont be surprised if people attempt to step in to the grey area that lays between.

Are we changing stuff in 4.0 for the sake of change or do we have to have good arguments for our changes?

What do you think this thread has been about? We have been trying but you just glass over our reasoning and ask our comments to be removed. Once again.. the reason to change is to promote modular CSS rather than non-modular CSS.

And just in case you need an example.....

Variations with modular CSS promoted by a 'Module Class' field - 4 colors and 3 further style options (border, rounded and shadow)

https://gist.github.com/ciar4n/0e25b6083f9cfd6fee5766d9c782c66b

CSS giving the exact same style variations using non-modular (suffixed) CSS and promoted by a 'Module Class Suffix' field

https://gist.github.com/ciar4n/ed042037f6636712a0b0049f7b37b90f

If you can't agree on what appears to be the best of both worlds ( no space ) then I'd like to make what you would think would be a simple suggestion...
lets add a core plugin that controls wether or not there is a space!!
by default no space. Now everyone can be happy! If you want space go to plugin, activate, viola` space added. EVERYONE WINS

@ciar4n You're example is wrong and you know it. Because even with the suffix no dev would do what you suggested. Everyone would do the modular approach in that case. And that's possible and heavily used in J3 already. It just needs to have a space in front of the class to make a standalone class out of the suffix. It's no magic.
The only reason you want to change this behavior is not module CSS. It's because some users don't know what a suffix is. There are better ways to deal with that than removing that feature. We could improve the UI and documentation so users better understand it.

@N6REJ Actually, he can do (and already does) whatever he wants in his own template. Since the space is controlled by the chrome which is part of the template. He just can't change the parameter name from Class Suffix to just Class. In his own installations, he could however override the parameter text.

Idea: name field class with a little tick box on it's right. ticked means class suffix and we strip the possible space. For existing installations we check for space and we put true to tick or else false. For new installations it's unticked and hopefully in 5.0 we remove the tick box. I know that more parameters is wrong but maybe with some designing love this tick box will be very gentle?

Tick box without label/description would be useless.
If such stuff is implemented, it should be a new field, i.e. a new Option...

You're example is wrong and you know it. Because even with the suffix no dev would do what you suggested. Everyone would do the modular approach in that case.

@Bakual From how your comments read, you appear to have just spent this entire thread arguing the opposite.

Could someone please just add another test to this and get it merged. Changing this field to 'Module Class' breaks b/c on older templates which are more likely to use suffixed classes. Considering chromes are not overridable, a workaround for the b/c issue is not as simple as I originally thought.

I haven't thoroughly thought how this "tick box " can be implemented. Another idea could be visible only if there is a value in the suffix. There must be a smart way considering ux that this functionally could be implemented so everyone wins. The only drawback would be a small "annoyance" by something subtle for the ones they use it with a space before Ofc it would be documented its ise in 4.0 docs

I will leave this final thought here about B/C break:
So what was changed in the relevant PRs and this PR is trying to undo?
Two things:

• A language string
• A minor layout markup change.

People screaming about B/C, please check https://developer.joomla.org/development-strategy.html and let me know how exactly is this considered a B/C break?

I'm quoting the official guideline here:

For the time being, rendered markup is **not** subject to our backwards compatibility promise.

If you won't try to fix things in a Major version, then when will you expect them to get fixed?

From how your comments read, you appear to have just spent this entire thread arguing the opposite.

I never said to not use modular CSS. I said we should not mandate it and I said to keep the flexibility of this parameter.

I'm currently thinking about what Michael wrote in #20864 (he referenced it earlier in this thread) and it's something I wanted to do for quite some time as well.
If someone wants to brainstorm with me how we can rework the current module chromes (eg allow template specific parameters based on selected Module Style), feel free to contact me.

If someone wants to brainstorm with me how we can rework the current module chromes (eg allow template specific parameters based on selected Module Style), feel free to contact me.

Maybe Michaels original issue can be re-opened?

Joomla 1.5 had only the parameters in a modules XML that the module used. General parameters like cache and suffix were injected by the system itself. This feature that I consider very good, was removed in 1.6 against my advise. Maybe this would be the point to bring that back. Consider all the parameters that could be removed from the menu items and modules. You could then also override that XML centrally and when we find a nice way to override chromes, you could modify both the way you like...

So I did a straw poll of my JUG users tonight and none of them use module class suffix's without spaces in (basically they always create new classes). And I think whilst there are a handful of use cases where appending a class can be useful. generally it's not. and it certainly confuses many of our new users. Honestly the majority of people who do care about this are competent users who actually are capable of building module class suffix's. And as a result whilst I understand that this is probably a provocative decision I'm going to decline this PR and keep the new change in behaviour.

FYI: Here is a change for the module parameters to clean some stuff up #23553