1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

browser display differences

Discussion in 'CSS' started by gwh, Mar 12, 2008.

  1. kk5st

    kk5st Prominent Member

    Messages:
    3,486
    Likes Received:
    367
    Best Answers:
    28
    Trophy Points:
    335
    #21
    Copy the code and try it. You may find whatever is causing the issue. Try adding a small margin to .lineblock.

    As to clients wanting pixel perfection x-browser, if you've done the information gathering stage and the project brief comprehensively, the client will not even raise an eyebrow at small differences. The type of clients you mention are print oriented and skilled at their crafts. Once shown the differences between web and print, they quickly understand. (At least that's my experience.)

    cheers,
    SEMrush
    gary
     
    kk5st, Mar 15, 2008 IP
    SEMrush
  2. Stomme poes

    Stomme poes Peon

    Messages:
    3,195
    Likes Received:
    136
    Best Answers:
    0
    Trophy Points:
    0
    #22
    I agree that unless you're doing some neat trick, pixel-perfect setups are not to be expected (crossbrowser anyway).
    I've copied both codes and don't even see text in deathshadow's but I'll need to be at work to get to a windows machine to really see differences.
    I see the * html hack setting inline on the element but wouldn't you want to do this first in source? I thought IE had to think the thing was already inline?
     
    Stomme poes, Mar 15, 2008 IP
  3. kk5st

    kk5st Prominent Member

    Messages:
    3,486
    Likes Received:
    367
    Best Answers:
    28
    Trophy Points:
    335
    #23
    I haven't played with inline-block all that much before this thread, but my understanding was that the element had to be returned to inline, like using the Campbell tripswitch hack.

    I just tried it placed first, and it doesn't seem to make a difference. Removing it breaks IE6.

    cheers,

    gary
     
    kk5st, Mar 15, 2008 IP
  4. Stomme poes

    Stomme poes Peon

    Messages:
    3,195
    Likes Received:
    136
    Best Answers:
    0
    Trophy Points:
    0
    #24
    And I've always heard it the other way around (though that moving it around doesn't change anything on IE seems to prove otherwise).... that IE will honour display: inline-block but only on inline elements... some web sites said natively inline elements while others said no, you could first set it to inline.

    The changing back afterwards I thought was only when you were using inline-block to trigger Haslayout and then going back to what you really wanted, inline or block, because it was the one trigger you could go back on and still keep HL="true"
     
    Stomme poes, Mar 15, 2008 IP
  5. RelevantBuZZ_PR

    RelevantBuZZ_PR Guest

    Messages:
    101
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    0
    #25

    Maybe not perfect but very close. I come across many designers who are not willing to invest the time and effort to lay out their designs to the pixel. I'm all for W3C compliance and have created sites that uphold the highest of standards but for me in the end it's about the display. That is the standard I set myself to. :)
     
    RelevantBuZZ_PR, Mar 16, 2008 IP
  6. Suzy

    Suzy Peon

    Messages:
    27
    Likes Received:
    2
    Best Answers:
    0
    Trophy Points:
    0
    #26
    5.0 didn't do it - it's supported from 5.5 onwards, IE appears to only support it on elements which are inline by default.. span, em, a etc.. but you can get it to honour it on block level elements (which I agree is more natural.. like a table cell - you may want to put block level elements inside your inline-block?) - by using the double barrel approach

    div {display: inline-block;}
    div {display: inline;}
    Code (markup):
    It has to be in 2 separate rules to make it work, and yes it's the basis for the hasLayout Tripswitch (though with it it's more likely the second property would be a "reset" to display: block; )

    however what it's doing for actual proper 'inline-blocks' is trigger haslayout which allows the width and height that a normal display: inline; element shouldn't be allowed to receive

    does anyone have IE8 to test how the inline-block support is doing on block level elements?

    inline-block support would be so handy for galleries and things like that!
     
    Suzy, Mar 16, 2008 IP
  7. Suzy

    Suzy Peon

    Messages:
    27
    Likes Received:
    2
    Best Answers:
    0
    Trophy Points:
    0
    #27
    found the answer, well for B1 anyway as reported by PPK

    this means in theory that the double barrel approach (or at least the second part) can be used in a filter in order to start taking advantage and still offer back compatibility :)
     
    Suzy, Mar 16, 2008 IP
  8. kk5st

    kk5st Prominent Member

    Messages:
    3,486
    Likes Received:
    367
    Best Answers:
    28
    Trophy Points:
    335
    #28
    Much like IE's allowing width, &c., to be put on native inline elements. I see no ready benefit to making an inline element inline-block. Making a native block element render in an inline box, i.e. inline-block makes sense.

    PPK to the rescue. :D

    A primary use, I'd think. My earlier post addressed this purpose. I used what I learned this thread to update a 2 week old thread on the subject of galleries over on CSSCreator.

    cheers,

    gary
     
    kk5st, Mar 16, 2008 IP
  9. Suzy

    Suzy Peon

    Messages:
    27
    Likes Received:
    2
    Best Answers:
    0
    Trophy Points:
    0
    #29
    haven't looked at the other 2 yet.. but the extra space you're seeing in IE5 is the original "Whitespace in lists" problem

    there are varying solutions depending on the context, but I find this one to be best as it means the link still gets its full rollover effect

    but due to box model difference, hasLayout causing problems for IE7 etc.. this should only be shown to IE 5.0 which can be done via a conditional comment

    <!--[if lt IE 5.5]>
    <style type="text/css" media="screen">
    li a:link {display: inline; width: 100%; vertical-align: top;}
    </style>
    <![endif]-->
    Code (markup):
     
    Suzy, Mar 17, 2008 IP
  10. Suzy

    Suzy Peon

    Messages:
    27
    Likes Received:
    2
    Best Answers:
    0
    Trophy Points:
    0
    #30
    hiya Gary.. I also looked in this a couple of years ago, moz's inline-box is the closest one but not perfect and it actually requires a nested div, with a width on it inside the "inline-block" to stop the content over-running, however the <p> in your code is acting as that nested "barrier". There were problems with lists and things displaying side-by-side in moz's box too but can't remember it all now. I see you have the "disappearing" margins in IE.. remember that to get around that you just need to explicitly declare margins instead of leaving them to default ;)

    here's my attempt at the CSS to reflect the IE8 upgrade and sort those margins!

      <style type="text/css">
      #gallery {text-align: center;}
    
      .lineblock {
      width: 75px;
      border: 1px solid black;
      text-align: center;
      display: -moz-inline-box;
      display: inline-block;
      vertical-align: top;
      }
    
      .lineblock p {
      text-align: center;
      width: 75px;
      margin: 0.5em 0; /* explicitly declare margins to help IE */
      }
    </style>
    <!--[if lte IE 7]>
    <style type="text/css" media="screen">
    .lineblock {display: inline;} /* all versions of IE up to 7 to make the block an inline-block */
    </style>
    <![endif]-->
    Code (markup):
    take care, Suzy
     
    Suzy, Mar 17, 2008 IP
  11. kk5st

    kk5st Prominent Member

    Messages:
    3,486
    Likes Received:
    367
    Best Answers:
    28
    Trophy Points:
    335
    #31
    Thanks, Suzy.

    That's pretty much what I've arrived at, too. I would appreciate you checking my thinking on a couple of items. Refer to the CC.
    
    <!--[if lte IE 7]>
      <style type="text/css">
    /*<![CDATA[*/
    
      .lineblock {              /*for IE6&7*/
      display: inline;
      margin: .5em .2em;        /*side margin added for IE6*/
      padding: 1em 0;           /*IE improperly collapse p's margins in
                                  spite of border.  Padding replaces them*/
      }
    
      /*]]>*/
      </style>
    <![endif]-->
    Code (markup):
    • I don't think this is a disappearing margin, as when there is no lateral margin on the outer div, and the margins are explicit, i.e. .lineblock {margin: .5em 0;}, FF et al still have a white space as expected, but IE does not. Making the lateral margin some small value separates the IE divs, but the margins are added to either side of the white space in the others. Moved the lateral margins to the cc.
    • In IE, <p>'s vertical margins collapse in spite of <div>'s border, even when explicit. I put padding on the div to emulate margins on p.
    • Vertical margins on .lineblock do not collapse, so half the desired value used. Is this correct? It would be on floats and a few other conditions; but this, I don't know.

    cheers,

    gary
     
    kk5st, Mar 17, 2008 IP
  12. Suzy

    Suzy Peon

    Messages:
    27
    Likes Received:
    2
    Best Answers:
    0
    Trophy Points:
    0
    #32
    I'm confused.. it's easy to do that ;) but if you're referring to the 4px whitespace between the blocks which would be the normal inline word-space, I'm not seeing it in IE or FF (2.0.0.12), perhaps you're on FF3?

    if it is that I would say IE's not got it because it's not really a true inline-block, it's a hasLayout version of one so certainly put the margin in the CC.. will be interesting to see what IE8 does with it, and I don't understand why we're seeing this differently in FF, I know FF3 supports I-Block now too so perhaps the -moz-inline-box doesn't have it but the real IB does ?

    I see the reason for the padding now.... but again the explicit vertical margins are working just fine for for me, hence my term of disappearing rather than collapsing - this often happens to elements with default margins inside a box with hasLayout (e.g. floats) so that is the solution I always use as it keeps it out of the conditional, and brings the margins under your own control anyway..

    I hadn't noticed that but yes it seems so - I tested with a pixel margin and measured the vertical space, it doubles .. so half margins or just a top/bottom one

    -Suzy
     
    Suzy, Mar 17, 2008 IP
  13. kk5st

    kk5st Prominent Member

    Messages:
    3,486
    Likes Received:
    367
    Best Answers:
    28
    Trophy Points:
    335
    #33
    Thanks,

    I'll take another look at the margin vs. padding issue, and perhaps take your advice and make the IE fix common to all.

    I am using FF2.0.0.12. That beta stuff, I leave to the more adventurous. There are always enough of them to take care of the occasional back to the future question.

    I got the same results on FF2, Opera9 and Konqueror3.5. IE was odd man out on the white space issue.

    cheers,

    gary
     
    kk5st, Mar 17, 2008 IP