Most of the items have been solved. Exceptions:

1. mediawiki foreground skin: make items in navigation clickable without drop-down and without javascript
2. CodeSelect needs fixes:

CodeSelect has a hard set row="1" in the widget powering it. I cannot find any examples of multiple lines used except as the demo on the template page.

Foreground requires JS to function. Not sure how to solve the navigation issue. No JS - no navigation.

https://www.whonix.org/wiki/Whonix:Sandbox is a Documentation page change suggested. Works with mobile well, using the tricks MediaWiki uses for columns in <ref> tags stacking and unstacking columns.

In T809#17271, @Hutchy68 wrote:

CodeSelect has a hard set row="1" in the widget powering it. I cannot find any examples of multiple lines used except as the demo on the template page.

CodeSelect multiple line examples (there is a tiny unnecessary scroll bar):

• https://www.whonix.org/wiki/Template:VirtualBox_Spectre_Meltdown

CodeSelect example "Too big when there is just one line."

• https://www.whonix.org/wiki/Template:Open_with_root_rights

Foreground requires JS to function. Not sure how to solve the navigation issue. No JS - no navigation.

Could you submit https://github.com/thingles/foreground/issues/182#issuecomment-409635256 to mediawiki upstream if that helps?

https://www.whonix.org/wiki/Whonix:Sandbox is a Documentation page change suggested. Works with mobile well, using the tricks MediaWiki uses for columns in <ref> tags stacking and unstacking columns.

Much better indeed!

Not fixed:

• There is too much white space on the left and the right side of any wiki page. (I always have to zoom in to 130% - 150% to use all the space of the screen.) (That is in a maximized desktop browser window.)
• Some of our boxes or something breaks mobile view. - Example page:

https://www.whonix.org/wiki/Bridges - There you can scroll to the right even if it shouldn't be possible to scroll to the right.

• css fixes required (in original post)

Perhaps more, perhaps a client caching issue? But I was using Tor Browser which shouldn't be caching things.

For CodeSelect multi line test:

{{CodeSelect|code=
VBoxManage modifyvm "Whonix-Gateway" --ibpb-on-vm-entry on
VBoxManage modifyvm "Whonix-Workstation" --ibpb-on-vm-entry on
VBoxManage modifyvm "Whonix-Gateway" --ibpb-on-vm-exit on
VBoxManage modifyvm "Whonix-Workstation" --ibpb-on-vm-exit on
VBoxManage modifyvm "Whonix-Gateway" --l1d-flush-on-vm-entry on
VBoxManage modifyvm "Whonix-Workstation" --l1d-flush-on-vm-entry on
VBoxManage modifyvm "Whonix-Gateway" --l1d-flush-on-sched on
VBoxManage modifyvm "Whonix-Workstation" --l1d-flush-on-sched on
VBoxManage modifyvm "Whonix-Gateway" --spec-ctrl on
VBoxManage modifyvm "Whonix-Workstation" --spec-ctrl on
VBoxManage modifyvm "Whonix-Gateway" --nestedpaging off
VBoxManage modifyvm "Whonix-Workstation" --nestedpaging off
}}

Not fixed:

There is too much white space on the left and the right side of any wiki page. (I always have to zoom in to 130% - 150% to use all the space of the screen.) (That is in a maximized desktop browser window.)

Sorry, I was misunderstanding your request. I set the max-width to 100%. Most website use a container with a max-width hard set to a number of pixels which is what Foreground does out of the box. You might find the 100% great on lots of pages, maybe not so on others. That would be your call. Anyway, the 100% is now set.

Some of our boxes or something breaks mobile view. - Example page:
https://www.whonix.org/wiki/Bridges - There you can scroll to the right even if it shouldn't be possible to scroll to the right.

This really has nothing to do with the skin. The issue is the use of width=800px or whatever you are setting as a width. Basically, this tells the browser to hard set a width of 800px no matter what the viewport size is which will break mobile if the size is greater than the viewport width. I fixed the template calling your example page.

If you need a max-width on a page because of formatting, use max-width:###px. It is better to just leave off the width call IMHO.

Hutchy68 (Tom Hutchison):

Hutchy68 added a comment.

> Not fixed:
> 
> There is too much white space on the left and the right side of any wiki page. (I always have to zoom in to 130% - 150% to use all the space of the screen.) (That is in a maximized desktop browser window.)

Sorry, I was misunderstanding your request. I set the `max-width` to 100%. Most website use a container with a max-width hard set to a number of pixels which is what Foreground does out of the box. You might find the 100% great on lots of pages, maybe not so on others. That would be your call. Anyway, the 100% is now set.

Great!

> Some of our boxes or something breaks mobile view. - Example page:
>  https://www.whonix.org/wiki/Bridges - There you can scroll to the right even if it shouldn't be possible to scroll to the right.

This really has nothing to do with the skin.

Some of our mediawiki css issues indeed aren't directly related to the skin.

The issue is the use of width=800px or whatever you are setting as a width. Basically, this tells the browser to hard set a width of 800px no matter what the viewport size is which will break mobile if the size is greater than the viewport width. I fixed the template calling your example page.

I see. No idea what's doing that. Could you try please to figure out
what's doing this?

I see. No idea what's doing that. Could you try please to figure out

what's doing this?

The use of style="width:800px'" being hard set in wiki markup on pages. Seems to mainly focus around pages using mw-expand and mw-collaspse. No idea how many there are. I didn't check but if you have replaceText extension installed you could search for the code and replace with style="width:100%;". Of course it would miss containers that have other style settings hard set. Maybe width:800px; to width:100%; might work. This is why it is a bad to use style and not classes.

CodeSelect needs fixes:

https://www.whonix.org/wiki/Template:CodeSelect

Too big when there is just one line.
Too small when there are two lines, example: https://www.whonix.org/wiki/Template:Deactivate_Misc_Proxy_Settings
Also, if fixable, the [select code] text should never cover other text if there is a lot text input.
Note: these have to look ok with and without javascript enabled.

This has a lot going on. First, you are hiding a <pre>, then selecting from a textarea, z-indexing a div and the select link, then the link is traversing the dom tree to select text in the textarea while resizing the textarea with a JS call on the classes..... see where I am going? There is a lot going on for a textarea view with a select all code to make it easier to copy it.

Backing up, I added https://www.whonix.org/wiki/Whonix:Sandbox/Code_select as a demo on something a little easier to do. Hover over the text area, left click to select or right click to select and copy. Done. Check it out. I know the [select text] link is gone, but hover over the textarea box will add some styling which will clue there is something active to do. I set it so the mouse pointer will change to a "grab hand" which is another clue. Click anywhere in the box and the text is all selected. Click again and you can click to select just text you want, which is probably not the use.

Mobile, will focus, but not select and I can not see a need to select all and copy to paste somewhere. Who is using their mobile device to copy and paste code to execute or change config files?

Just a note, I change the mouseover pointer to cursor: text; just as the current textareas.

Awesome!

• style="width:800px'" fixed using https://www.whonix.org/wiki/Special:ReplaceText (long time user, awesome extension) Pages such as the https://www.whonix.org/wiki/Bridges no longer needlessly let mobile users to scroll empty content on the right which is good.
• New code select looks nice. However it does not work yet when javascript is disabled.

I will keep striking through all items which are done in the original ticket.

New code select looks nice. However it does not work yet when javascript is disabled.

Oops, fixed now.

a) mediawiki original (examples: https://en.wikipedia.org/wiki/Whonix / https://en.wikipedia.org/wiki/Unix-like)

The underline below a chapter is good.
Right amount of space between chapter title and text.
Right amount of space between chapters.
b) Whonix wiki:

Too much space after title headline.
There is too much space between lines of text.
mediawiki original space between title headline and text and space between lines of text is better. We want Whonix similar to mediawiki in regards to space between lines

I made some adjustments which are live right now. Do you want font-size of h1, h2, etc tags reduced to be more inline with mediawiki? Most of my earlier changes were based on what web-archive whonix looked like with the previous skin. Just need more direction, examples and I will try to match.

I went ahead and toned down font-size on h tags a bit. Looks better although <h3> might need to drop a touch more, 1.5 instead of 1.6.

Awesome! All done except: mediawiki foreground skin: make items in navigation clickable without drop-down and without javascript

mediawiki foreground skin: make items in navigation clickable without drop-down and without javascript

@Patrick

I think you are referring to the Actions button. The top bar works with a click, but Foundation 5 has no fallback for clients without JS turned on. So.... I rolled one myself with a pure CSS fallback. Check it out. Actions button now falls back to "on hover" with a dropdown menu below the Actions button. Tested and seems to work ok for a user without JS enabled.

Darn, I see the top nav does click to drop but no links are usable in the drops.

No, not action buttons. But it's cool that this works now. Didn't know that's possible.

Yes, I mean the MENU drop down menu.

• Worst: links aren't even clickable without javascript.
• Very bad: we don't even want a drop-down menu for HOME, DOWNLOAD, DOCS, HELP, NEWS. These items should just be clickable, always visible items at the very top.

Tracker updated at https://github.com/jthingelstad/foreground/issues/182

Will need to think about the most sensible method to fix this and it will probably break mobile views without JS so it should be noted to users of mobile devices with JS turned off.

Hi Tom!

Can we remove the Menu drop down menu? I don't like drop down menus much anyhow.

And instead, can we have some - clickable - without javascript - (even hardcoded) links up there HOME DOWNLOAD DOCS HELP NEWS in the top bar?

Even if the "Menu" cannot be removed: can we have some - clickable - without javascript - (even hardcoded) links up there HOME DOWNLOAD DOCS HELP NEWS in the top bar?