Im more than happy to utilize CSS grid in core views, providing that if an extension developer for some reasons want to load the entire BS CSS file and use their grid, it wont conflict.

Cause as we discussed yesterday, not all devs are comfortable with CSS

I can't see an issue in this regard. Nothing stopping extension developers from using a Bootstrap grid inside a CSS grid if they so wish. That situation currently exists between the template and the core components.

An issue for me is where to include the grid CSS. Add it to the template means all template developers will have to include the same CSS in their templates. The other alternative is to include with the component. Note that the only core component using a grid appears to be com_content.

A 3rd alternative is to create a mini CSS kit that will always be loaded with Joomla 😉

The template should dictate the design, so including the CSS in the actual template would seem the most logical approach. It's up to other template devs to decide whether or not they wish to utilize it

True. The only thing that bothers me there is that you now got a Joomla feature that depends on defined CSS outside of the CSS framework. The upgrade process becomes that little bit more complicated as you now have to add/create this non framework CSS within your template to allow certain features within Joomla to function correctly (Eg. Category Blog -> Blog Layout -> # Columns).

This is the reason why I am against fields tied to CSS properties. There should be just one field (class) and let the template define if and what layouts are available. The '# Columns' field under Blog Category -> Blog Layout is a good example. Replace such options with a single class field and IF the template dev wants the option for 2 columns then they can create the class (eg. 2-columns) and document it in their template documentation. This simplifies the options and means template devs are in no way restricted. They want articles to display in some random grid format... they create a CSS class for it!

Yup, I see exactly where you're coming from.

But then again no matter how you look at it, it will always require the template to import something, be it:

JHtml::_('load.CssGrid');

or:

@import "blocks/css-grid"

I agree with the fields though, they do really need to just burn and die, but I can think of a handful of people that would like to keep it the hard/improper way.

Not necessarily as without the '# Columns' field, items will just display in a single column with the default display:block. No grid/layout CSS needed.

Unless I am mistaken this is the only multi-column grid in all the core frontend component views.

As much as I agree that the backend options are bloated, especially with things that most of us with a technical skill set would never touch, we also need to keep in mind the users who are not technically savvy and rely on options like these to manipulate the frontend output. I do think the class based solution works, but our class options are only targeting a select number of elements in the default layouts and aren't going to cover all the use cases we have for other options. So I'm only going to post this to play devil's advocate and say that whatever the end state is should still be something that is relatively easy for users to customize some basic things without having to have the skillset to heavily edit and maintain customized layout files.

We may not like or use it (or something like it), but there is a reason WP invests so much into their theme customizer UI.

In this case (# columns field) I don't believe a class based solution to be any more difficult. It does however remove the responsibility of the blog 'layout' from core to the template. For me this is right as not every template can account for a 6 column blog layout in their design (a somewhat exaggerated example).

TBH I am not totally hell bent on removing the '# Columns' and other similar fields. I just appreciate any conversion which explores the alternatives.

Anyways... on removing the '# Columns' field and instead promoting the use of classes to replicate the same blog layouts..

The pros

• Not dependent on a specific CSS framework
• No grid classes needed in the component views
• No limit to the number of layout possibilities. Some example classes off the top of my head...
  • 2-column
  • 2-column-masonry
  • 3-column
  • 3-column-masonry
  • Style specific.. https://www.pinterest.ie/explore/blog-layout/
• Template developers don't have to worry about breaking the columns field simply because their design doesn't allow for it (eg. masonry/grid layout)
• Simpler component view (https://github.com/joomla/joomla-cms/blob/4.0-dev/components/com_content/tmpl/category/blog.php#L95-L100)
• Moves the responsibility of the blog 'layout' from core to the template
• Future proof

The cons

• Less descriptive field naming. Not all users will connect 'class' with how something looks
• A B/C breaks if users have anything other than a single column layout.
• Complicates template upgrades from 3.x to 4.0. CSS will need to be added to create the classes for replicating the old layout options (eg. columns-1, columns-2 etc). Probably best to document how in JDocs.
• Moves the responsibility of the blog 'layout' from core to the template

In reality a lot depends on how this would work in the wild. We can promote good practice with the new frontend template and add some nice blog layout variation classes. But ultimately it depends on what template developers do with it. As they would no longer be restricted by the columns options they may create some nice layout alternatives.

Regarding the WP theme customizer UI, for me the key difference is their UI effects the theme and not the core output. It is the theme that defines what can be changed within the customizer (presuming I remember correctly).

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18149

closed as having Pull Request #18319