Did you add the correct Menu Class Suffix? I can't re-install Joomla at the moment, but if you look at the current top menu module, you can get it from there.

@C-Lodder just installed a clean 4.0 (without sample data) and moved the "Main menu" module to "menu" position.

I can't even install Joomla at the moment cause of this: #16788 :)

I'll take a look when it's working again

ok so i tested WITH sample data and it's ok now.

So the issue is when installing joomla 4.0 WITHOUT sample data.

Also the default render of links for that position should not be that color IMO.

Did you ensure the module/menu class suffixes were the same when you did and didn't have sample data?

WITHOUT sample data i didn't put any module/menu class suffixes

I understand what you're saying @C-Lodder with the Menu Class Suffix from sample data work fine.

But IMHO there are two issues here:

1. WITHOUT sample data shouldn't the menu module be on top too?
2. Even without the menu specific class suffix shouldn't the links have color contrast? See for instance what happens when you put a custom module with text/links in header positions (no contrast in links or text).
   

The default joomla.sql should have the right parameter values needed to make things work out of the box. So we probably need to just add the right classes to that parameter for the module and it'll be fine.

Even without the menu specific class suffix shouldn't the links have color contrast? See for instance what happens when you put a custom module with text/links in header positions (no contrast in links or text).

Part of the problem is you can't really hardcode the menu module to any specific convention as it can theoretically be placed in any position on the page and a user may elect to use different menu styles (i.e. https://www.joomla.org/about-joomla.html uses the menu module in 2 different layouts, in addition to our top navbar element). So as a generic thing, you can only go so far with it without requiring the user add classes in the parameters.

1. yes that's the issue to solve.

2. IMHO when you have darker backgrounds by default you should use lighter colours (for text, links, borders, etc). so in aurora header the default color for the header class should be, for instance, white text and white links, not a css expert (probably a better way) but something like could solve it

.header { color: #fff; }
.header a, .header a:link, .header a:hover, .header a:active { color: #fff; text-decoration: underline; }

I'm with @andrepereiradasilva on this. These links should be styled out of the box so that means by the template and not bootstrap classes.

The CSS bit that @andrepereiradasilva posted is fine to at least deal with the contrast part. Likewise, the default SQL files should have the parameters set up in a way where things are just correct when it's installed. But we should be careful about making the menu module display things in a specific way; that's where framework modifier classes or layout overrides come into play.

I agree to a point however I believe any default data in the class suffix fields will cause an extra complexity when a user changes template. Moving all styling to the template means a user can change template without having to edit each class suffix field. Consider the current navbar-nav mr-auto in the Menu Class Suffix field of the top menu... this will likely cause an issue if changing template more often than not. The reason for the issue would not be very obvious if a user is not familiar with the class suffix fields.

Without changing the user's workflow, I'm not sure what options exist. You could use module chrome, but that's also template specific and would require changes with each template (so no easier or harder than the module class suffix option). You could just hardcode a wrapping container into the template around the <jdoc> tag, but that seems inflexible to me. You could hardcode mod_menu with framework specific markup and options, but that's not going to end well.

mod_menu is just one of those beasts where it's difficult to have "good" defaults in the module without coupling it to a template or framework. So to me the first best compromise is the class suffix option; it does let you style the output to the template and to the different variants a template or framework may provide (again I'll point out how on our websites we're using three variants of Bootstrap's navigational components, navbar and navs).

mod_menu is just one of those beasts where it's difficult to have "good" defaults in the module without coupling it to a template or framework

That's what overrides are for, or not?

Right. But if the default template has to make use of module overrides, something seems really off.

I guess it once again boils down to the tight coupling with bootstrap. An avid bootstrap user would probably be quite comfortable using the class suffix fields in this manner. However outside of Joomla I don't believe it to be quite so true. Sure using bootstrap classes gives a somewhat rough handed flexibility but in a lot of these cases I don't see the point. When would the top menu be anything but horizontal and do we really want that level of flexibility when the result are often rough at best.

Personally I think it better to style within the template using template classes instead of bootstrap (eg. .top-menu { ... }). At least that means the sample data can be free of bootstrap classes.

Personally I think it better to style within the template using template classes instead of bootstrap

As long as there is thorough documentation on it then we can make it work. But Joomla's documentation is still massively lacking and no aspect of the UI has ever really been well documented outside of Bootstrap's documentation for 2.3.2. I just don't want us to get into a hole where we're back to the 1.5/2.5 days of nothing about the core UI (markup structure, CSS class use, etc.) is documented and we're all fighting to figure out how to make things work; at least just using Bootstrap conventions everywhere gave us a documented structure to build on. The other thing that worries me is if we start to create a UI abstraction layer, at what point do we draw the line on it being an abstraction layer versus a full stack CSS framework in its own right? I don't think we need to get into the business of having that as well.

When would the top menu be anything but horizontal

For a top menu it's probably fine to wrap that position in a way where you only have a horizontal menu. But that's template logic, not something that gets forced into mod_menu.

I agree. Here I simply propose having the styling added by the current bootstrap classes in the class suffix fields moved to the template CSS so they are styled in this manner by default without the need for adding any classes. So such styling is dictated by the module position rather than the addition of a module/menu class or use of a module chrome. In my opinion the Module Class Suffix and Menu Class Suffix fields are best suited for modifier classes. So the template sets the default appearance via CSS and the modifier classes are used to create alternatives. Modifier classes can be either from the coupled CSS framework (bootstrap - eg. card-success, card-info etc.) or the template. As you say any modifier classes from the template will have to be correctly documented. For now there is none to speak of.

My reasoning here is to try and move presentation away from content. IMO these should be separate as much as possible and the admin UI/UX should reflect that. So the likes of com_content controls what is displayed and com_template controls how it is displayed.

The other thing that worries me is if we start to create a UI abstraction layer, at what point do we draw the line on it being an abstraction layer versus a full stack CSS framework in its own right?

What I suggest doesn't really go that far. We could create new modifier classes unique to the template however only when we need to go above and beyond the bootstrap CSS.

What I suggest doesn't really go that far. We could create new modifier classes unique to the template however only when we need to go above and beyond the bootstrap CSS.

I only bring this up because over the years people have come up with proposals that really blur the line between abstraction layer and us having our own CSS framework. I'd really like for us to not have our own CSS framework if it's at all practical.

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

The frontend has a different template so this is no longer applicable.