[Gimp-web] Re: rendering problems

Branko Collin collin at xs4all.nl
Fri Sep 12 20:58:15 2003


On 8 Sep 2003, at 19:52, Raphaël Quinet wrote:

[menu block too wide]
> 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.

IIRC, according to Eric Meyer's CSS compatibility chart, ems cause 
huge troubles in IE 3.x for Windows, where they are interpreted as 
pixels. Incidentally, I nicked the idea of using ems from Eric 
Meyer's stylesheets for http://devedge.netscape.com, so either I am 
misremembering that it was his compatibility chart, or he does not 
care anymore about IE 3, or he has found a work-around.

I feel width needs to be set. I don't understand why the design works 
in some browsers without setting the width for the menu div. My 
understanding of the specs is that if you don't set the width of a 
DIV, it should stretch to the width of it's containing block. In our 
case, the containing block is (as wide as) the BODY element.

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

Have you implemented this change? My demo works (somewhat--the height 
of the menu box is still a problem) in IE 5.1 for Mac OS Classic, but 
not so mmmaybe.gimp.org.

-- 
branko collin
collin@xs4all.nl