classification
Title: Simple CSS fix for left margin at docs.python.org
Type: behavior Stage: needs patch
Components: Documentation Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: cdunn2001, docs@python, eric.araujo, ezio.melotti, fdrake, georg.brandl
Priority: normal Keywords: easy

Created on 2011-01-18 19:12 by cdunn2001, last changed 2012-10-26 18:12 by ezio.melotti.

Messages (13)
msg126477 - (view) Author: Christopher Dunn (cdunn2001) Date: 2011-01-18 19:11
This is an easy one.

When I zoom my browser in (with Ctrl+ or Apple+) the left-side navigation margin gets bigger and bigger, pushing the useful text off the screen. That has bothered me (and anyone else with 40+ year old eyes) ever since the switch to the newest doc format with Sphinx.

There is no fix that will satisfy everyone. People with perfect vision might like to zoom out (with Ctrl- or Apple-), since the margin currently gets smaller and smaller. But we need a compromise.

The relevant CSS, in default.css, is this:

 div.bodywrapper {
    margin: 0 0 0 230px;
 }

If instead it were something like this:

 div.bodywrapper {
    margin: 0 0 0 10%;
 }

then at least the navigation margin would stay the same size always.

If you really want it to grow and shrink, then you need some sort of javascript control of its position.
msg126685 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-01-21 02:57
If the width is specified with a percentage, a min-width should be specified too.
In the py3k doc the sidebar can be collapsed though, so I'm not sure it's worth changing this. Georg?
msg126690 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2011-01-21 04:03
As Ezio noted, the coming versions of the Python 3 documentation
provide a way to collapse the sidebar completely.  Perhaps a min-width
should be specified, but I'm not convinced that's a good idea.

The sidebar problem is fairly significant, and the collapsing sidebar
alone isn't sufficient.  The sidebar is useful since it's the only
overall navigation structure (as opposed to the direct links embedded
in the content), but there's no real need to ensure it gets "enough"
width.  I'd rather see a simple adjustment as recommended by
Christopher Dunn.

I appreciate Ezio's in making the sidebar collapsible, but I think
that's just the first step.  The sidebar is certainly the most
contentious element of the new design, and the most difficult to get
right.
msg126691 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-01-21 04:18
The min-width is necessary in case the CSS is changed to resize the sidebar dynamically. If it gets too narrow it would start getting unusable and the text will start overflowing.

Possible alternatives are:
1) use a percentage and min-width;
2) like 1) but also collapse the sidebar automatically when its width gets smaller than the min-width;
3) leave a fixed width but make the sidebar mouse-resizable (that will conflict with the collapsibility though and is less trivial to do);
msg126692 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2011-01-21 04:45
On Thu, Jan 20, 2011 at 11:18 PM, Ezio Melotti <report@bugs.python.org> wrote:
> If it gets too narrow it would start getting unusable and the text will start overflowing.

If someone is zooming that much, it's because they really need the
size of the text more than anything (trust me; I've tried to work
while my eyes were dilated; size is *everything* at that point).  The
worst thing to do in such situations is to get in the way of the
browser's normal behavior.
msg126693 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-01-21 05:11
I did some tests using 20% instead of 230px and found the following problems:
1) while zooming, even if the width of the sidebar doesn't change, the font size does, overflowing from the sidebar;
2) min-width can't be used because the width of the sidebar is given by the margin-left of the bodywrapper, and there's no min-margin-left property that can be used instead;

The font size can probably be changed to fit the width of the sidebar, but the min-width problem remains (I'm thinking about small screens -- e.g. smartphones -- where the sidebar would end up having a width of ~130-160px (I haven't (yet) tested it there though)).
msg126703 - (view) Author: Christopher Dunn (cdunn2001) Date: 2011-01-21 07:53
I see what @ezio means about the apparent overflow when the bodywrapper left margin is at 20%. (It's not really overflow, since the sidebar is actually the width of the screen.) How about this change to basic.css?

 44 div.sphinxsidebar {
 45     float: left;
 46     width: 20%; /* was 230px */
 47     margin-left: -100%;
 48     font-size: 90%;
 49 }

It looks pretty good to me. The only thing that overflows is the search-input box. CSS for that is set in both basic.css and default.css (which takes precedence) as:

104 div.sphinxsidebar input {
105     border: 1px solid #98dbcc;
106     font-family: sans-serif;
107     font-size: 1em;
108     max-width: 100%;
109 }

I added line 108 (max-width). And now everything looks decent when zoomed in.
msg126704 - (view) Author: Christopher Dunn (cdunn2001) Date: 2011-01-21 07:58
For narrow-width screens, there really shouldn't be a sidebar. Maybe a dynamic element would be better. Could it unhide and overlap the main body with a click or mouse-over? Then the main body could take the full screen width. Just an idea.
msg126738 - (view) Author: Fred L. Drake, Jr. (fdrake) (Python committer) Date: 2011-01-21 13:41
On Fri, Jan 21, 2011 at 2:58 AM, Christopher Dunn
<report@bugs.python.org> wrote:
> For narrow-width screens, there really shouldn't be a sidebar. Maybe a dynamic element would be better.

Right.  I'd be in favor of removing the sidebar and having a pop-out
ToC navigator of some sort.  Most of the time, most of us are looking
at the content, not at how to navigate the content.  Spending so much
screen real-estate on navigation is painful.  Large, hi-res screens
just aren't *that* cheap yet.
msg126769 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-01-21 18:52
Also, laptops and handheld devices have a limited screen size.

-1 on a pop-up, for obvious usability reasons.
msg126770 - (view) Author: Christopher Dunn (cdunn2001) Date: 2011-01-21 18:57
@eric.araujo:

Not a 'pop-up', that you would have to click to close. But something dynamic, based on mouse location.
msg126774 - (view) Author: Christopher Dunn (cdunn2001) Date: 2011-01-21 19:15
I was just trying to help fix the CSS, and I think I've done that.

If we're reconsidering the behavior of the nav sidebar, then I'd like to point out that if you're far down the page, the sidebar is blank to your right. From a usability point of view, it's already broken. It was a neat idea, but a ToC for the page would serve the purpose better.

My monitor is quite large, and rotated 90 degrees, so it's narrow and tall. A web-page can be infinitely long, but its practical width is limited to the user's screen, which is different for every user. That's why HTML was designed the way it is, with auto-word-wrap.

When you have a bunch of stuff that you want to fit within a window, a sidebar makes more sense. For Python docs, I'd vote to drop it altogether, as attractive-looking as it is.

But if you really want it, give it its own vertical scrollbar, so that a relevant portion is always visible. Then people can talk about dynamic controls.

That's just my opinion. I created this bug because, when I zoon, the sidebar consumes most of my screen with no visible text. It's such a huge problem that I was afraid someone had already submitted this.
msg130632 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-03-11 22:26
There's #4965 for that. Last time I tried there was some problem with it, maybe I'll try again in future.
History
Date User Action Args
2012-10-26 18:12:33ezio.melottisetversions: + Python 3.4, - Python 3.1
2011-03-11 22:26:49ezio.melottisetnosy: fdrake, georg.brandl, ezio.melotti, eric.araujo, cdunn2001, docs@python
messages: + msg130632
2011-01-21 19:15:21cdunn2001setnosy: fdrake, georg.brandl, ezio.melotti, eric.araujo, cdunn2001, docs@python
messages: + msg126774
2011-01-21 18:57:41cdunn2001setnosy: fdrake, georg.brandl, ezio.melotti, eric.araujo, cdunn2001, docs@python
messages: + msg126770
2011-01-21 18:52:24eric.araujosetnosy: + eric.araujo
messages: + msg126769
2011-01-21 13:41:56fdrakesetnosy: fdrake, georg.brandl, ezio.melotti, cdunn2001, docs@python
messages: + msg126738
2011-01-21 07:58:35cdunn2001setnosy: fdrake, georg.brandl, ezio.melotti, cdunn2001, docs@python
messages: + msg126704
2011-01-21 07:53:17cdunn2001setnosy: fdrake, georg.brandl, ezio.melotti, cdunn2001, docs@python
messages: + msg126703
2011-01-21 05:11:19ezio.melottisetnosy: fdrake, georg.brandl, ezio.melotti, cdunn2001, docs@python
messages: + msg126693
2011-01-21 04:45:37fdrakesetnosy: fdrake, georg.brandl, ezio.melotti, cdunn2001, docs@python
messages: + msg126692
2011-01-21 04:18:32ezio.melottisetnosy: fdrake, georg.brandl, ezio.melotti, cdunn2001, docs@python
messages: + msg126691
2011-01-21 04:03:36fdrakesetnosy: + fdrake
messages: + msg126690
2011-01-21 02:57:57ezio.melottisetkeywords: + easy
messages: + msg126685
nosy: georg.brandl, ezio.melotti, cdunn2001, docs@python
stage: needs patch
2011-01-18 19:41:48brian.curtinsetnosy: + ezio.melotti, georg.brandl
2011-01-18 19:12:00cdunn2001create