XHTML bug? Transitional/Strict Rendering Issues

D

Dave Winter

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

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

SpaceGirl

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.
Click to expand...

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 :)
 
D

Dave Winter

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

Steve Pugh

Dave Winter said:
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?
Click to expand...

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
 
W

Whitecrest

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?
Click to expand...

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

Dave Winter

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
Click to expand...

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

Steve Pugh

Dave Winter said:
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?
Click to expand...

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
 
J

Jukka K. Korpela

Steve Pugh said:
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'.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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

Steve Pugh

Jukka K. Korpela said:
I don't see how this would be required in any HTML standard. The height
of text is not defined in HTML.
Click to expand...

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.
Click to expand...

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?
Click to expand...

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.
Click to expand...

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

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
 
C

C A Upsdell

Dave Winter said:
Would it be a big problem if I set:

img {display: block;}
Click to expand...

Mozilla is doing it right, but recent versions only do this in standards
mode, which is triggered by a strict DTD; transitional uses its
'almost-standards mode', which is the same as standards mode except that it
does not produce the unwanted vertical gaps. Setting display:block is the
correct solution.
 
J

Jukka K. Korpela

Steve Pugh said:
HTML is not the only standard that needs to be considered.
Click to expand...

But in the context of alt.html, isn't it a fair assumption that you mean
HTML "standards" (i.e., W3C Recommendations on HTML) when you just say
"standard"?
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.
Click to expand...

Quite right, but the CSS "standard" does _not_ specify how HTML shall or
should be rendered. It defines a style sheet "language", which can be
used in various contexts, and it assigns meanings to style sheets.
HTML, on the other hand, does not require any style sheet. And when you
use HTML and CSS, there is really nothing that binds the two together in
the sense of prescribing default rendering for HTML in CSS terms. The
"sample style sheet" for HTML in CSS specs is a poor joke; it is neither
normative (the spec says this explicitly) nor a realistic description,
though it might be seen as having ingredients of both.

By the way, does this mean that when CSS is switched off (on browsers
that support this), the problem vanishes?
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>.
Click to expand...

Well, maybe. But there is actually no normative definition of what an img
element is in CSS terms. Of course this mostly reflects the ways that the
W3C works, creating specifications that contain quite a lot of things to
be implied or deduced.

Is there something that prevents a browser from having
img { line-height: 0; }
in its default style sheet? Wouldn't this be very reasonable, in fact?
After all, since an image has intrinsic dimensions, there is no need to
set any particular minimum height. And setting a minimum height, if
implemented consistently, would destroy the layout effect that people try
to achieve using a table cell containing just a single-pixel GIF, with
suitable settings for the cell. Whatever one thinks about such tricks, it
can hardly be useful to mess up pages using them if there is no better
reason than a strange idea of applying the page's line height (as
inherited) to images.

Actually, is img { line-height: 0; } in authors' style sheets a general
solution to the problem?
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.
Click to expand...

In any case, CSS 2.1 is not a standard yet, even by W3C standards.
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.
Click to expand...

Yes, I see your point, I'm just worried about the consequences.
 
S

Steve Pugh

Jukka K. Korpela said:
By the way, does this mean that when CSS is switched off (on browsers
that support this), the problem vanishes?
Click to expand...

As far as I can tell the problem is unique to Gecko (I only have
Windows to hand so can't test in Safari or Konqueror). Disabling CSS
in Gecko is not possible.
Is there something that prevents a browser from having
img { line-height: 0; }
in its default style sheet? Wouldn't this be very reasonable, in fact?

Actually, is img { line-height: 0; } in authors' style sheets a general
solution to the problem?
Click to expand...

It wouldn't make any difference. The line-height of the div is what
determines the minimum height of the line box.

"If the property is set on a block-level element whose content is
composed of inline-level elements, it specifies the minimal height of
each generated inline box."

(Note the difference from the CSS 2.1 spec I quoted earlier: here in
CSS 2 it specifies the minimal height of the inline boxes, not as in
2.1 the line boxes.)

In fact the effect of line-height on replaced inline elements like img
is undefined. It explicitly doesn't do what it does for non-replaced
inline elements, but no alternative meaning is supplied.

"If the property is set on an inline-level element, it specifies the
exact height of each box generated by the element. (Except for inline
replaced elements, where the height of the box is given by the
'height' property.)"

Yet "Applies to: all elements".

http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height

Steve
 
M

Mark Parnell

Disabling CSS in Gecko is not possible.
Click to expand...

If the title attribute has been used for the styles (e.g. <link
rel="stylesheet type="text/css" title="My Style">), you can disable CSS
through View>Use Style>Basic Page Style, because the CSS "version" will
be listed separately (e.g. in the above, as "My Style").

If there is no title attribute, the Basic Page Style uses the CSS.
 
S

Steve Pugh

Mark Parnell said:
If the title attribute has been used for the styles (e.g. <link
rel="stylesheet type="text/css" title="My Style">), you can disable CSS
through View>Use Style>Basic Page Style, because the CSS "version" will
be listed separately (e.g. in the above, as "My Style").

If there is no title attribute, the Basic Page Style uses the CSS.
Click to expand...

How do I disable the CSS used by Gecko's own browser style sheet?

Steve
 
T

Toby A Inkster

Steve said:
How do I disable the CSS used by Gecko's own browser style sheet?
Click to expand...

Delete the "html.css" file, which controls Gecko's default rendering of
HTML. On my system it's in the "/usr/lib/mozilla-1.6/res" directory.
 
S

Steve Pugh

Toby A Inkster said:
Delete the "html.css" file, which controls Gecko's default rendering of
HTML. On my system it's in the "/usr/lib/mozilla-1.6/res" directory.
Click to expand...

That works. It makes the browser unusable, but it works. ;-)

Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

xhtml table attributes 33
IE/Firefox XHTML Strict 7
XHTML - how extend/create ELEMENT body in my DTD? 0
XHTML strict 4
what is better strict or xhtml? 17
Advantages of HTML Strict over Transitional 10
4.01 strict weirdness 5
xalan versus ie xml rendering 3

Members online

No members online now.
Total: 27 (members: 0, guests: 27)
Robots: 330

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top