[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