Tim Jackson

Email conversation

From	Tim Jackson
To	Me
Subject	Suggestion
Date	2 November 2003 00:47

Hi,

Just looking at your HowToCreate pages whilst I grapple with a tough
layout problem (as usual, I had a page doing exactly what I wanted about
5-6 hours ago, and now I'm in the middle of deconstructing/reconstructing
it purely because of the stupidity of one particular unnamed browser)

On:

http://www.howtocreate.co.uk/ie6pita.html

I have a couple of points:

a) I think you should provide a link to the definitive MSDN page
explaining in detail what changes are made in IE6:

http://msdn.microsoft.com/workshop/author/css/overview/cssenhancements.asp

as this is an invaluable resource for anyone trying to work with the
beast. Note also that your advice about doctype switching is correct as
far as it goes but only partial; the above URL has a precise table of
which situations switch it into which modes.


b) I think your advice to avoid switching into standards-compliant mode is
questionable: if people do layouts with s-c mode off, then it perpetuates
the broken MS box model and gets people used to "width = content + padding
+ border" instead of "width = content".


c) I'm no JS expert, and you know a lot more about it than I do, but are
you sure the JS change is not a positive change to make IE respect the DOM
better? (possibly caused by them fixing the canvas to be
standards-compliant?) If so, again, this seems to be a reason *to* switch
(more consistent, standards-compliant behaviour across browsers) rather
than avoiding switching...


The frameset bug is a bastard though, as you rightly point out. I really
must do that CSS hack on xxxxxxxxxxxxxxx.xxx sometime.


Cheers,


Tim

From	Tim Jackson
To	Me
Subject	ideas?
Date	2 November 2003 01:22

Tark, have you ever come across this?

I'm aware of (I think) all the common CSS bugs in IE6, but I can't even
get it to do some really basic absolute positioning correctly. Check this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
<style type="text/css">

body {
 padding: 0;
 margin: 0;
}

div#navbar {
 position: absolute;
 top: 0px;
 left: 0px;
 margin: 20px 20px 20px 20px; /* yes, could be compressed */
 background-color: red;
 border: 1px solid green;
 padding: 0;
}

</style>
</head>

<body>
 <div id="navbar">
 ... Lots of latin text used just to fill out the space ...
 </div>

</body>
</html>


What you'd expect is a div that expands to fill the screen, with a 20px
margin all round. Indeed, that's what Gecko/Op/KHTML produce. IE (5.5/6
tested; the DOCTYPE doesn't make a difference) produces a div which is
expandable as expected but which protrudes a fixed amount beyond the right
hand edge of the screen. How weird! It's kind of like a variation on the
"whoops, I forgot the scrollbar in frameset" bug except there are no
frames, and experimentation shows that subtracting 35 pixels approximately
fixes the bug, using the same fix as for the broken frameset bug:

[in the body style]
voice-family: "\"}\""; voice-family: inherit; width:
expression(document.documentElement.clientWidth - 35);

Am I missing something obvious here? Doing something stupid (quite
possible; I've spent the whole evening arsing around with CSS)? Is this
widely known? If so, what is it usually classified as and what is the
usual fix/workaround?

By the way, came across your mention of me on your site. Very kind of you,
thanks!

Tim

From	Me
To	Tim Jackson
Subject	Re: ideas?
Date	2 November 2003 09:32

> IE produces a div which is expandable as expected but which protrudes a
> fixed amount beyond the right hand edge of the screen.

I'm afraid this is IE being stupid. As the element is absolutely 
positioned, it determins the default width assuming there are no 
margins. Then it adds on the margins afterwards. All other browsers do
these the opposite way around, so getting the correct effect.

The width expression you used will do the trick, but you may also find
that you can use relative positioning, because it works correctly with
that (dunno how your page will be constructed however, so that may be
impossible).

> a) I think you should provide a link to the definitive MSDN page

will do. cheers

> b) I think your advice to avoid switching into standards-compliant mode
> is questionable ...

this is true, but as IE screws it up, we may have to just play along for
now ...

> are you sure the JS change is not a positive change to make IE respect
> the DOM better?

That may be their excuse, but as none of the js is in any standard,
changing their minds willy nilly serves only to confuse.

From	Tim Jackson
To	Me
Subject	Re: ideas?
Date	2 November 2003 12:29
Attachments	image of what Opera 7 produces and image of what Gecko produces

> I'm afraid this is IE being stupid ...

FFS, that is a basic calculation, and IE gets even that wrong in
"standards" mode? That is screwed up. Sigh.

Maybe you should put something about it on HowToCreate?

> You may also find that you can use relative positioning, because it
> works correctly with that

Unfortunately not. Well, not fulfilling exactly what I was trying to
achieve. I was trying to do a 3-column (2 fixed, centre expanding) layout
like this: http://xxxxxxxxx.xxx/xxx/xxxxxxx/xxxxxxx.xxxx except that I
also want a navigation bar at the top of the centre column. Now, achieving
this visually is not a problem, but what I was also trying to do was keep
the code order clean - so I wanted the nav to be *below* the centre div in
the HTML, but *above* it in the visual layout - hence why I was trying to
absolutely position it.

Only vaguely related to that (but I came across it whilst playing around
last night), how about this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
<style type="text/css">

body {
 padding: 0;
 margin: 0;
 border: 1px solid blue;

}

div#wrap {
 width: 50%;
 border: 1px solid black;
}

div#navbar {
 position: absolute;
 top: 0px;
 left: 0px;
 margin: 20px 20px 20px 20px;
 background-color: red;
 border: 1px solid green;
 padding: 0;
}


</style>
</head>

<body>
 <div id="wrap">
  [blah blah]

  <div id="navbar">
   [blah blah]
  </div>	

 </div>

</body>
</html>

Opera interprets this how I would expect (see attached). Gecko and KHTML
don't. (I'll ignore IE because that's clearly screwed). (KTHML and Gecko
are the same except KHTML has a ~20px border between the right of the red
navbar div and the edge of the window, Gecko has ~40px).

Which is right?


Tim

From	Tim Jackson
To	Me
Subject	Re: grrrrrrrrrrrrrrrrrrrrrr
Date	2 November 2003 23:00

Yo,

OK, here's what I've been working on:

http://xxxx.xxxxxxxxxx.xxx/

Comments/criticism welcome. Through a minor hack I managed to achieve what
I was trying to do last night (expandable layout, broad compatibility AND
logical code order: I gave up trying to control the width of the navbar in
IE and instead just plonked a relatively-positioned empty box at the top,
with absolutely positioned navbar (with no background) floating over it.
It even has the devedge drop-down menus working in Gecko/IE/Opera.

However, is it just my VMware installation (I fear not) or am I seeing
some horrendous bug in both IE5 and 6 which means the heading "tabs"
(which are background-images on <h1>s) randomly appear and disappear, as
you refresh the page multiple times or even just scroll up and down it? I
think it's something to do with relative positioning and IE is randomly
(sometimes) clipping stuff which is outside its parent content box.

Any idea of a fix? I've got a hacky workaround here which involves a huge
background image, but it's ugly...if I'm forced to do that I'll have to do
some browser sniffing/dynamic CSS generation so that only IE gets the
"uglified" CSS/big background image.

[ED. I removed some stuff here because it did not relate to the problem
(just complained about the way that Microsoft wrote a browser with lots of
rendering bugs, then practically forced it on the world using their very
effective marketing techniques)]


Tim

From	Me
To	Tim Jackson
Subject	Re: ideas?
Date	3 November 2003 08:57

> Opera interprets this how I would expect
> Which is right?

In this case, I think Opera is wrong.

Positioned elements take their width from the parent container, not the
parent element. As there is no parent positioned element, the body becomes
the parent container, so the width or margins should be relative to the
body. If you want to force the Opera response in all browsers (IE also?...),
set the container div to position relative.

By the way, I get no difference in rendering between Gecko (Moz 1.5) and
KHTML (Konq 3.0, Safari 1.0, Safari 1.1)

As for your three col layout, is there some reason why you can't use:
<div style="float:left;width:200px;">left menu</div>
<div style="float:right;width:200px;">right menu</div>
<div>main content</div>

It does mean that the left and right menus appear first in the HTML.

or how about positioning all three absolutely, then setting the left and
right positions of the middle one to make its width variable

<div style="position:absolute;left:200px;right:200px;top:10px;">

> the heading "tabs" randomly appear and disappear
 
I have heard of this bug before. usually it relates to floats and clears.
However, IE does not like things being displayed outside their container.
Not sure what to do to fix it, but it is usually something like adding a
blank element with clear:both;

If you need to do sniffing, you may want to use a conditional comment:
<!--[if IE]><style>@import url(iestuff.css)</style><![endif]-->

It may not be very good, but at least it validates, and it works with
script disabled.

From	Tim Jackson
To	Me
Subject	Re: ideas?
Date	3 November 2003 09:28

> In this case, I think Opera is wrong.

That's quite a big bug then! That's a major layout difference...

> Positioned elements take their width from the parent container, not the
> parent element.

Ah yes, I'm mixing up containers and elements.

> As for your three col layout, is there some reason why you can't use:
> <div style="float:left;width:200px;">left menu</div>
> <div style="float:right;width:200px;">right menu</div>
> <div>main content</div>

Well, the bad code order is one reason; beyond that I dunno, I haven't
tried that, but the bluerobot one seems to be a widely used (and
compatible) way of doing it, with the benefit of good code order. Also, if
you make your overall structure out of floated elements, isn't that
restricting how you can use floats within it?

There are so many ways to skin a cat in CSS!  (A good thing though, since
it seems that usually out of a load of possibilities, only 1 way actually
works across a reasonable number of browsers...)

> or how about positioning all three absolutely, then setting the left and
> right positions of the middle one to make its width variable 
> <div style="position:absolute;left:200px;right:200px;top:10px;">

Good idea, and I would have done this since it's simple, but the main
problem is that IE seems to ignore the 'right' parameter if the content is
small (the box will shrink-wrap the content rather than taking on the
specified geometry). Which is a PITA. Unless you know a way round this?
Also, the [external site] way allows the centre div to slide over the others on
very narrow screens (e.g. handheld). Although you could probably just
supply a different handheld stylesheet. (dunno if IE for WinCE recognises
them though).

> If you need to do sniffing, you may want to use a conditional comment:
> <!--[if IE]><style>@import url(iestuff.css)</style><![endif]-->

Good idea, thanks for reminding me of that (I saw it somewhere the other
day but forgot about it). Although ISTR someone at the time saying it
wouldn't validate against XHTML 1.0? Is that right? (I'm aiming for
something that will XHTML 1.0 validate)

> It may not be very good, but at least it validates, and it works with
> script disabled.

I was going to do it server-side, actually... (using phpsniff). But if the
"comment trick" will validate, that's simpler and probably more reliable.

Tim

From	Me
To	Tim Jackson
Subject	Re: ideas?
Date	3 November 2003 09:38

I quote:
This Page Is Valid XHTML 1.0 Strict!

You just have to be careful what you put inside the comments. What I showed
you is perfectly valid.

afraid I don't know a way around the shrink wrap. I assume putting a block
element inside it doesn't help?

how about using conditional comments with
width: expression(document.body.clientWidth-sidePanelWidths);
very bad practice, but it should work

maybe hiding a long paragraph inside it ;-)

From	Tim Jackson
To	Me
Subject	Re: grrrrrrrrrrrrrrrrrrrrrr
Date	15 November 2003 13:50

> [IE conditional comments]
> I quote:
> This Page Is Valid XHTML 1.0 Strict!

Funky. Thanks. 

However, a little note; you suggested this:

> <!--[if IE]><style>@import url(iestuff.css)</style><![end if]-->

but for some (unknown) reason, the @import doesn't seem to work. This
does:

<!--[if IE]><style>foo { bar; }</style><![endif]-->

and so does this:

<!--[if IE]><link rel='stylesheet' href="i_am_a_s**t_browser.css"
type="text/css" /><![endif]-->

but not the @import. Strange.

Hmm, this conditional comment thing strikes me as one of the few
*sensible* things MS have done...a reliable, non-JS way of authoritatively
detecting IE, which doesn't break any standards. Handy. I think you should
write about it on howtocreate.co.uk (which, once again, I must say that
the more I explore it, the more impressed I am with the depth and quality
of info there! Awesome!)

From	Me
To	Tim Jackson
Subject	Re: grrrrrrrrrrrrrrrrrrrrrr
Date	16 November 2003 10:06

> @import doesn't work

replace [end if] with [endif] and it will work

Tim Jackson

Navigation

Search

Site navigation

Email conversation