Crippled or missing borders in IE 7

Discussion in 'HTML' started by DC, Mar 19, 2008.

  1. DC

    DC Guest

    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>
    DC, Mar 19, 2008
    #1
    1. Advertising

  2. DC

    Guest

    On Mar 19, 5:45 pm, DC <> wrote:
    > 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.
    , Mar 19, 2008
    #2
    1. Advertising

  3. DC

    Bergamot Guest

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


    For example...?

    --
    Berg
    Bergamot, Mar 19, 2008
    #3
  4. DC

    Guest

    On Mar 19, 8:56 pm, Bergamot <> wrote:
    > mynameisnobodyodys.. wrote:
    >
    > > IE and Firefox have some differences in calculating
    > > how elements define boxes and their positioning in the browser.

    >
    > For example...?
    >
    > --
    > Berg


    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.
    , Mar 19, 2008
    #4
  5. DC

    Bergamot Guest

    wrote:
    > On Mar 19, 8:56 pm, Bergamot <> wrote:
    >> mynameisnobodyodys.. wrote:
    >>
    >> > IE and Firefox have some differences in calculating
    >> > how elements define boxes and their positioning in the browser.

    >>
    >> 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,


    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.

    --
    Berg
    Bergamot, Mar 19, 2008
    #5
  6. DC

    Guest

    On Mar 19, 9:43 pm, Bergamot <> wrote:
    >
    > [snip]
    > --
    > Berg


    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?

    --
    Cristina.
    , Mar 19, 2008
    #6
  7. DC

    Ben C Guest

    On 2008-03-19, <> wrote:
    > On Mar 19, 9:43 pm, Bergamot <> wrote:
    >>
    >> [snip]
    >> --
    >> Berg

    >
    > 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.
    Ben C, Mar 19, 2008
    #7
  8. DC

    Guest

    On Mar 19, 10:05 pm, Ben C <> wrote:

    > 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.
    , Mar 19, 2008
    #8
  9. DC

    Bergamot Guest

    wrote:
    > On Mar 19, 9:43 pm, Bergamot <> wrote:
    >>
    >> [snip]

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


    So is <a>, so you are contradicting yourself now.

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

    --
    Berg
    Bergamot, Mar 19, 2008
    #9
  10. DC

    Ben C Guest

    On 2008-03-19, <> wrote:
    > On Mar 19, 10:05 pm, Ben C <> wrote:
    >
    >> 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?


    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.
    Ben C, Mar 19, 2008
    #10
  11. DC

    dorayme Guest

    In article
    <
    m>,
    wrote:

    > On Mar 19, 10:05 pm, Ben C <> wrote:
    >
    > > 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?
    >


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

    --
    dorayme
    dorayme, Mar 19, 2008
    #11
  12. DC

    Guest

    On Mar 19, 11:12 pm, Ben C wrote:
    > 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.


    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.
    , Mar 19, 2008
    #12
  13. DC

    Guest

    On Mar 19, 11:05 pm, Bergamot wrote:
    > 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...

    >
    > So is <a>, so you are contradicting yourself now.
    >
    > > 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.
    >
    > --
    > Berg


    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.
    , Mar 19, 2008
    #13
  14. DC

    Bergamot Guest

    wrote:
    >
    > 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.

    --
    Berg
    Bergamot, Mar 20, 2008
    #14
  15. DC

    Ben C Guest

    On 2008-03-19, <> wrote:
    > On Mar 19, 11:12 pm, Ben C wrote:
    >> 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.

    >
    > 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.
    Ben C, Mar 20, 2008
    #15
  16. DC

    DC Guest

    On 19 Mrz., 19:28, wrote:
    > On Mar 19, 5:45 pm, DC <> wrote:
    >
    > > 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.


    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>
    DC, Mar 20, 2008
    #16
  17. mynameisnobodyodyssea wrote:

    > 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/
    Toby A Inkster, Mar 20, 2008
    #17
  18. DC

    BootNic Guest

    DC <> wrote in news:54cd3e47-7b77-460e-ab39-
    :

    > 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>
    <![endif]-->

    > </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*
    BootNic, Mar 20, 2008
    #18
  19. DC

    DC Guest

    On 20 Mrz., 13:53, BootNic <> wrote:
    > DC <> wrote in news:54cd3e47-7b77-460e-ab39-
    > :
    >
    > > 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>
    > <![endif]-->
    >
    > > </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*


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

    Regards
    DC
    DC, Mar 20, 2008
    #19
  20. DC

    Guest

    On Mar 20, 9:36 am, Toby A Inkster <>
    wrote:
    > mynameisnobodyodyssea wrote:
    > > 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


    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
    , Mar 20, 2008
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roger Meyers

    Re: Windows.Forms crippled by Microsoft

    Roger Meyers, Jun 29, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    1,279
    Richard Grimes [MVP]
    Jul 2, 2003
  2. Russ Bishop

    Re: Windows.Forms crippled by Microsoft

    Russ Bishop, Jun 30, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    1,181
    Russ Bishop
    Jun 30, 2003
  3. Kieran Benton

    Re: Windows.Forms crippled by Microsoft

    Kieran Benton, Sep 9, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    455
    William Ryan
    Sep 11, 2003
  4. George
    Replies:
    9
    Views:
    4,895
    George
    Oct 25, 2004
  5. Neredbojias

    Site Crippled

    Neredbojias, Sep 1, 2008, in forum: HTML
    Replies:
    1
    Views:
    359
    Neredbojias
    Sep 2, 2008
Loading...

Share This Page