Crippled or missing borders in IE 7

DC · Mar 19, 2008

Hi,

sorry if this has been answered a million times already - I still did
not find the answer in the groups.

My problem is best explained by the html below. I often experience
missing borders, typically top or bottom. In Firefox everything is
fine, in IE7 (I did not test a lower version) the border is being
crippled.

TIA for any explanations and workarounds.

Regards
DC

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style>
..WP1LinkButton {
BORDER: red 10px solid;
padding: 2px;
}
..WP1LinkButton2 {
BORDER: red 10px solid;
padding: 0px;
}
</style>
</head>

<body>

<table>
<tr>
<td style="height: 50px;">
<a class="WP1LinkButton">Where is the top border?</a>
</td>
<td style="height: 50px;">
<span class="WP1LinkButton2">
<a>1px top border only</a>
</span>
</td>
</tr>
</table>

</body>
</html>

mynameisnobodyodyssea · Mar 19, 2008

I often experience
missing borders, typically top or bottom. In Firefox everything is
fine, in IE7 (I did not test a lower version) the border is being
crippled.

Positioning of elements with borders in browsers
takes into account if the element is inline,
or block-level, or table cell and
IE and Firefox have some differences in calculating
how elements define boxes and their positioning in the browser.
<a> and <span> are inline elements of course and
borders are more reliably calculated by browsers for
block-level elements, like <div> or <p>,
but the situation becomes even more complicated when you
include bordered elements in tables.
For example if you add display:block to the style of the
WP1LinkButton class you might get a better border,
but it would be a contradiction to add display:block
for the WP1LinkButton2 class, because it applies to
span, which is an inline element.

One suggestion would be to drop the tables layout
and to use floated divs for bordered elements.

Also check for HTML and CSS validating errors.

Bergamot · Mar 19, 2008

IE and Firefox have some differences in calculating
how elements define boxes and their positioning in the browser.

For example...?

mynameisnobodyodyssea · Mar 19, 2008

For example...?

For example some IE browsers include (or not - I always forget which)
the border size when they calculate the width/height of an element,
while Firefox does the opposite, things like this.
And IE has some specificities in rendering tables.

I repeat that things become more complicated for browsers
when features like borders that are easier to calculate
for block-level elements are used for inline elements
like <a> or <span> included in table cells.
You can see that the whole border is displayed in IE
when you set display:block for WP1LinkButton,
but this just complicates things, so it would be better
to drop the table layout.

Just to add that it is good practice
not to specify the height of a table cell element,
but let it adjust to the content and padding.
It does not make sense anyway to specify inline individually
the height of table cells in the same row.

Bergamot · Mar 19, 2008

For example some IE browsers include (or not - I always forget which)
the border size when they calculate the width/height of an element,

That's ancient history. IE6 or newer in standards mode uses the standard
box model used by other browsers. You shouldn't be intentionally
triggering quirks mode in *any* browser these days.

And IE has some specificities in rendering tables.

If you're bothered about a couple pixels difference in rendered tables,
you've no doubt got other worse issues to deal with, like scalability
(or lack thereof) in general.

mynameisnobodyodyssea · Mar 19, 2008

[snip]

There are obviously differences in how IE and Firefox render
the code of the OP.

I repeat that my point is quite clear and
proven by the fact that the whole border is rendered in IE if you set
display:block for example for the <a> element class
WP1LinkButton. For the span element to set
display:block would be a contradiction since
<span> is a very inline element... but
browsers are trying to do their best.

What is wrong with you?

Ben C · Mar 19, 2008

[snip]

Click to expand...

There are obviously differences in how IE and Firefox render
the code of the OP.

I repeat that my point is quite clear and
proven by the fact that the whole border is rendered in IE if you set
display:block for example for the <a> element class
WP1LinkButton. For the span element to set
display:block would be a contradiction since
<span> is a very inline element... but
browsers are trying to do their best.

It's sort of a contradiction but in fact perfectly legal and
well-defined so browsers should have no difficulty with it.

A modern browser just renders whatever the CSS says. It doesn't care
what the element type is (except for BR and in practice probably LI).

So provided the HTML is valid for the most part it doesn't matter from
the point of view of rendering which elements you use.

mynameisnobodyodyssea · Mar 19, 2008

It's sort of a contradiction but in fact perfectly legal and
well-defined so browsers should have no difficulty with it.

A modern browser just renders whatever the CSS says. It doesn't care
what the element type is (except for BR and in practice probably LI).

So provided the HTML is valid for the most part it doesn't matter from
the point of view of rendering which elements you use.

What do you mean by a well-defined sort of a contradition?

Block-level and inline elements are different,
this is the whole point of HTML and CSS, and
browsers can get confused when they are not dealt with
properly in the HTML or CSS code.

IE and Firefox render differently the example code
in the original posting,
even when it is corrected to validate HTML and CSS.

Bergamot · Mar 19, 2008

[snip]

Click to expand...

There are obviously differences in how IE and Firefox render
the code of the OP.

I didn't even look at the OP's code, since he didn't bother posting a
URL. Your general statements about known rendering differences led me to
believe you know something specific about what and why, but I see that
is not the case.

I repeat that my point is quite clear

It is not, at least not to me.

and
proven by the fact that the whole border is rendered in IE if you set
display:block for example for the <a> element class
WP1LinkButton.

It seems you made an observation and drew some conclusions from that. It
doesn't really "prove" anything.

For the span element to set
display:block would be a contradiction since
<span> is a very inline element...

but
browsers are trying to do their best.

Maybe some are, though I'm not convinced IE is one of them.

What is wrong with you?

Nothing, except it bugs me when somebody throws out "facts" that aren't
really more than guesses. That doesn't help the OP at all.

Ben C · Mar 19, 2008

What do you mean by a well-defined sort of a contradition?

In HTML some elements are "inline" and others are "block".

In the days before CSS that determined how they were rendered. In a
modern browser it doesn't. What matters is whether the CSS display
property has the value "inline" or "block".

What I'm calling modern browsers (Firefox, Opera, Konqueror, Safari,
etc.) have a default stylesheet containing rules equivalent to this:

span { display: inline }
div { display: block }

So span is usually inline in both the HTML and CSS senses. But you can
set:

span { display: block }

perfectly well, and that makes spans become block-level elements. If you
do that you have an element which is inline in the HTML sense but
block-level and rendered as a block.

It's a contradiction in a sense but only in terminology. The browser
doesn't care, it just gets on with it and renders a block.

Block-level and inline elements are different,

Right, but whether an element is block-level or inline-level depends on
the display property.

<span style="display: block"> ... </span>

is a block-level element.

this is the whole point of HTML and CSS, and
browsers can get confused when they are not dealt with
properly in the HTML or CSS code.

It is the whole point of CSS, but not of HTML. It used to be the whole
point of HTML, but nowadays HTML is not supposed to describe
presentation. So for something to be "inline" or "block" in HTML is
presumably meant to be interpreted in some kind of abstract way (or just
accepted as a bit of an anachronism).

IE and Firefox render differently the example code in the original
posting, even when it is corrected to validate HTML and CSS.

I'm sure you're right. I haven't tested it (I don't have IE) and I don't
know what exactly is causing the difference there.

dorayme · Mar 19, 2008

<[email protected]
m>,

What do you mean by a well-defined sort of a contradition?

Ben C did not say it was a well defined contradiction. He was
going along with your perception of an appearance of oddity but
saying it is not a contradiction. Like saying to someone who
seems puzzled that a bloke called Mr. Tall should be so short
that it is quite possible, nothing in the rules of syntax or
naming conventions stops it.

Block-level and inline elements are different,

.... by default settings of display and things like this. Think of
it as the bet is off if an author changes these defaults. In the
film Normal, Tom Wilkinson, grows breast and has a sex change
operation. He is not a walking contradiction. He is just a feller
that becomes a woman, as fellers *sometimes* do...

mynameisnobodyodyssea · Mar 19, 2008

It is the whole point of CSS, but not of HTML. It used to be the whole
point of HTML, but nowadays HTML is not supposed to describe
presentation. So for something to be "inline" or "block" in HTML is
presumably meant to be interpreted in some kind of abstract way (or just
accepted as a bit of an anachronism).

I'm sure you're right. I haven't tested it (I don't have IE) and I don't
know what exactly is causing the difference there.

Block-level, inline, and table-cell elements are not about
presentation,
they are about syntax in HTML.
You cannot have for example <span><div>something</div></span>
you cannot have a block-level element inside an inline element
(div is block-level, span is an inline element).
Well... you can have that, browsers will try to cope with this,
but it makes no sense,
and it might confuse browsers, so
different browsers could display the same code differently, etc.

I was just trying to answer the question which started this thread,
and I think the answer is to treat accordingly
block-level, inline and table-cell elements.
You can see that adding
display:block to the style makes the border
appear as intended in IE as well,
but especially when applied to <span>
it does not fit logically in the syntax,
in the page element tree, not only in the box visual model.

My point is that it is a good idea to follow the simple rule
that is to consider what are the block-level, inline and
table-cell elements in your page and deal with them
as simply and as logically as you can,
because this will make it easier to browsers to
present the page as intended by the author.

Another simple rule, when using tables only for layout,
consider not using tables.

mynameisnobodyodyssea · Mar 19, 2008

I didn't even look at the OP's code, since he didn't bother posting a
URL. Your general statements about known rendering differences led me to
believe you know something specific about what and why, but I see that
is not the case.

It is not, at least not to me.

It seems you made an observation and drew some conclusions from that. It
doesn't really "prove" anything.

Maybe some are, though I'm not convinced IE is one of them.

Nothing, except it bugs me when somebody throws out "facts" that aren't
really more than guesses. That doesn't help the OP at all.

What I wrote was about the original posting that
started this thread, and that included
HTML + style code.
If you add in the style code display:block you can see the whole
border in IE, and this means that
the problem is that inline, block and table-cell elements
are mixed in such a way as to confuse browsers.

I added clearly that to set display:block
to inline elements
is a contradiction because it is
(both <a> and <span> are inline,
I thought that everyone knows this),
and that it would be better to drop the table layout.

Adding display:block
can solve the problem described in the
original posting of this thread
in IE, but I had to add words of caution (that it is a contradiction),
because display:block applied to inline elements might
create problems in other browsers that I did not test
the code in.

Bergamot · Mar 20, 2008

If you add in the style code display:block you can see the whole
border in IE, and this means that
the problem is that inline, block and table-cell elements
are mixed in such a way as to confuse browsers.

It means no such thing. Or can you point to some article written on this
subject that supports your claim of browser confusion?

I added clearly that to set display:block
to inline elements
is a contradiction

No, it isn't. You don't quite grasp the separation of markup from
presentation, do you?

display:block applied to inline elements might
create problems in other browsers that I did not test
the code in.

Maybe you should study HTML and CSS a little more. Your newbie-ness is
showing.

Ben C · Mar 20, 2008

Block-level, inline, and table-cell elements are not about
presentation,
they are about syntax in HTML.

In HTML yes, but in CSS they are about presentation.

This is from the HTML specification:

Certain HTML elements that may appear in BODY are said to be
"block-level" while others are "inline" (also known as "text
level"). The distinction is founded on several notions:

It's talking about DIV and SPAN.

But in the CSS specification:

Block-level elements are those elements of the source document that
are formatted visually as blocks (e.g., paragraphs). Several values
of the 'display' property make an element block-level: 'block',
'list-item', and 'run-in' (part of the time; see run-in boxes [p.
120] ), and 'table'.

It's talking about the display property.

You cannot have for example <span><div>something</div></span>
Correct.

you cannot have a block-level element inside an inline element
(div is block-level, span is an inline element).

In the HTML sense of block-level and inline-level you cannot. In the CSS
sense you can.

Well... you can have that, browsers will try to cope with this, but it
makes no sense, and it might confuse browsers, so different browsers
could display the same code differently, etc.

Correct-- they may try to repair the invalid HTML in unpredictable ways.

I was just trying to answer the question which started this thread,
and I think the answer is to treat accordingly block-level, inline and
table-cell elements. You can see that adding display:block to the
style makes the border appear as intended in IE as well, but
especially when applied to <span> it does not fit logically in the
syntax, in the page element tree, not only in the box visual model.

The reason the border appears is possibly because a border on a display:
inline element doesn't get any extra space made for it, it just gets
drawn, on top of or underneath anything else that happens to be in the
way.

But there is nothing wrong with setting display: block on a SPAN, it
should not cause a browser any confusion or difficulty. Something
CSS-block can go inside something CSS-inline with no problems (all that
happens is an anonymous block gets created either side of the block).

But putting a DIV inside a SPAN is different-- it's invalid HTML, which
is bad.

My point is that it is a good idea to follow the simple rule that is
to consider what are the block-level, inline and table-cell elements
in your page and deal with them as simply and as logically as you can,

Yes, good idea.

because this will make it easier to browsers to
present the page as intended by the author.

So long as the HTML is valid the browser doesn't mind what you do with
the CSS. Anything goes. There's no point styling things illogically just
because you can. Setting a span to display: block is unusual, but people
often set LI (block-level in HTML) to display: inline for example.

DC · Mar 20, 2008

Positioning of elements with borders in browsers
takes into account if the element is inline,
or block-level, or table cell and
IE and Firefox have some differences in calculating
how elements define boxes and their positioning in the browser.
<a> and <span> are inline elements of course and
borders are more reliably calculated by browsers for
block-level elements, like <div> or <p>,
but the situation becomes even more complicated when you
include bordered elements in tables.
For example if you add display:block to the style of the
WP1LinkButton class you might get a better border,
but it would be a contradiction to add display:block
for the WP1LinkButton2 class, because it applies to
span, which is an inline element.

One suggestion would be to drop the tables layout
and to use floated divs for bordered elements.

Also check for HTML and CSS validating errors.

Thank you! Indeed display: block does make a difference, but it also
produces heavy side effects since the element's size will not adjust
to the text size anymore. See example below. My current solution is to
set the line-height, demonstrated in the third row of the example
below. This works in IE 7 and Firefox 2.

Regards
DC

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<style type="text/css">
.d1 {
width: 300px;
border: thin yellow solid;
}
.b1, .b2, .b3 {
font-size: 16px;
font-family: Arial, Helvetica, Sans-Serif;
padding: 3px;
background-color: gray;
text-align: center;
border: 3px red solid;
color: white;
}
.b2 {
display: block;
}
.b3 {
line-height: 30px;
/*
font-size + padding + border + 3px IE extra fluff (above text) -
static 1 (excess pixel)
= 16 + 6 + 6 + 3 - 1 = 30

I did not find a formula for the extra fluff, it is about as high as
the lower part of
the letter "g" (what is the word for "Unterschnitt" in english -
"undercut"?) of the used
font.
*/
}
</style>
</head>

<body>
<div class="d1">
<a class="b1">Button Inline</a>
<a class="b1">Button Inline</a>
</div>
<div class="d1">
<a class="b2">Button Block</a>
<a class="b2">Button Block</a>
</div>
<div class="d1">
<a class="b3">Button Line-Height</a>
<a class="b3">Button Line-Height</a>
</div>
</body>
</html>

Toby A Inkster · Mar 20, 2008

mynameisnobodyodyssea said:
Block-level, inline, and table-cell elements are not about presentation,
they are about syntax in HTML.

The terms "block" and "inline" are used differently in CSS and HTML.

In CSS, they are all about presentation. Basically a block element has an
implicit line break before and after; it can have margins; its borders
don't look weird when the block element spans more than one line. An
inline element doesn't have an implicit line break before or after.

In HTML, the terms relate to the content model of the element. DIV is a
block element, hence you can pile headings, paragraphs and lists into it
as child elements. SPAN is an inline element, so putting a paragraph
inside a SPAN is not allowed.

Although CSS and HTML use the same terms, the concepts are mostly
unrelated. (But generally HTML block elements are set to display:block in
CSS by default, and inline elements to display:inline.)

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 2 days, 11:17.]

The Semantic Web
http://tobyinkster.co.uk/blog/2008/03/09/sw/

BootNic · Mar 20, 2008

Hi,

sorry if this has been answered a million times already - I still did
not find the answer in the groups.

My problem is best explained by the html below. I often experience
missing borders, typically top or bottom. In Firefox everything is
fine, in IE7 (I did not test a lower version) the border is being
crippled.

Google IE trigger haslayout

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">

replace doctype:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
[snip]

<head>
<style>
.WP1LinkButton {
BORDER: red 10px solid;
padding: 2px;
}
.WP1LinkButton2 {
BORDER: red 10px solid;
padding: 0px;
}
</style>

<!--[if IE]>
<style type="text/css">
..WP1LinkButton, .WP1LinkButton2 {
zoom:1;
}
</style>

</head>

[snip]
--
BootNic Thursday March 20, 2008 8:53 AM
Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact
us.
*Bill Watterson*

DC · Mar 20, 2008

Hi,

Click to expand...

sorry if this has been answered a million times already - I still did
not find the answer in the groups.

Click to expand...

My problem is best explained by the html below. I often experience
missing borders, typically top or bottom. In Firefox everything is
fine, in IE7 (I did not test a lower version) the border is being
crippled.

Click to expand...

Google IE trigger haslayout

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">

Click to expand...

replace doctype:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
[snip]

<head>
<style>
.WP1LinkButton {
BORDER: red 10px solid;
padding: 2px;
}
.WP1LinkButton2 {
BORDER: red 10px solid;
padding: 0px;
}
</style>

Click to expand...

<!--[if IE]>
<style type="text/css">
.WP1LinkButton, .WP1LinkButton2 {
zoom:1;}

</style>

</head>

Click to expand...

[snip]
--
BootNic Thursday March 20, 2008 8:53 AM
Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact
us.
*Bill Watterson*

Thank you BootNic, accurate solution. It only bugs me a little that it
requires an additional style sheet.

Regards
DC

mynameisnobodyodyssea · Mar 20, 2008

The terms "block" and "inline" are used differently in CSS and HTML.

In CSS, they are all about presentation. Basically a block element has an
implicit line break before and after; it can have margins; its borders
don't look weird when the block element spans more than one line. An
inline element doesn't have an implicit line break before or after.

In HTML, the terms relate to the content model of the element. DIV is a
block element, hence you can pile headings, paragraphs and lists into it
as child elements. SPAN is an inline element, so putting a paragraph
inside a SPAN is not allowed.

Although CSS and HTML use the same terms, the concepts are mostly
unrelated. (But generally HTML block elements are set to display:block in
CSS by default, and inline elements to display:inline.)

There are obviously problems for browsers
when inline elements are bordered within table cells,
as shown by the example that started this thread.

I repeat that the simplest solution to the example
that started this thread is to drop the table, and
look at the problem again, considering the simple
rules for inline and block elements
(in HTML and CSS),
and try to have valid HTML and CSS.

What was the code that started the thread for?
If it is for a menu, then lists are better than tables.
There are lots of examples of how not to use tables
in alistapart.com

Help with Visual Lightbox: Scripts	2	May 3, 2023
Can someone tell me if this a real tracker? Or is it one designed to show you a different message at certain times, ie. acting like one?	0	Jan 10, 2021
Having trouble centering contents of td ?	3	May 2, 2023
Image shifts to the right when export the page to pdf	4	May 5, 2023
I need help fixing my website	2	Oct 15, 2023
SendGrid email issue in responsive Gmail	1	Nov 4, 2021
How do I fix this issue in sqaurespace code block?	1	Jul 2, 2024
Help with my responsive home page	2	Dec 14, 2022

Crippled or missing borders in IE 7

DC

mynameisnobodyodyssea

Bergamot

mynameisnobodyodyssea

Bergamot

mynameisnobodyodyssea

Ben C

mynameisnobodyodyssea

Bergamot

Ben C

dorayme

mynameisnobodyodyssea

mynameisnobodyodyssea

Bergamot

Ben C

DC

Toby A Inkster

BootNic

DC

mynameisnobodyodyssea

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads