Columns option was supposed to be removed with #18319 but some related code remains.

@ciar4n can you give an update on this? Are columns still being removed?

Get rid of the options. It's been totally superseded by the grid classes you've mentioned @SharkyKZ

except that is completely undocumented and unnecessarily breaks all upgrading sites with a complex option that requires code knowledge instead of the current simple solution

This is the type of option that should've never been part of the component options to begin with. It always should've been at the template level. Now you have a set of options that might be friendly in the user interface but results in complex as hell code in the layouts because it has to dynamically calculate everything to set up the "grid" correctly. And it is inherently tied very explicitly to the Bootstrap 12 column grid (at least in 3.x) meaning there really only are 5 sane options you can set.

Just like I hinted at in #18319 (comment) we need to massively expand the template manifest and how the template is integrated to various forms to expose options. Or you end up with what Elisa was suggesting and we basically start building page builder type configurations into core.

the current simple solution

Well, the web has moved forward, css grid layout is here to stay. That said is pretty stupid to serve two gods (css grind and Bootstrap grid) at this point (css grid has support for over 90% of the browsers). Also hardcoded template positions seem a very outdated approach for css grid...

I am referring to the solution being simple for the user and not about the technical aspects of how it is implemented. The user couldn't care how it is done - they just need to know what to do.

I would say remove all column options. Classes are more versatile, remove any b/c promise and simply the views.

and how does a user know what to do?
how do they know how to get their old layout working again?
Without a user knowing what to do it doesnt matter how versatile it is

I agree on Brians point, these classes need to be either well documented by the template. Or and more ideally, classes included in the template XML and in turn be presented within the UI.

Finally someone understands what the hell i am talking about.

It would be great to have similar to Michael's suggestion (#18319 (comment)). I am largely at sea outside of CSS so I am certainty not the one to attempt to implement it.

So, adding a section to the template manifest is easy (especially as we refuse to maintain XML definitions for our schemas). Adding a form field to use this data is relatively easy (it essentially has to behave like the tags field, multiselect plus the ability for users to input their own customizations). What is difficult is the fact that all of our management UI is so far detached from the template that it's painful to deal with this efficiently. The default behavior would be to load the modifiers of the default template, but what happens if the template style is set to another template for that menu item? Presumably on category views we would want a modifier type option to go hand-in-hand with a layout option (think the category blog menu item and the option to set the article view layout).

Sooner or later I honestly feel like we need to do some deep thinking with how the template integrates with everything in Joomla. Like it almost needs to become a component in terms of service type structure and a system plugin in that it is loaded on every request so that the template can more efficiently hook the rest of the system. Sure, you can do that with plugins. But, for something that is supposed to dictate the look and feel of your website, it is painfully difficult to hook the template into the management UI to expose options related to the look and feel of your website, not to mention that at the content item level there are options that really belong to templates or layouts and have no business being in our data structure, even as parameters.

The default behavior would be to load the modifiers of the default template, but what happens if the template style is set to another template for that menu item?

Then the menu item will also need to override the CSS Grid modifier to be used

How do you manage such a modifier field in that case? That’s kind of the
workflow issue that needs spec’d out before anyone puts code time in here.

On Sat, Jul 21, 2018 at 7:44 PM George Wilson notifications@github.com
wrote:

The default behavior would be to load the modifiers of the default
template, but what happens if the template style is set to another template
for that menu item?

Then the menu item will also need to override the CSS Grid modifier to be
used

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#21106 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoRDTyOajDedOqTw84UMoaPYYK6amks5uI8rtgaJpZM4VPgcL
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

The default behavior would be to load the modifiers of the default template, but what happens if the template style is set to another template for that menu item? Presumably on category views we would want a modifier type option to go hand-in-hand with a layout option

For me modifier classes should only go hand-in-hand with the template. It is only the template than can decide if it's design can accommodate, for example, a 4 column blog layout. Sure the modifier class remains with the menu item, but if that class is not defined within the template CSS then it will not and should not impact the layout.

That part makes sense. What I'm saying though is how do we deal with loading the modifiers when on the menu item edit page? Do we just load all of them the same way module chrome is handled? Or is the field contextually aware of the template style setting, which inherently means its data has to be somehow refreshed if you change it?

I guess ideally the field has to be contextually aware. There is no way CSS classes can be realistically created that will work in every instance. For example a 2-column modifier class for a category blog layout will not work on say a menu item dropdown without over complicating the CSS.

We also don't want the previous situation where the location of the 'Module Class Suffix' was often dictated by Bootstrap.

Sorry I may have misunderstood.

You are referring to how is a menu item to be aware of what template classes are be to loaded. My guess is the module chrome approach is the easier option. It does give the user the added benefit of been visually able to see what classes are linked to what template from within the field.