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, gary
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?
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
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"
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.
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!
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
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. 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
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):
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
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
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
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