Simple CSS fix for left margin at docs.python.org

[cdunn2001]

BPO	10936
Nosy	@freddrake, @birkenfeld, @ezio-melotti, @merwok, @DeVil2O

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2011-01-18.19:12:00.071>
labels = ['easy', 'type-bug', '3.8', '3.9', '3.10', 'docs']
title = 'Simple CSS fix for left margin at docs.python.org'
updated_at = <Date 2020-10-30.23:24:34.345>
user = 'https://bugs.python.org/cdunn2001'

bugs.python.org fields:

activity = <Date 2020-10-30.23:24:34.345>
actor = 'iritkatriel'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2011-01-18.19:12:00.071>
creator = 'cdunn2001'
dependencies = []
files = []
hgrepos = []
issue_num = 10936
keywords = ['easy']
message_count = 14.0
messages = ['126477', '126685', '126690', '126691', '126692', '126693', '126703', '126704', '126738', '126769', '126770', '126774', '130632', '344103']
nosy_count = 7.0
nosy_names = ['fdrake', 'georg.brandl', 'ezio.melotti', 'eric.araujo', 'cdunn2001', 'docs@python', 'codevil_2o']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue10936'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[cdunn2001]

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.

[ezio-melotti]

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?

[freddrake]

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.

[ezio-melotti]

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);

[freddrake]

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.

[ezio-melotti]

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)).

[cdunn2001]

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.

[cdunn2001]

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.

[freddrake]

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.

[merwok]

Also, laptops and handheld devices have a limited screen size.

-1 on a pop-up, for obvious usability reasons.

[cdunn2001]

@eric.araujo:

Not a 'pop-up', that you would have to click to close. But something dynamic, based on mouse location.