Sort of. {display: inline-block;} triggers hasLayout which is needed, then you need to reset IE6/7 to {display: inline;}. See Inline-block Gallery for an example and explanation.
hah, i tried resetting, no, won’t do, it kills the whole behaviour.
display:inline-block;
display:inline;
usually works fine in IE6, but what I’m looking for are not the height/width, it’s the vertical alignment, as you see I’m working in undefined css right now.
its a refined cross-browser css only vertical dropdown, and its working well so far.
slightly clearer explanation:
the inline block property on elements also affects the vertical alignment of its siblings, resetting it to display:inline removes this.
i was initially looking to do this with <div>'s in IE6, but found no way, while setting this on a <a> works fine.
edit: oh right right, i forgot, different rule-set.
edit2: what are the effects of resetting it to display:inline in IE6?
working version:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="http://localhost/41logo/host/htdocs/41/css/navigation.css" />
<title>DisplayInlineBlock</title>
<style type="text/css">
#box1 {
border:solid red 1px;
height:200px;
width:200px;
display:inline-block;
}
#box2 {
border:solid green 1px;
height:250px;
width:200px;
display:inline-block;
}
</style>
<!--[if lte IE 7]>
<style type="text/css">
#box1,#box2 {
display:inline;/*makes display:inline-block; work on non inline elements*/
}
</style>
<![endif]-->
</head>
<body>
<div id="box1"></div><div id="box2"></div>
</body>
</html>
edit2: what are the effects of resetting it to display:inline in IE6?
Triggering hasLayout in IE6/7 is effectively the same as creating a new block formatting context. You now have a rectangular element box instead of an inline box, even after you declare them inline. Since those IEs don’t grok inline-block, their natural block status would rule. By declaring them inline, they act inline, but hasLayout means the blocks are rendered inline; just like inline-block.
Reading that over even confuses me. Good luck making sense of it.
I have a similar article here that more or less says the same as Gary anyway.
The easiest way to explain it is that to make a block element behave as an inline-block in IE7 and under you simply need to declare it as display:inline and then apply haslayout. The haslayout trigger has to be one that applies to inline elements and therefore zoom would be the most appropriate (you cannot use height or width as they are ignored for inline elements).
If you use display:inline-block as a haslayout trigger in the same rule then the element is no longer display:inline which is why the separate rule trick has to be used. The element is first given haslayout with display:inline-block and then made inline with display:inline - the order is important because the reverse order would not work.
Here’s an example just using zoom and display:inline all in one rule.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
/* ie7 and under only example */
div {
display:inline;
zoom:1.0;
background:red;
vertical-align:bottom;
margin:20px;
}
</style>
</head>
<body>
<div>
<p>test</p>
<p>test</p>
<p>test</p>
</div>
<div>
<p>test</p>
<p>test</p>
</div>
<div>
<p>test</p>
<p>test</p>
<p>test</p>
<p>test</p>
<p>test</p>
<p>test</p>
</div>
</body>
</html>
thanks paul, but as all the other browsers are using display:inline-block it makes no sense to add haslayout again by giving it zoom:1
what worries me is that i tested it with browsershots in lots of browsers, and some browsers really go mad, especially the old operas (7.*, 8.0 etc) (cant believe how crappy they are) and lots of noname browsers that i cant remember the names of.
Yes of course - I was just saying what the real triggers were for clarification
what worries me is that i tested it with browsershots in lots of browsers, and some browsers really go mad, especially the old operas (7.*, 8.0 etc) (cant believe how crappy they are) and lots of noname browsers that i cant remember the names of.
should i even worry about those browsers?
These days you cant support every version of browsers like opera because it changes on every iteration and indeed is almost impossible to fix one version without breaking the other (just look at its recent issues with min-height:100%) .
I usually only test in the latest of these minor browsers. Unless your audience is all opera users then you would need to think again. However most opera users upgrade straight away so most are using the current browser anyway.
There are loads of browsers out there but most are based on well known engines so as long as you have checked the main browsers being used you have a good chance of catering for most of the others as well.
The problem is that if a lot of these minor browsers are showing your page incorrectly then there well may be something that they all don’t like and it’s always worth investigating why. If it’s because of a rule they don’t understand they you have a choice of either not supporting them or trying something different to make all happy.
Good luck making sense of it.