filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale, src=img/png-file.png);

The most commonly used solution for the geek ones os to implement a javascript programmed to parse the whole shazan, to look for PNG references and, with a global replace, to turn those into filter areas. Since this is a javascript-dependent solution, and since it comes with alterations on the structure of the document, I’ll just drop it right here and move along to the really intersting part of the problem, which is the simpler CSS solution.

Why CSS? Well, simply because most ofthen than not, you need to use PNGs within an external CSS, and javascript stops there.

If you didn’t get a chance to read the !important; article, I strongly recommend you do so before moving along with this article.

Normally, in CSS, we set a background image like this:

.style {
background-image: url(img/png-file.png);
}

, which works in any sane browser, but not in IE.
In IE, as I was saying, you MUST do it like this:

.style {
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale, src=img/png-file.png);
}

As you can see, we have two different properties trying to accomplish the same thing. If you already read the above-recommended article, you’ll understand how the solution to this problem is to apply a double !important; , like this:

.style {

background-image: url(img/png-file.png) !important;

background-image: none;

filter: none !important;

filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=scale, src=img/png-file.png);

}

This way, FF will “see” one valid background and zero filters, while IE will “see” zero background and one filter. Problem solved. That’s it for today…

In this image I’m using as an example, the blue border represents the parent element (the context), the red border is an element positioned absolute, and the green border represents an element positioned relative. The red and green elements are included, code-wise, in the blue one, obiously.

Relative – using the position: relative; CSS property, we instruct the browser to position the element relative to its context, in a fluid mode. In other words, we force the relative element to depend, position-wise, on it’s parent, but also on the in-line flow of the other elements present in the same context. Put bluntly, we force the element to behave like a letter in a block of text.
Absolute - using the position: absolute; CSS property, we instruct the browser to position the element relative to its context, but independent of the in-line flow of the other elements in the context. In other words, we force the element to maintain fixed position coordinates, expressed in pixels or directions.

At least in theory.

Because, when you try to do this in real life, you notice that IE and FF go bananas when using position:absolute, every browser interpreting in its own way what element to report the positioning to. And the resulting effect will look completely different in different browsers.

Why is that? Because browsers decide differently on wheather the next relative parent is either the next logical parent or the BODY.

Sounds absurd, I know, but all makes sense in the end, you’ll see. When they need to position an element = ABSOLUTE, all browsers start looking up, ierarchically, looking for the next HTML element defined specifically as RELATIVE. Some consider this to be the parent, some consider the body. Hence the difference in visual results.

The solution? very simple: (Even if it sounds redundant,) when you tant to position X absolute in Y, then specifically define Y as having a position: relative;.

This will force ANY browser to explicitely understand what tag to report to (remember? the next ierarchically superior element that is explicitely set as relative), and to visually solve the problem in the same way.

Basic usage: instead of width: 300px; you can write width: 300px !important;. But, more important, what does it do? Let’s see…

The basic function of !important; is to priorotize/set an ierarchy among the CSS properties attached to a page (be those inline or linked in external css files). In this respect, it can be used for 2 main purposes:

1. The first purpose, more known, is to differentiate certain properties between FF and IE. In this instance, the hack relies on the fact that, in the cases where IE finds 2 definitions of the same property, it tends to prefer the property that doesn’t have the !important; attached to it.

Example:
Let’s say we want an element to have in IE width: 100px; and in FF 120px; How do we achieve this? Easy: we write the same property twice: width: 120px !important; width: 100px;. FF will understand from this 120px, and IE will understand 100px. Easy, to the point and in many cases very useful.

2. The second, less known but just as important function, it to prioritize ierarchically a css property. What does this mean?

A. You may know (or just find out, now) that in CSS you can define CLASSES ot TAGs. The classes are particular cases and are prefixed with a dot, and the tags are global re-definitions of the way HTML tags should display. body {} redefines a TAG, and .body {} is a CLASS.

What’s important here is that a TAG’s properties are superior, ierarchically, to those of a CLASS. If, for instance, I define p {color: #cccccc;} and then, in a particular P, I want to use the class .green {color: #009900;}, .green will show up gray, instead of green, because a tag is more general/powerful than a class, i.e. P is more general/powerful than .green.

B. You may also know (or just find out) that in CSS we can define complex classes. For instance, .green {} is one thing, while .green .title {} means “all the titles found in a green“. This can help us structure, detail and prioritize very well and in an orderly fashion alot of classes and particular cases.

Getting back to our sheep: the bottomline from paragraphs A and B is that in CSS ierarchy exists and is important.
But what do you do when you need to override that ierarchy? YOU USE !important;.

This way, the problem above (the one with p and .green) can be solved like this: .green {color: #009900 !important;}. This way, if we use a .green in a p, the color property in .green will decome more important/powerful than the one in the p, and display correctly.

Saner browsers (FF included) don’t take things “for granted”. They don’t work user-friendly, but mathematically. To position an element in relative terms, the browser needs to know exactly what are the parameters needed for the calculation of that particular relative position. Since, in this case, we’re talking horisontal positioning, the browser needs to know the div’s horisontal margins (left and right). In other words, if I want a DIV to be horisontally centered, I MUST tell it to have:

margin-left: auto;
margin-right: auto;

Without these simple settings, FF would stubbornly position any non-floating div to the left margin of it’s holder/parent, irrespective of that holder/parent’s text-align.

All said and done, the problem is solved. Too easy? Doesn’t matter, what matters is that it helps you.

But the problem stays. Why? Because verical-aligning is only specific to certain HTML elements, and DIV isn’t one of them. So what then?

Well… it depends. You have not one, but two solutions, depending wheather you want your DIV to have a fixed height, or you want it to have a height relative to the height of the page. In either case, the basic principle is that your DIV must be placed into a context clearly defined position-wise, be it relative or absolute. Let’s take them one at a time…

Simple You set the din in the CSS, with the following parameters:

position: absolute; height: x%; top: ((100-x)/2)%;

Well, what I just wrote is an EXAMPLE, not to be taken literally, but to be interpreted. Don’t just copy-paste, cuz it won’t work. See it “translated” into usable code, in this example:

position: absolute; height: 40%; top: 30%;

If you have any questions, please leave a comment and we’ll sort them out

This one may look trickyer… but it’s doable. Before anything, let’s create a “dummy” div, and define it like so::

.dummy {position: absolute; top: 50%;}

Clearly, this div will sit exactly in the vertical middle of the page. Step 2 is to create, inside this dummy div, the div that we really care about. Let’s say it will have the height “X”. The CSS parameters will look like this:

position: absolute; height: Xpx; top: (-X/2)px;

Again, this is just an example of a formula. Translated in a real-life example, it would look something like this:

position: absolute; height: 300px; top: -150px;

Problem solved!

Note 1: For whoever doesn’t quite grasp yet what’s going on with position:absolute and what it involves, I strongly recommend the post Elements positioned ABSOLUTE in a RELATIVE context.
Note 2: For who has problems with horisontal alignment or with widths, read this: Horisontally centered DIVs: look out for MARGINs!.
Final Note: The parameters given in the examples above represent a bare minimum necessary for the functioning of these examples. You’re, obviously, free to add up as many extra parameters as you see fit, starting with the common width and going up the ladder to the baddest meanest hacks you know.

The Problem
The problem is that the FLOAT’s visual rendering model is an archaic one, dating back when a float was limited to an <IMG>’s align: left / align: right, which allowed the text to flow around an image (or an image to “text-wrap”). Back in the day, a float was limited, conceptually, to < IMG > si < P >. What resulted from the old model? Something like this:

If you look closer, you’ll see that the image included in the first < P > (marked with magenta in the image) has an align=”left” (the functional equivalent of float: left; in CSS), which makes the < P >-s (including the ones to follow) to seamlessly flow around the image. All nice an dandy.

But what do you do when you want that image/float to “force” the height of it’s containing holder? What do you do if you want that < P > -ul containing the image to stretch down in a way to include ALL the image? That was easy peasy with tables, but DIVs make it much harder.

Why? Because, as I was saying: when they conceived and created the specification for the FLOAT model, the dear W3C guys simply considered the above model to be more natural. Don’t ask why. What this means, for the coder? A big’ol pain in the neck, because not only is it a serious issue, but it happens to be a cross-browser one too…

The Solution?

Various tests yielded various solutions for various browsers.

For instance, in IE, setting a height of the DIV was enough. And, in order not to affect the layout, it was best to just set the height to 1% – IE would spread its div-s as needed, anyway, moving through that 1% like mice through cheeze.

But this would wreck a layout in FF – since it had no effect whatsoever. In return, in FF it was enough to manually enter, at the end of the div, an HTML element with the clear:both property. This would force the DIV to stretch beyond that little forcepsed-in element, since clear-both allows no other elements to be in the same line with it, thus forcing the div to stretch below it. To better understand this, here’s another drawing:

(that blue border around that dot illustrates the effect of clear-both;)

But since manually inserting code into the HTML just to get this working is rather un-elegant, they came up with another solution: to take advantage of a FF-specific CSS property: content: “”;. What this does, is it allows you to insert code into the HTML, from the CSS. Obviously, it only works in FF, but it’s useful in it’s way.

How can we apply these 2 solutions so far?

FF:

.clearfix:after {content: "."; display: block; height: 0;
                 clear: both; visibility: hidden;}

IE:

* html .clearfix {height: 1%;}

After which, in HTML, we give our DIV the class “clearfix”. And so we get to the famous “CLEARFIX” solution, which saved alot of HTML geeks from eternal shame:

.clearfix:after  {content: "."; display: block; height: 0;
                  clear: both; visibility: hidden;}
/* Hides from IE-mac */
* html .clearfix {height: 1%;}
/* End hide from IE-mac */

But wait! IE7 came along… And this trick didn’t work well with it’s majesty… What to do, what to do? Take all the sites you’ve done so far and start re-coding them just because IE7 is so retarded and clients who suddenly discover IE7 see theirs sites messed-up? This dear IE7 provided alot of meat in we-know-who’s mouth, fridge and family, especially since they had the nerve to announce that this would be the latest version, after which no more new CSS stuff to be implemented…

Just our luck (AGAIN) a bunck of good guys humped the problem until thei made it squeak, and found a new solution; modify ONLY the CSS, and ONLY the CLEARFIX section, as follows:

.clearfix:after {content:"."; display:block; height:0;
                 clear:both; visibility:hidden; }
.clearfix       {display:inline-block;}
/* Hide from IE Mac */
.clearfix       {display:block;}
/* End hide from IE Mac */

Once redefined, this piece of CSS code made it all come back to normal, working in all browsers. Good job, guys, thank you for saving me from lots of senseless sweats!

If you ever tried to get an 1px; border on a table, in HTML, you probably wrote this: < table border = ” 1 ” bordercolor = ” #000000 ” > etc. But see it in a browser and it’ll show 2px borders instead. WHY? Simple, if you come to think about it: because, when defining the 1px border, it applies to both the table and it’s cells (by means of inheritance), and the 2 borders adding up always result in disurbing, thick, 2px borders. To better understand how this happens, suffice it to give the table acellspacing=”5″ – only then will you see how, in fact, the border was 1px thick… The 2 cases look like this:

Still, what to do, if CSS isn’t at hand and you still want that fine 1px border? Use this little trick:

< table cellspacing = ” 1 ” bgcolor = ” #000000 ” > … and then give all the cells a white background-color. This way, with no table-border but with an 1px spacing, the spacing WILL BECOME the 1px border you wanted in the first place.

Any modern browser (implicitely excluding all versions of IE), if is playing by the CSS book, has support for the dynamic pseudo-class “:hover” on ALL tags, not just on the lonely sad pathetic < a >.

Note: As you may already know, in CSS there’s a series of dynamic pseudo-classes (:hover, :active si :focus) that traditionally get associated with “a” in order to create different styles for the 3 possible different states of a link, as in a:hover, for instance.

Modern browsers, as I was saying, having implemented the support for this, allow for the association of the pseudo-classes with any HTML tag. In other words, you could very well define something like:

td       {background-color: #cccccc;}
td:hover {background-color: #336699;}

which would result in a background-color change on those td-s, on roll-over, without any need whatsoever to use HTML-bloating javascript code.

Pretty neat, huh? It’s an excellent feature, supported now even by the overly-and-yet-not-enough-booed IE7. Only the older IEs still go around butt-naked… So my recommendation is that you follow both the tutorial and the linked examples in a _modern_ browser.

Well, moving on with the tutorial, let’s see just what could we use this pretty thing for: Let’s imagine for a minute that we want to keep an HTML element hidden, making it visible only when we mouse-hover it’s parent. It’s an overly-known scenario for anybody who ever tried to build menus with sub-menus. To give you an example, I’ll just go back to a < li > case:

<ul id="menu">
  <li><a href="#">Element 1</a></li>
  <li><a href="#">Element 2</a></li>
  <li><a href="#">Element 3</a></li>
</ul>

This would be a classical, simple menu (I gave it an “id” for a simple reason: to be able to better controll the way in which to apply the CSSs later – in other words, if I have multiple ULs in the document and I want to restrict the behaviors to only THIS one, then I just restrict from the very begining how I apply the redefinition of the ULs and LIs in the CSS).

Let’s say we want to enrigh it a bit wit some second-level elements, by means of – yes, again – < ul > with < li > -s:

<ul id="menu">
  <li><a href="#">Element 1</a>
    <ul>
      <li><a href="#">Sub-element 1</a></li>
      <li><a href="#">Sub-element 2</a></li>
      <li><a href="#">Sub-element 3</a></li>
    </ul>
  </li>
  <li><a href="#">Element 1</a>
    <ul>
      <li><a href="#">Sub-element 1</a></li>
      <li><a href="#">Sub-element 2</a></li>
      <li><a href="#">Sub-element 3</a></li>
    </ul>
  </li>
  <li><a href="#">Element 1</a>
    <ul>
      <li><a href="#">Sub-element 1</a></li>
      <li><a href="#">Sub-element 2</a></li>
      <li><a href="#">Sub-element 3</a></li>
    </ul>
  </li>
</ul>

(You can check out what we’ve got so far, here).
Let’s try and style it a bit, now! First of all I’ll want any < ul > found in the < ul > marked by the id=”menu” to be hidden:

#menu ul {display: none;}

Note: Why use, for display, the valuenone and not hidden? Because any HTML element has two inherent properties: the visibility and the occupied space. While hidden only affects the visibility (like a sort of transparency: you can’t see the object, byt the space it occupied remains fermly on position), none affects both properties, both hiding the object and freeing up the space it occupied.

Now that I’ve hidden the secondary menus, I want it to get back when I mouse-hover it’s containing < li >:

li:hover ul {display: block;}

(in other words: any UL found in a mouse-hovered LI will be displayed as a block)
As you can see here, we haven’t solved much, although logic tells you we should’ve.

WHY: every CSS rule has a precise importance, that you can calculate simply by counting the elements that define it. And every element has in turn a predefined value, depending on what kind of element it is. A simple node (.my_class for instance) values 1, a pseudo-class (a :hover for instance) values 10, and an id (#class_x for instance) values 100. (wow that’s a lot of theory right there! )

Now if we count the 2 rules above, for the first one we have #menu ul (100+1=101) and for the second one we have li:hover ul (10+1=11). From this simple math you can now understand how come that a “more general” rule can be out-smarted by a “more private” one, even when logics and common-sense tell you the opposite. What can be done? Simply: increase the “value” of the second rule:

#menu li:hover ul {display: block;}

Now we have #menu li:hover ul (100+10+1=111>101), which solves the problem (see the result here).

If we further add some more styling to spice things up a bit,

#menu   {width: 10em;}
ul      {margin: 0px; padding: 0px;}
ul ul   {padding-left: 10px;}
li      {list-style-type: none;}
#menu a {display: block; margin: 0; padding: 2px 3px;}
a       {background-color: #CCCCCC; text-decoration: none;
        font-family: Verdana; font-size: 11px;}
a:hover {background-color: #EAEAEA;}

we get something that really starts to look like a menu. And all this, WITHOUT ANY JAVASCRIPT, with a simple, clean code that, when needed, degrades gracefully, clearly and in a structured manner in any more limited browser, so it’s easy to use in virtually any environment. From here on (for this example) your imagination in making it look pretty is the only limit.

IE5/6?

These two retarded browsers won’t EVER understand what we’ve been talking about so far. It’s by sheer dumb luck that the gentlemen at M$ allowed us to redefine the way some HTML tags work by using sets of rules in .htc files. Since this is a completely different story, I’m just going to send you reading what others, wiser guys, have to say about this, here, that’s IF you have the patience I HAD. The Bottom-line is that the guys from the above link have programmed such an .htc file that suits our :hover needs like a glove, emulating for IE5/6 around 99% from :hover‘s behaviour..

In order to make our example work in IE5/6, you’ll just have to download the file from here and to save it in the same folder with the CSS file, then to use conditional comments to force IE (and not only it) to “read” some extra stuff, like so:

<!--[if IE]>
<style type="text/css" media="screen">
body          {behavior: url(csshover.htc); font-size: 100%;}
</style>
<![endif]-->

(we’re just teaching the “body” tag to play by the behavior: url(csshover.htc); rules) Since IE will be the only one to understand this crap, other browsers won’t be affected and we’ll have gotten exactly what we came for. And, since all thiss crap is inside a comment, it will validate just fine which will work for us again.

Clearly, the list of cross-browser compatibility problems doesn’t stop here… So both IE7 and IE5/6 will just mess up our menu, if we tray to make it look at least decent.

The way around this? Yet another “hack” from M$ – the possibility to create CSS definitions conditionally, depending on the detected browser. After some tweaking I got the following set of conditional rule, both for IE7 and for IE5/6:

<!--[if IE]>
<style type="text/css" media="screen">
body        {behavior: url(csshover.htc);}
#menu ul li {float: left; width: 100%;}
li          {border-bottom: solid 1px #CCCCCC; margin-bottom: -1px;}
</style>
<![endif]-->

<!--[if gte IE 7]>
<style type="text/css" media="screen">
#menu ul li {float: none;}
li          {border-bottom: none 0px; margin-bottom: -4px;}
</style>
<![endif]-->

The final file can be seen here.
For inspiration, read what I have read too.

{ empty-cells: show }

This will force all the empty cells to SHOW the border, even if empty. (the other possible values for this property are: hide and inherit)

Acid Test 2