[Gimp-web] Re: rendering problems

[Raphaël Quinet]

On Sun, 7 Sep 2003 01:03:14 +0200, "Branko Collin" <collin@xs4all.nl> wrote:
> On 6 Sep 2003, at 14:13, Branko Collin <collin@xs4all.nl> wrote:
> [...] 
> > Actually, I now see that the entire page renders badly in Opera 
> > Win/5, though not as bad as the Mac IE 5s (5.1 for OS 9, 5.2 for OS
> > X). Where on the Macs, the content area gets shifted to the right,
> > outside the viewport, in Opera it gets shoved under the menu.

Hmmm...  This is strange.  If Opera behaves like that, this could mean
that it reports zero when the script asks for the current width of the
menu in order to position the content area ("main" div).  I could try
to test for that in the script.

> (Since it takes ages for my e-mail to get to list, I am cc'ing this 
> to you directly, Raphael.)

The mailing list seems to work a bit better now.  Let's hope that it lasts.

> Here are some suggestions that at least work for Opera 5/Win:
> 
> - add to wgo.css:
> #menu
> 	{
> 	width: 8.75em; 
> 	border-width: 0px 1px 1px 0px;
> 	}
> #main
> 	{
> 	margin-left: 10.7em;
> 	}
> 
> - change in wgo.js:menu-adjust():
>     if (menu_el.offsetWidth) {
>       main_el.style.marginLeft = 
>           (menu_el.offsetWidth + padding) + "px";
>     }
> 
> to: 
> 
>     if (menu_el.offsetWidth) {
>       main_el.style.marginLeft = "10.7em";
>     }

Well, that's a problem.  I explicitely used pixels instead of ems for
the default width (which is changed by the script anyway) because some
CSS compatibility chart told me that I should avoid ems as a unit
because it was causing problems in some browsers (I don't remember
which ones, though).  So I decided to use pixels everywhere in order
to be as portable as possible.

> This also solves the problem that if you change font-size in a Gecko 
> browser, the menu will at some point be rendered over the main 
> content. (In Phoenix at least I can solve this by reloading the page, 
> but that will probably not be obvious to the average user.)
> 
> Disadvantages of setting the width of #menu are that these values may 
> need to be changed if the menu item texts get changed, and that users 
> with funky fonts may get a weird rendering.
> 
> Demo at <http://www.abeleto.nl/staging/wgo.html>.

I could work with that...  Until some people tell me that their
browser gives weird results when "em"s are used as the unit.  ;-)
Anyway, I think that I will change the width to 11em (rounding up) and
see if it works better.

> - Drc wondered why we don't float the menu to the left, instead of 
> positioning it, and frankly I don't have an answer to that question.

Same reason as above: float was broken in some browsers.  But I think
that it was only Netscape 4, in which case we shouldn't worry about
that because I have disabled the use of style sheets in NS4.

But even if we use float instead of absolute, I don't think that it
will solve the other problems that we observed with the height and
continuity of the menu.  So it looks like I still have to improve the
script.  Or maybe switch back to tables, but then it will be more
difficult to toggle the menu on and off like we can do now.  After
playing with it a bit I found this very useful, especially when
viewing tutorials or printing them (if the browser ignores the media =
"print" statement in the style sheet).

I will try to commit some changes this evening.  Please test this
tomorrow and tell me if it works, especially in less common browsers.

-Raphaël