XHTML bug? Transitional/Strict Rendering Issues

Hi,

After smashing my head against the table a few times, I finally was
able to fix a bug that was causing my site to render incorrectly in all
browsers.

An hour ago, I had just finished my conversion from HTML to XHTML/CSS
Transitional, the site was validating perfectly. So, as it was doing
this, I thought I'd try it out as XHTML Strict. So I changed the
doctype in the file and then validated it. Validated fine as XHTML
Strict. However! Then I noticed it was rendering differently. These
weird line spaces were appearing in weird places. They hadn't been. So
I assumed I'd editting something accidently in the CSS file. Checked
the CSS file, nothing weird in there.

Hit my head against the table for the first time.

What had I changed recently? The doctype! From Transitional to Strict.

So I changed it back from Strict to Transitional.

Hit my head against the table for the second time.

The site was rendering correcltly! What the heck?!

Transitional: http://www.commanderbond.net/xhtml/
Strict: http://www.commanderbond.net/xhtml_s/

The only difference between these two versions are the doctypes.
Nothing else is different.

What the hell is going on?

Really appreciate any help of advice.

Cheers,

Dave Winter.

Dave Winter

Just to be clear on what exacly doesn't work for me:

There is a space beneath the top most header graphic.
There is also a space above the left and right columns. Above the
images ("General" and "Search CBn")

I've made the backgrounds bright red so it's clear to see the issue.

Dave.

On 2004-04-26 11:03:45 +0100, Dave Winter <> said:

> Hi,
>
> After smashing my head against the table a few times, I finally was
> able to fix a bug that was causing my site to render incorrectly in all
> browsers.
>
> An hour ago, I had just finished my conversion from HTML to XHTML/CSS
> Transitional, the site was validating perfectly. So, as it was doing
> this, I thought I'd try it out as XHTML Strict. So I changed the
> doctype in the file and then validated it. Validated fine as XHTML
> Strict. However! Then I noticed it was rendering differently. These
> weird line spaces were appearing in weird places. They hadn't been. So
> I assumed I'd editting something accidently in the CSS file. Checked
> the CSS file, nothing weird in there.
>
> Hit my head against the table for the first time.
>
> What had I changed recently? The doctype! From Transitional to Strict.
>
> So I changed it back from Strict to Transitional.
>
> Hit my head against the table for the second time.
>
> The site was rendering correcltly! What the heck?!
>
> Transitional: http://www.commanderbond.net/xhtml/
> Strict: http://www.commanderbond.net/xhtml_s/
>
> The only difference between these two versions are the doctypes.
> Nothing else is different.
>
> What the hell is going on?
>
> Really appreciate any help of advice.
>
> Cheers,
>
> Dave Winter.

"Dave Winter" <> wrote in message
news:2004042611034516807%davewinter@maccom...
> Hi,
>
> After smashing my head against the table a few times, I finally was
> able to fix a bug that was causing my site to render incorrectly in all
> browsers.
>
> An hour ago, I had just finished my conversion from HTML to XHTML/CSS
> Transitional, the site was validating perfectly. So, as it was doing
> this, I thought I'd try it out as XHTML Strict. So I changed the
> doctype in the file and then validated it. Validated fine as XHTML
> Strict. However! Then I noticed it was rendering differently. These
> weird line spaces were appearing in weird places. They hadn't been. So
> I assumed I'd editting something accidently in the CSS file. Checked
> the CSS file, nothing weird in there.
>
> Hit my head against the table for the first time.
>
> What had I changed recently? The doctype! From Transitional to Strict.
>
> So I changed it back from Strict to Transitional.
>
> Hit my head against the table for the second time.
>
> The site was rendering correcltly! What the heck?!
>
> Transitional: http://www.commanderbond.net/xhtml/
> Strict: http://www.commanderbond.net/xhtml_s/
>
> The only difference between these two versions are the doctypes.
> Nothing else is different.
>
> What the hell is going on?
>
> Really appreciate any help of advice.
>
> Cheers,
>
> Dave Winter.

Both versions looked identical to me in IE6. Which is ironic, considering
IE6 *does* have some serious XML/XHTML rendering bugs (they are fairly
random, but are affected completely by the doctype). Generally IE renders
XHTML *better* if you set the doctype to HTML4 Transitional. Which is just
plain weird. Of course if you do that, it fails validation and screws up
some other browsers.

I miss the old days where everyone hated Netscape and IE was the best
browser! Now everyone is still using IE and it's by far the *worst* browser.
Arrrg. And Mozilla is rather nice

You're right, it does seem to render ok in IE6.

However, Firefox, Safari, Camino - none of these do. They render the
site differently based on the doctype.

Could this be a bug with all of these? Or, IE 6? Or some other sort of bug?

Dave.

On 2004-04-26 11:12:31 +0100, "SpaceGirl" <> said:

>
> "Dave Winter" <> wrote in message
> news:2004042611034516807%davewinter@maccom...
>> Hi,
>>
>> After smashing my head against the table a few times, I finally was
>> able to fix a bug that was causing my site to render incorrectly in all
>> browsers.
>>
>> An hour ago, I had just finished my conversion from HTML to XHTML/CSS
>> Transitional, the site was validating perfectly. So, as it was doing
>> this, I thought I'd try it out as XHTML Strict. So I changed the
>> doctype in the file and then validated it. Validated fine as XHTML
>> Strict. However! Then I noticed it was rendering differently. These
>> weird line spaces were appearing in weird places. They hadn't been. So
>> I assumed I'd editting something accidently in the CSS file. Checked
>> the CSS file, nothing weird in there.
>>
>> Hit my head against the table for the first time.
>>
>> What had I changed recently? The doctype! From Transitional to Strict.
>>
>> So I changed it back from Strict to Transitional.
>>
>> Hit my head against the table for the second time.
>>
>> The site was rendering correcltly! What the heck?!
>>
>> Transitional: http://www.commanderbond.net/xhtml/
>> Strict: http://www.commanderbond.net/xhtml_s/
>>
>> The only difference between these two versions are the doctypes.
>> Nothing else is different.
>>
>> What the hell is going on?
>>
>> Really appreciate any help of advice.
>>
>> Cheers,
>>
>> Dave Winter.
>
> Both versions looked identical to me in IE6. Which is ironic, considering
> IE6 *does* have some serious XML/XHTML rendering bugs (they are fairly
> random, but are affected completely by the doctype). Generally IE renders
> XHTML *better* if you set the doctype to HTML4 Transitional. Which is just
> plain weird. Of course if you do that, it fails validation and screws up
> some other browsers.
>
> I miss the old days where everyone hated Netscape and IE was the best
> browser! Now everyone is still using IE and it's by far the *worst* browser.
> Arrrg. And Mozilla is rather nice

Dave Winter <> wrote:

>Transitional: http://www.commanderbond.net/xhtml/
>Strict: http://www.commanderbond.net/xhtml_s/
>
>The only difference between these two versions are the doctypes.
>Nothing else is different.
>
>What the hell is going on?

Doctype sniffing.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> triggers
Standards mode in Mozilla.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> triggers
Standards mode in Opera and IE, but triggers "Almost Standards" mode
in Mozilla.

The difference is slight (nothing like the differences between
Standards and Quirks) and is most evident in the way images are
treated if they are the sole content of an element.

You have
<div id="header"><img src="resources/images/headers/48/logo.jpg"
/></div>
(which is naughty as the alt attribute is mandatory).

If you had
<div>abcd<img>efgh</div>
you would expect a space below the image, as by default the bottom of
the image sits on the baseline of the text and there must be room
below the baseline for the descender of the 'g'. To be totally
standards compliant there must be room below the baseline even when
there are no characters with descenders used.

But traditionally browsers have fudged this and so in 'Almost
Standards' mode (and obviously Quirks mode as well) Mozilla fudges it
as well.

#header img {display: block;}
#leftmenu img {display: block;}
#rightmenu img {display: block;}
will fix your problem. By turning the images from inline to block
elements they no longer need to be treated as text characters.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <> <http://steve.pugh.net/>

In article <2004042611172250073%davewinter@maccom>,
says...
> You're right, it does seem to render ok in IE6.
> However, Firefox, Safari, Camino - none of these do. They render the
> site differently based on the doctype.
> Could this be a bug with all of these? Or, IE 6? Or some other sort of bug?

Yes to all. The problem is that no browser supports 100% of CSS, so if
you are planning on a CSS design you have to either use only code that
works identically in all browsers (which pretty much eliminates nested
divs with borders and padding), or just accept that it will not look the
same.

--
Whitecrest Entertainment
www.whitecrestent.com

On 2004-04-26 11:49:30 +0100, Steve Pugh <> said:

> Dave Winter <> wrote:
>
>> Transitional: http://www.commanderbond.net/xhtml/
>> Strict: http://www.commanderbond.net/xhtml_s/
>>
>> The only difference between these two versions are the doctypes.
>> Nothing else is different.
>>
>> What the hell is going on?
>
> Doctype sniffing.
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> triggers
> Standards mode in Mozilla.
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> triggers
> Standards mode in Opera and IE, but triggers "Almost Standards" mode
> in Mozilla.
> The difference is slight (nothing like the differences between
> Standards and Quirks) and is most evident in the way images are
> treated if they are the sole content of an element.
>
> You have <div id="header"><img src="resources/images/headers/48/logo.jpg"
> /></div>
> (which is naughty as the alt attribute is mandatory).
>
> If you had
> <div>abcd<img>efgh</div>
> you would expect a space below the image, as by default the bottom of
> the image sits on the baseline of the text and there must be room
> below the baseline for the descender of the 'g'. To be totally
> standards compliant there must be room below the baseline even when
> there are no characters with descenders used.
> But traditionally browsers have fudged this and so in 'Almost
> Standards' mode (and obviously Quirks mode as well) Mozilla fudges it
> as well.
> #header img {display: block;}
> #leftmenu img {display: block;}
> #rightmenu img {display: block;}
> will fix your problem. By turning the images from inline to block
> elements they no longer need to be treated as text characters.
>
> Steve

Thanks Steve!

Yeah, I only left out the alt attribute while I smashing around trying
to get it all working again Thanks for reminding me though to
actually put it back in.

Would it be a big problem if I set:

img {display: block;}

Doing so, making all image on the web page no longer be treated as text
characters? Or would that mess things up?

Thanks for your help! Really appreciate it.

Dave.

Dave Winter <> wrote:

>Would it be a big problem if I set:
>
>img {display: block;}
>
>Doing so, making all image on the web page no longer be treated as text
>characters? Or would that mess things up?

On the page in question it probably wouldn't make much difference. But
don't forget that block level elements have a line break before and
afterwards so it may cause problems elsewhere (when you want an image
to appear inline with some text).

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <> <http://steve.pugh.net/>

Steve Pugh <> wrote:

> If you had
> <div>abcd<img>efgh</div>
> you would expect a space below the image, as by default the bottom of
> the image sits on the baseline of the text and there must be room
> below the baseline for the descender of the 'g'.

That's one way of putting it. Another way is to say that there is some
space below the baseline defined by the text, even when the text has no
descenders.

> To be totally
> standards compliant there must be room below the baseline even when
> there are no characters with descenders used.

I don't see how this would be required in any HTML standard. The height
of text is not defined in HTML.

But it's a natural assumption that visual browsers leave some space below
a string of characters even when they have no descenders, just as it is
natural to expect that there is some space _above_ the characters when a
line consists of just "aaa". It's a feature of normal rendering of
characters that the height of the font is decisive here, not the heights
of characters in the text.

However, shouldn't the situation change when there are _no_ characters,
as in <div><img ...></div>? If we had <div> <img ...></div> or
<div><img ...> </div> (i.e., with a space before or after the img
element), then it would be a debatable case, since the effect of
whitespace is not quite exhaustively defined in HTML specifications. But
when _no_ text is present, the issue of vertically aligning to a baseline
does not arise, does it?

I'm not arguing against observations of browser behavior, just against
the idea that the extra space would be required by standards.

> #header img {display: block;}
> #leftmenu img {display: block;}
> #rightmenu img {display: block;}
> will fix your problem. By turning the images from inline to block
> elements they no longer need to be treated as text characters.

This sounds like bad news. When a document contains an image to be shown
separately, not as part of a paragraph or other construct, the Strict
syntax requires that it be wrapped inside a block level container, as in
<div><img ...></div>
But now it seems that this may cause undesired spacing effects, unless
you take the trouble of adding extra CSS rules.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

"Jukka K. Korpela" <> wrote:
>Steve Pugh <> wrote:
>
>> To be totally
>> standards compliant there must be room below the baseline even when
>> there are no characters with descenders used.
>
>I don't see how this would be required in any HTML standard. The height
>of text is not defined in HTML.

HTML is not the only standard that needs to be considered. It is, of
course, part of the total stupidity of doctype sniffing that the
(X)HTML doctype determines not only how browsers (mis)interpret the
HTML standard but also how they (mis)interpret the CSS standard.

>But it's a natural assumption that visual browsers leave some space below
>a string of characters even when they have no descenders, just as it is
>natural to expect that there is some space _above_ the characters when a
>line consists of just "aaa". It's a feature of normal rendering of
>characters that the height of the font is decisive here, not the heights
>of characters in the text.

True, but the relationship between the font size and the baseline is
not instantly obvious. My explanation was simply intended to get the
point across that the space comes from the font, without going into
details that aren't strictly relevant to the problem at hand.

>However, shouldn't the situation change when there are _no_ characters,
>as in <div><img ...></div>? If we had <div> <img ...></div> or
><div><img ...> </div> (i.e., with a space before or after the img
>element), then it would be a debatable case, since the effect of
>whitespace is not quite exhaustively defined in HTML specifications. But
>when _no_ text is present, the issue of vertically aligning to a baseline
>does not arise, does it?

One would think so. Clearly, Microsoft and Opera think so.

>I'm not arguing against observations of browser behavior, just against
>the idea that the extra space would be required by standards.

The standards are not 100% clear on this. CSS 2.1 is clearer than CSS
2 but still leaves certain things unsaid, however...

Even when there is no text there is still a CSS line box created by
the presence of the inline element <img>.

"The line box height is the distance between the uppermost box top and
the lowermost box bottom." (CSS 2.1, section 10.

In this case one would assume that as the online inline box is that
generated by the <img> that the line box height would be the height of
the <img>.

But, section 10.8.1 defines the line-height property and says that it
"specifies the *minimal* height of line boxes within the element". The
emphasis is in the spec.

This part of the spec continues with "The minimum height consist of a
minimum height above the block's baseline and a minimum depth below
it, exactly as if each line box starts with a zero-width inline box
with the block's font and line height properties (what TEX calls a
"strut")."

Now I know nothing of TeX but the description seems clear enough to me
- even when there is no text present the minimumline box height is
calculated as if there was.

BTW this last quote is not present in CSS2. Some cynics claim that CSS
2.1 is written to make Mozilla's bugs the correct behaviour.

I may be interpreting the specs incorrectly, and the specs may well
not be logical but I hope you now see why I said what I said.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <> <http://steve.pugh.net/>