Information
ID: 809
PHID: PHID-TASK-l2cvcxxncfgqxtek7jjb
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal
Description
mediawiki foreground skin: make items in navigation clickable without drop-down and without javascript
Upstream ticket.
opened 10:59AM - 07 Sep 14 UTC
question
enhancement
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.
https://forums.whonix.org/uploads/default/original/2X/5/5e5684a89715910c5fcba42b628fd0449a53020c.png
Forum discussion:
The list you are referring to ( upper left hand corner https://whonix.org/wiki/Documentation# ) does not work when scripts are disabled globally with NoScript. If an exception is made it will work.
There is too much white space on the left and the right side of any wiki page.
Some of our boxes or something breaks mobile view.
Example page:
Configure (Private) (Obfuscated) Tor Bridges - There you can scroll to the right even if it shouldn’t be possible to scroll to the right.
css fixes required
reduce space between lines a bit
increase space between chapters a bit
Example:
Whonix Track Record against Real Cyber Attacks
a) mediawiki original (examples: Whonix - Wikipedia / Unix-like - Wikipedia )
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.
mediawiki markup fix required
pretty up table / add border between cells
Examples:
CodeSelect needs fixes:
Template:CodeSelect - Whonix
Note: these have to look ok with and without javascript enabled.
Bullet point font sizes within footnotes are too big (bigger than normal footnote size), should be smaller.
Example on page Anonymity Operating System Comparison - Whonix vs Tails vs Tor Browser Bundle look for
Open Source software does not automatically prevent
~~After a bullet point, there is too little white space before the next non-bullet point text. ~~
There is more space before the bullet point text than after the bullet point text which is bad style. Should not be needed to use two new lines after a bullet point list.
Example:
Frequently Asked Questions - Whonix FAQ
fix wiki Expand All / Collapse All already SOLVED
Fix Widget:Expand or Collapse All - Whonix
Broken since we switched from mediawiki strapping to mediawiki foreground skin.
To be used on Whonix Documentation
(It worked previously:)
web.archive.org/web/20180430153424/www.whonix.org/wiki/Documentation
Experiment here:
www.whonix.org/wiki/Dev/Documentation
See browser developer console to see javascript error.
Any other CSS recommendations for a well readable pretty wiki page?
Likely related:
Comments
Hutchy68
2018-09-28 13:16:05 UTC
Most of the items have been solved. Exceptions:
mediawiki foreground skin: make items in navigation clickable without drop-down and without javascript
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.
Patrick
2018-09-29 09:58:45 UTC
! 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):
CodeSelect example “Too big when there is just one line.”
Foreground requires JS to function. Not sure how to solve the navigation issue. No JS - no navigation.
Could you submit Clickable items in navigation without drop-down · Issue #182 · jthingelstad/foreground · GitHub 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:
Configure (Private) (Obfuscated) Tor 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.
Patrick
2018-09-30 07:31:19 UTC
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
}}
Hutchy68
2018-09-30 18:53:41 UTC
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:
Configure (Private) (Obfuscated) Tor 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.
Patrick
2018-10-01 06:54:35 UTC
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:
Configure (Private) (Obfuscated) Tor 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?
Hutchy68
2018-10-01 14:51:54 UTC
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:
Template:CodeSelect - Whonix
Too big when there is just one line.
Too small when there are two lines, example: Template:Deactivate Misc Proxy Settings - Whonix
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
, 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?
Hutchy68
2018-10-01 21:04:28 UTC
Patrick
2018-10-02 10:01:05 UTC
Hutchy68
2018-10-02 13:39:06 UTC
New code select looks nice. However it does not work yet when javascript is disabled.
Oops, fixed now.
a) mediawiki original (examples: Whonix - Wikipedia / Unix-like - Wikipedia )
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.
Hutchy68
2018-10-02 14:04:26 UTC
Patrick
2018-10-03 12:57:23 UTC
Hutchy68
2018-10-03 22:50:11 UTC
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.
Hutchy68
2018-10-04 03:18:56 UTC
Patrick
2018-10-04 07:15:06 UTC
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.
Hutchy68
2018-11-05 13:19:49 UTC
Patrick
2019-03-05 13:01:59 UTC
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?
Patrick
2019-11-08 14:56:47 UTC