Please help with this IE problem

[Alan Silver]

Hello,

Please look at http://www.kidsinaction.org.uk/ie/ie.html in IE6 and
notice that there is a white vertical line on the right of the white
bit. This is caused (AFAICS) by IE not putting the "bottomr" element
right up against the right edge of the containing element, allowing the
white background to show through.

It works fine in FF and IE7. Both the XHTML and CSS validate fine. I
have this problem twice on the page I'm building, but I cut it down to a
simple case that shows the problem to make it easier to debug.

I think this might be the famous IE 3-pixel bug, but I'm not sure as I
thought that only applied to floating elements next to text. In my case,
I have an absolutely positioned element inside a div, without any floats
or text in sight. Also, the solutions for the IE 3-pixel bug all seem to
involve adding a width or height to the element, but all three elements
in this test case already have both a width and a height.

Anyone able to help me sort this out? Thanks

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

Anyone have any idea on this? I'm pretty sure it's not the 3-pixel jog,
mainly as the gap has now been seen to be one pixel, not three.

Any help would be greatly appreciated. TIA

In article <+g**************@nospamthankyou.spam>, Alan Silver
<al*********@nospam.thanx.invalidwrites

>Hello,

Please look at http://www.kidsinaction.org.uk/ie/ie.html in IE6 and
notice that there is a white vertical line on the right of the white
bit. This is caused (AFAICS) by IE not putting the "bottomr" element
right up against the right edge of the containing element, allowing the
white background to show through.

It works fine in FF and IE7. Both the XHTML and CSS validate fine. I
have this problem twice on the page I'm building, but I cut it down to
a simple case that shows the problem to make it easier to debug.

I think this might be the famous IE 3-pixel bug, but I'm not sure as I
thought that only applied to floating elements next to text. In my
case, I have an absolutely positioned element inside a div, without any
floats or text in sight. Also, the solutions for the IE 3-pixel bug all
seem to involve adding a width or height to the element, but all three
elements in this test case already have both a width and a height.

Anyone able to help me sort this out? Thanks

--
Alan Silver
(anything added below this line is nothing to do with me)

[rf]

"Alan Silver" <al*********@nospam.thanx.invalidwrote in message
news:CP**************@nospamthankyou.spam...

Anyone have any idea on this? I'm pretty sure it's not the 3-pixel jog,
mainly as the gap has now been seen to be one pixel, not three.

Unmaximize your browser window. Pick up an edge and very slowly move it left
and right. You will notice that the artifact appears and disappears,
depending on the width of the browser canvas, probably the users font size
and if the dog is barking as well.

It's due to the fact that you are trying to position things with pixel
precision and also using percentages for width. A percentage of what? The
browser canvas, and what if that percentage is not an integer? IE does not
like this sort of stuff. It'll round up, or down, or whatever and sometimes
it will leave an artifact there.

From what I can see you are starting a page that would be better drawn with
some paint program and destined to paper, and not the web. Rethink the
design. You already have WAY too much CSS, trying to control things with way
too much precision.

Hint: If you really know what you are doing and if you really understand all
the implications then you then may use position: absolute. not before.

--
Richard.

[Jonathan N. Little]

Alan Silver wrote:

Hello,

Please look at http://www.kidsinaction.org.uk/ie/ie.html in IE6 and
notice that there is a white vertical line on the right of the white
bit. This is caused (AFAICS) by IE not putting the "bottomr" element
right up against the right edge of the containing element, allowing the
white background to show through.

It works fine in FF and IE7. Both the XHTML and CSS validate fine. I
have this problem twice on the page I'm building, but I cut it down to a
simple case that shows the problem to make it easier to debug.

I think this might be the famous IE 3-pixel bug, but I'm not sure as I
thought that only applied to floating elements next to text. In my case,
I have an absolutely positioned element inside a div, without any floats
or text in sight. Also, the solutions for the IE 3-pixel bug all seem to
involve adding a width or height to the element, but all three elements
in this test case already have both a width and a height.

Do no see your problem. But a bit of advice, unless your have a *real*
compelling reason to use XHTML use HTML 4.01 strict. You will have less
frustration with MSIE6...

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Alan Silver]

In article <38*************************@NAXS.COM>, Jonathan N. Little
<lw*****@centralva.netwrites

>Do no see your problem. But a bit of advice, unless your have a *real*
compelling reason to use XHTML use HTML 4.01 strict. You will have less
frustration with MSIE6...

Unfortunately, XHTML is a project requirement, not my choice. I meant to
mention that in my original post, as I knew someone would raise it!

Thanks anyway

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

In article <qS******************@news-server.bigpond.net.au>, rf
<[e-mail]

>
"Alan Silver" <al*********@nospam.thanx.invalidwrote in message
news:CP**************@nospamthankyou.spam...

>Anyone have any idea on this? I'm pretty sure it's not the 3-pixel jog,
mainly as the gap has now been seen to be one pixel, not three.

Unmaximize your browser window. Pick up an edge and very slowly move it left
and right. You will notice that the artifact appears and disappears,
depending on the width of the browser canvas, probably the users font size
and if the dog is barking as well.

Well, it's actually there about 99% of the time. Just occasionally it
disappears, although the dog wasn't barking, so that might have affected
it.

>It's due to the fact that you are trying to position things with pixel
precision and also using percentages for width.

What pixel precision? I'm trying to get the bottoml and bottomr divs to
sit right up against the left and right margins of their containers.
That's hardly trying to position with pixel precision. I've done this
many times before, and seen plenty of other example of it too.

A percentage of what?

What percentage? The only percentage in that whole bottom set of divs is
the 100% width for the container div. All of the CSS on the html and
body tags could have been removed. I should actually have taken it out
for this example, but forgot.

So I'm left with one single percentage, which is 100%. What's the
problem with that?

>The
browser canvas, and what if that percentage is not an integer? IE does not
like this sort of stuff. It'll round up, or down, or whatever and sometimes
it will leave an artifact there.

Well, this would be fine if I were trying to position with percentages,
but I'm not. The bottomr div, which is the one causing the problem is
positioned absolutely, and has a top and right property of zero. Even
with IE's buggy rendering, I don't see why that would cause rounding
errors. Zero is zero. Sure, if I was specifying a percentage of
something, then rounding could occur, but there's nothing to round.

>From what I can see you are starting a page that would be better drawn with
some paint program and destined to paper, and not the web. Rethink the
design. You already have WAY too much CSS, trying to control things with way
too much precision.

I have been designing web sites for about 12 years. I produce 100% valid
and compliant sites that adhere to web standards. I know how to design
web pages. What I am doing here hardly falls into the dee-ziner category
that you describe.

As I pointed out, you can ignore the CSS for the html and body tags
(which I've now removed from the sample page). What you are left with
are three fairly simple CSS declarations. How is that "way" too much
CSS, and how am I trying to control things with "way" too much
precision?

>Hint: If you really know what you are doing and if you really understand all
the implications then you then may use position: absolute. not before.

Yes I do know what I'm doing. I have been using absolute positioning for
years and never had a problem with it before.

I understand your point of view. I have seen plenty people trying to do
pixel-perfect design, without understanding the nature of the web. You
were not to know that this does is not my situation. However, your
criticism does not seem justified. A quick look at the CSS would show
that I'm not doing a lot of what you suppose.

Anyway, I have found a hack that fixes the problem, but I would still
like to know why it is happening as I don't like using hacks. If you
have any suggestions about the actual problem, as opposed to telling me
that I am doing it the wrong way, I would be glad to hear them.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Andy Dingley]

On 23 Jul, 15:50, Alan Silver <[e-mail]>
wrote:

Unfortunately, XHTML is a project requirement,

People who make such arbitrary and clueless rules don't get to have
websites that work,
or sites that can be developed at reasonable cost (i.e. not inflated
solely by pandering to IE).

My sympathies on having to work around that (BTDT, had the 50% over-
run just to cope with IE5/Mac), but the fix is to drop the faked-up
XHTML, not to argue the indefensible. Good luck on the managerial
education project!

[Alan Silver]

In article <11**********************@w3g2000hsg.googlegroups. com>, Andy
Dingley <di*****@codesmiths.comwrites

>On 23 Jul, 15:50, Alan Silver <[e-mail]>
wrote:

>Unfortunately, XHTML is a project requirement,

People who make such arbitrary and clueless rules don't get to have
websites that work,
or sites that can be developed at reasonable cost (i.e. not inflated
solely by pandering to IE).

Don't know. I don't have such strong feelings on the subject. I know
it's a bit of a religious topic round here, but I can't really see the
big deal about XHTML. You have to remember to close all tags, but apart
from that there's little difference.

I've never had any problems with it before, even with IE. I've always
managed to produce clean designs without hacks, and had them work fine
in IE. I guess that's why I don't get worked up about XHTML, never been
much of an issue. I've read some of the articles about how evil it is,
but IMO, there are more important things to worry about!

>My sympathies on having to work around that (BTDT, had the 50% over-
run just to cope with IE5/Mac), but the fix is to drop the faked-up
XHTML, not to argue the indefensible. Good luck on the managerial
education project!

Not going to bother even trying to argue against the XHTML. The project
is going to be an ASP.NET site, and if you want valid code, you need to
use XHTML. AFAIK, the only options are valid XHTML or invalid HTML ;-(

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

[Andy Dingley]

On 23 Jul, 17:26, Alan Silver <[e-mail]>
wrote:

Unfortunately, XHTML is a project requirement,

I can't really see the big deal about XHTML.

There is no big deal. That's why, if it's causing problems for you you
can dump it. The idea of it as an mandatory "project requirement" is
what I have the issue with.

For another thing, you're not using XHTML anyway, just Appendix C at
most.

Not going to bother even trying to argue against the XHTML. The project
is going to be an ASP.NET site, and if you want valid code, you need to
use XHTML. AFAIK, the only options are valid XHTML or invalid HTML ;-(

I'm assured by ASP.NET developer that it's not that bad: M$oft merely
make it ridiculously obscure for how to achieve valid HTML, not
completely impossible. 8-)

There's a similar issue with JSF Facelets. Although the source _into_
them must be XML (it must be XHTML + Facelets, with namespacing),
their _output_ can perfectly well be HTML.

[Alan Silver]

In article <11**********************@n60g2000hse.googlegroups .com>, Andy
Dingley <di*****@codesmiths.comwrites

>On 23 Jul, 17:26, Alan Silver <[e-mail]>
wrote:

>Unfortunately, XHTML is a project requirement,

>I can't really see the big deal about XHTML.

There is no big deal. That's why, if it's causing problems for you you
can dump it. The idea of it as an mandatory "project requirement" is
what I have the issue with.

It isn't causing me any problems. Someone else said I shouldn't be using
XHTML without a compelling reason. AFAICS, XHTML is just HTML with a few
extra slashes to close tags. Apart from a few extra bytes in my output,
I can't see any problem with it at all.

>For another thing, you're not using XHTML anyway, just Appendix C at
most.

Again, does it matter? Not trying to be awkward, but aren't there more
important things to worry about?

>Not going to bother even trying to argue against the XHTML. The project
is going to be an ASP.NET site, and if you want valid code, you need to
use XHTML. AFAIK, the only options are valid XHTML or invalid HTML ;-(

I'm assured by ASP.NET developer that it's not that bad: M$oft merely
make it ridiculously obscure for how to achieve valid HTML, not
completely impossible. 8-)

I've never found a way. I would be grateful if you could ask him how he
did it. Not that it bothers me. As I said, XHTML is fine by me, at least
until someone comes up with a compelling reason *not* to use it.

>There's a similar issue with JSF Facelets. Although the source _into_
them must be XML (it must be XHTML + Facelets, with namespacing),
their _output_ can perfectly well be HTML.

Don't know, never used them. The ASP.NET framework emits a lot of the
code itself, and you don't seem to have much control over the level of
what comes out. They support XHTML strict and transitional, as well as
something called "legacy," which AFAICS is invalid HTML4. Given the
choice between those three, it didn't take long to go for XHTML strict!

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)