Clickable items in navigation without drop-down

[quimgil]

The drop-down items in the navigation bar are great, but is there a way to have plain clickable items, with no dropdowns, defined in MediaWiki:Sidebar or elsewhere? In the documentation I couldn't find any reference to this seemingly basic use case.

[Hutchy68]

is there a way to have plain clickable items, with no dropdowns, defined in MediaWiki:Sidebar or elsewhere?

Unfortunately - no.

The navbar is defined by MediaWiki:Sidebar and the headings on any wiki are not clickable in the sidebar on any skin. *edit-At least that I am aware of :) * Vector uses a js rewrite trick (fragile and sometimes CSS quirky) to hide the first top-level heading of the sidebar. Think that's with a display:none, which in Foreground will eliminate the top-level heading, but everything under it.

[quimgil]

Fair enough. I have modified my MediaWiki:Sidebar instead.

[adrelanos]

The navbar is defined by MediaWiki:Sidebar and the headings on any wiki are not clickable in the sidebar on any skin. *edit-At least that I am aware of :)

Mediawiki skin strapping can have clickable sidebar links.

• https://www.mediawiki.org/wiki/Skin:Strapping
• https://github.com/OSAS/strapping-mediawiki

Example wiki? We are using strapping currently but moving to foreground soon. Therefore I am sharing a link with you from archive.org where you can see it:
https://web.archive.org/web/20180430153424/https://www.whonix.org/wiki/Documentation

Does that give any hint on how to implement this feature?

[gagarine]

Can we reopen this issue?

This is how they do it https://github.com/OSAS/strapping-mediawiki/blob/master/Strapping.skin.php#L425

They use a custom render function for navigation.

[Hutchy68]

Some of the bootstraps use a little trick with a single blank heading and then span out all the links under it. The proper thing to do is to go after the developers or submit your own patch to MW core to fix the issue or improve href=“#” headings.

[gagarine]

I don't think we should make the header clickable. I think we should render the menu without the header, it's what do the bootstrap theme. We can create an option $sideBarDropdown for that.

Then in the template we can render all menus in flat. I think it will fix most use case.

I'm talking about this piece of code:

	<ul id="top-bar-left" class="left">
	<li class="divider show-for-small"></li>
		<?php foreach ( $this->getSidebar() as $boxName => $box ) { if ( ($box['header'] != wfMessage( 'toolbox' )->
text())  ) { ?>
	<li class="has-dropdown active"  id='<?php echo Sanitizer::escapeId( $box['id'] ) ?>'<?php echo Linker::tooltip(
 $box['id'] ) ?>>
		<a href="#"><?php echo htmlspecialchars( $box['header'] ); ?></a>
			<?php if ( is_array( $box['content'] ) ) { ?>
				<ul class="dropdown">
					<?php foreach ( $box['content'] as $key => $item ) { echo $this->makeListItem( $key, $item ); } 
?>
				</ul>
					<?php } } ?>
			<?php } ?>
</ul>

[gagarine]

In fact, because skin extend BaseTemplate it's possible to do whatever needed.

class FooBarTemplate extends BaseTemplate {

I think this skin have very good UX idea, but perhaps it's easier to start it from scratch on bootstrap 4.

[Hutchy68]

The skin is based on foundation 5 and if anything the next iteration will be based on foundation 6.

[Hutchy68]

As per https://phabricator.whonix.org/T809 a client with no js will be able to click the top link of a dropdown and the dropdown will appear. However, the links in the dropdown are not clickable.

Suggestions of rendering all links in the top as bootstrap does with their custom override of links held in one MediaWiki:Sidebar column.

* Naviagtion
** Link 1 ....
** Link 2 ....
** Link 3 ....
** etc.....

The above might solve main navigation and limit the number of items in top bar for navigation. What it doesn't address is the dropdown of the toolbox (gear icon) and user (user icon). Those are still broken and hobble the website when the user doesn't have JS turned on. This is a know limitation of Zurb Foundation Framework because of the navbar js and css construction.

TL;DR

So what is causing this? JS not only allows the hover over to drop the dropdown, as far as I can tell it brings the dropdown element into "focus" which then allows the <a> elements in the dropdown to become clickable.

So how to fix it?

• Total rewrite and do not use the navbar classes and js, but this would break mobile
• Hidden secondary totally CSS dependent drop menu (I've already accomplished this for the menu actions button)
• Other suggestions welcome as there is no CSS able to bring a classed or id'd item into focus like a textbox/textarea could be.

[adrelanos]

Could you re-open please?

[JasonJAyalaP]

Foundation 5 provided a css fix for the menu bar dropdown menus being broken without javascript, but it wasn't being applied because it was under the class ".no-js" and mediawiki uses ".client-nojs". Simply renaming seemed to be enough to make it mediawiki aware, and the drop items are now clickable without js.

Note: This isn't a solution to the "show all items request"

Additionally, however, both the menu css and the fix are under the > 40em media query. At < 40em the menus are combined under a single dropdown which doesnt even display it's list items when js is disabled. Looking into it.

[JasonJAyalaP]

I expanded the main menu dropdown with this code:

#p-Menu > a {
    display: none;
}
#p-Menu > ul.dropdown {
    display: contents;
}
#p-Menu > ul.dropdown > li {
    width: auto; 
}

inside the "full menu" screen query
@media only screen and (min-width: 40.0625em) {

You can have the expanded menu inside the collapsed mobile "MENU" if you put the code outside of the screen query, but more is needed to get rid of the unnecessary BACK and MENU text:

#p-Menu > .dropdown li.title.back.js-generated {
   display: none;
}
#p-Menu > .dropdown li.parent-link.hide-for-medium-up
{
  display: none !important;
}

Works for us (whonix) but no guarantees about other sites with more than one menu (we only got one).

[rebastion]

You can just hack direct links into the menu with Mediawiki:Sidebar, and then those are clickable of course, even though not "internal" links per se. Did this with social media icons e.g. at spaghetti-western.net

[Hutchy68]

@rebastion I get that, but no-js kills the action menu too. Unless they are a just browser of a site, the ability to do anything is shut down completely without JS turned on. EDITED

I would be open to adding an extra stylesheet aimed at no-js, example - client-nojs.css to load and handle a client without js turned on.

Here is the first patch of code for it.

@media only screen and (min-width: 40.0625em) {
  .client-nojs .top-bar-section ul li:hover > a {
    background-color: #555555;
    background: #222222;
    color: #FFFFFF; }
  .client-nojs .top-bar-section ul li:active > a {
    background: #008CBA;
    color: #FFFFFF; }
  .client-nojs .top-bar-section .has-dropdown:hover > .dropdown {
    position: static !important;
    height: auto;
    width: auto;
    overflow: visible;
    clip: auto;
    display: block;
    position: absolute !important; }
  .client-nojs .top-bar-section .has-dropdown > a:focus + .dropdown {
    position: static !important;
    height: auto;
    width: auto;
    overflow: visible;
    clip: auto;
    display: block;
    position: absolute !important; }
  .client-nojs .tabs-content > .content {
    display: block;
    float: none; } 
}

Just saying, I know Foundation v5 isn't being developed any longer. Just wondering if anyone forked it and has continued the development of it to handle no-js better.