|
|
After looking at the CSS I have figured out that this has nothing
to to with pixel sizing. Instead the problem is caused by some positioning done with em's.
The "personal toolbar" -- that one with the "log in" or "log out"
link (div class="personalBar") -- is in the HTML actually on top
of the navigation breadcrumbs (div class="pathBar").
This means the "personal toolbar" normally would have been displayed above of the navgation breadcrums (which is the case for an uncustomized plone site, it seems).
Now instead of moving the personal toolbar down in the
HTML-template the move down is done via some CSS positioning;
the toolbar is moved down 6.6em from the top of its parent position (seemingly the <body>).
this declaration moves it down below the breadcrumbs. As the
positioning is absolute the toolbar is out of the normal flow
and would normally overlay the contents, hiding the
"View","Folloup" links, etc.
To prevent this, the table containing the content
has some top margin. However the margin is only 1.4em.
This looks fine for "normal" font sizes.
However if one changes the overall font size the toolbar moves much more down than the top margin of the content table makes
space for it.
One possibility to avoid this is to move down the personal
toolbar in the HTML and then forget about the CSS positioning.
I have checked that this would help,
except it leaves an ugly looking gap
between the vertial border separating the toolbar stuff
from the content area and the grey border between
the left navigation and the content.
This is some odd problem due to the left navigation and
content being inside of a table while the horizontal border
below them is not. I have not been able to fix that.
If one does not want to touch the HTML at all (I guess this
happened intentionally, maybe hoping that plone upgrades would
run more soothly if one does not touch the HTML=templates?),
one could instead try to swap the personal toolbar
and the breadcrumbs by relative positioning; i.e.
move the one 1.7ems down and the other 1.7em up.
(1.7em seems to be just right for me, figured out by
trial and error)
Now one does not have to add some top margin to the content table,
because both bars mutually reserve layout space for each other.
I tried to do this in the attached patch. To avoid breaking
the assumption that each bars are 1.7em height I had to prevent
linebreaks for the personal toolbar, too. (I guess thats ok,
if its ok for the breadcrumb anyway).
Additionally I has to give the content a negative margin to
make the grey borders touch each other. (1.4em - 1.7em = -0.3em)
The width of 100% has ben prooven harmful for relative
positioning; the toolbar edged around on the right, causing to
have the right padding outside of the browser window ...
I did not define any explicit height
for the bars to avoid patching around of IE5.5 nonstandard's
treatment of height and paddings.
Now I am definitely not the "design guru" called for in some
earlier followup. Only tested with Mozilla1.6/Linux,
Opera 7.53/Linux and IE6.0/Win2000 (but have been too dump
to find the text zoom there ... :-/ )
Only tested with a local copy of the page for this issue.
No idea it it breaks on other pages.
Please check carefully if the patch is useful.
Simply swapping the divs in the HTML seems to be more
natural fix to me, anyway.
Oh, and what I did not treat at all
is the problem of the search form getting shadowed by
toolbars as the text size grows.
File details
File type
application/octet-stream
|
Log in
Forgot your password?
