Last modified: 2014-06-01 13:51:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14501 - A way to hide the sidebar providing a "fullscreen" view
A way to hide the sidebar providing a "fullscreen" view
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: design
Depends on:
Blocks: javascript css
  Show dependency treegraph
 
Reported: 2008-06-10 18:23 UTC by Andrew Dunbar
Modified: 2014-06-01 13:51 UTC (History)
19 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Waste of space (158.24 KB, image/png)
2011-12-14 15:50 UTC, Helder
Details

Description Andrew Dunbar 2008-06-10 18:23:32 UTC
On small displays such as the very popular Eee PC there are quite a few Wikipedia articles that don't quite fit the width of the screen even with the browser in fullscreen mode.

Other sites such as Google Reader allow the user to fold or collapse the sidebar so as to provide maximum width for formatting the important content.

This ought to be easy via Javascript manipulating the CSS widths of the column-one and column-content for instance on the Monobook skin.

Support without Javascript would be possible but at the PHP level and might me too much trouble to bother implementing.
Comment 1 Brion Vibber 2008-06-10 19:18:31 UTC
You can select an alternate skin in your preferences, though this isn't necessarily ideal.
Comment 2 AlexSm 2008-06-10 21:04:34 UTC
I think this should be a userscript/gadget, like [[User:js/bottomSidebar]] (mine) or [[User talk:Gerbrant/hidePane.js]]
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-11 21:53:21 UTC
Turning off CSS will do this.  Also see bug 7020, which is related.  Maybe we should use media queries!
Comment 4 Siebrand Mazeland 2008-08-13 21:24:44 UTC
Jhs has created a JavaScript Gadget that will move the sidebar to the top of the page with drop down menus. He will probably be able to elaborate/refer. Adding Jhs to cc list.
Comment 5 Niklas Laxström 2008-10-06 08:31:10 UTC
This probably doesn't need to be in the core, a job for the gadgets. Reopen if you disagree.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-10-06 16:36:31 UTC
I do disagree, which is why I didn't WONTFIX this bug when I commented before, and presumably neither Brion or Siebrand particularly agreed either, by the same logic.  This is not a job for JS, it's a job for CSS, and if possible it should be automatically supported in the core software (using, e.g., media queries).  Subnotebooks look to be becoming more popular, and it would be nice if we could support their lower resolutions cleanly and without extra configuration.
Comment 7 Krinkle 2011-04-06 22:24:50 UTC
A gadget exists on Commons:

http://commons.wikimedia.org/?withJS=MediaWiki:IPadSidbarSlider.js

Orignally written to be automatically loaded for all users that match the iPad user agent. but can be used as a normal gadget as well.
Comment 8 Helder 2011-12-14 15:50:41 UTC
Created attachment 9694 [details]
Waste of space

Currently if a reader starts to read a long article, he will soon get to the point where there is nothing in the sidebar (because the useful links are in the beggining of the page, and there is no other languages to show), so for the remaining 80% (or more) of the page, there will be a lot of wasted space on the left. It could be useful to provide by default some way to get the full width of the screen used for displaying the article content, or alternativelly, to bring the sidebar links down while scrolling the page.

See screenshot and some random long page from
http://en.wikipedia.org/wiki/Special:LongPages
Comment 9 richa jain 2013-03-08 10:21:30 UTC
found a fix for this https://gerrit.wikimedia.org/r/#/c/52781/
Comment 10 Quim Gil 2013-04-02 18:13:37 UTC
(In reply to comment #8)
> Waste of space

Not at all. The wider the lines the more difficult is to read them. This is a basic usability principle. Just check any decent website with long pages out there.
Comment 11 Bartosz Dziewoński 2013-04-02 18:16:42 UTC
(See also bug 44387.)
Comment 12 Technical 13 2013-04-03 12:19:20 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > Waste of space
> 
> Not at all. The wider the lines the more difficult is to read them. This is a
> basic usability principle. Just check any decent website with long pages out
> there.

I disagree with your assessment Quim, I have three screens on my desktop and one of them is portrait oriented in order to read long pages.  I also have friends that complain about the sidebar when reading wikipedia on their tablet or cell phone.

I have other thoughts about the sidebar as well.  Not only should the user be able to position it at any of the four poles or hide it all together.  It should be offered to have it set to an absolute position so that scrolling the page up and down doesn't make it scroll off the page.  Just my thoughts.
Comment 13 Daniel Friesen 2013-04-03 21:19:25 UTC
Quim Gil's comment is in fact correct. Very wide paragraphs of text are in fact hard to read. The reader is forced to move their head more and it becomes difficult to find the start of the next line. Likewise when a paragraph of text is too narrow the reader is forced to break to the next line too often breaking the flow of their reading. There is an optimum range for the width of a paragraph of text.

And white space is not a waste. White space between things de-clutters pages giving things room to breathe and separating unrelated stuff.

The white area below the sidebar is not the problem. The problem is that these small and portrait screens don't have the space to fit both the optimal paragraph width and the width of a sidebar.


At the same time our current navigation isn't very well suited to alternate forms of display.
Comment 14 Gerrit Notification Bot 2013-04-11 11:33:32 UTC
https://gerrit.wikimedia.org/r/52781 (Gerrit Change Ie5dbcdc6efe15ea9ad6708c98ac5979deb7e29c5) | change ABANDONED [by Rjain]
Comment 15 Technical 13 2013-04-11 11:49:44 UTC
(In reply to comment #13)
> Quim Gil's comment is in fact correct. Very wide paragraphs of text are in
> fact hard to read. The reader is forced to move their head more and it becomes
> difficult to find the start of the next line. Likewise when a paragraph of
> text is too narrow the reader is forced to break to the next line too often
> breaking the flow of their reading. There is an optimum range for the width of a
> paragraph of text.

That wasn't being debated (at least not by me).

> And white space is not a waste. White space between things de-clutters pages
> giving things room to breathe and separating unrelated stuff.

That is true, yet again only on wide-screens.

> The white area below the sidebar is not the problem. The problem is that
> these small and portrait screens don't have the space to fit both the optimal
> paragraph width and the width of a sidebar.

Not sure what your point is with the first sentence of this comment.  My comment regarding fixing the sidebar location (I incorrectly used the word absolute) was so that when you are at the bottom of a very long page, you still have easy access to all of the links that it offers without having to scroll ALL the way back to the top (and no, keyboard shortcuts don't exist on my mobile phone).  For that matter, perhaps the top section shouldn't scroll either to have easy access to the edit link or other links, although...

> At the same time our current navigation isn't very well suited to alternate
> forms of display.

Would it be possible to add media selectors to the CSS or some kind of HxW (probably JavaScript) detection to the pages that can detect the orientation and size of the window pages are being displayed in and format them appropriately?
Comment 16 Waldir 2013-04-11 16:04:06 UTC
(In reply to comment #15)
> My comment regarding fixing the sidebar location was so that when you are
> at the bottom of a very long page, you still have easy access
> to all of the links that it offers without having to scroll
> ALL the way back to the top (and no, keyboard shortcuts don't exist on my
> mobile phone).  For that matter, perhaps the top section shouldn't scroll
> either to have easy access to the edit link or other links

You might find this interesting to try: http://meta.wikimedia.org/wiki/User:Waldir/vector.css/fixednav.css
Comment 17 Waldir 2013-04-11 16:05:32 UTC
(In reply to comment #16)
> You might find this interesting to try:
> http://meta.wikimedia.org/wiki/User:Waldir/vector.css/fixednav.css

To give it a try, place this in your vector.css:

/* Fixed navigation (keep top tabs and sidebar always in place, only scroll the content */
@import url("https://meta.wikimedia.org/w/index.php?title=User:Waldir/vector.css/fixednav.css&action=raw&ctype=text/css");
Comment 18 Nemo 2014-05-17 08:10:32 UTC
In case you've not clicked the link above: this was done in Translate (for Special:Translate only), bug 45836. You can see it on [[m:Special:Translate]].
Comment 19 Nemo 2014-06-01 13:51:34 UTC
There is also https://it.wikipedia.org/wiki/MediaWiki:Gadget-AutohidePanel.css , 2012, Vector-only, 48 users on it.wiki.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links