Way back in the day, you could customize scrollbars in IE (5.5) with non-standard CSS properties like scrollbar-base-color which you would use on the element that scrolls (like the ) and do totally rad things. IE dropped that.

These days, customizing scrollbars is back, but it's WebKit this time. It's a bit better now, because the properties are vendor-prefixed (e.g. ::-webkit-scrollbar) and use the "Shadow DOM". This has been around for a couple of years. David Hyatt blogged it in early 2009 and put together an example page of just about every combination of scrollbar possibilities you could ever want.

- https://css-tricks.com/custom-scrollbars-in-webkit/

Came across this one today. A DOM element had CSS3 border-radius: and box-shadow: attributes applied to it. Worked perfectly in everything except good old Internet Explorer, specifically IE9.

Turns out the reason for my ugly looking border-radius: and box-shadow: effect (instead of my nice smooth, anti-aliased shadowed corners) was because a legacy filter: dropshadow(color=#e0e0e0, offx=0, offy=1); attribute had been applied to affect/hack the newer CSS3 text-shadow: attribute for IE8.

Turns out, as of IE9, most of the filter: attribute methods on MSDN are officially deprecated.

Simply removing this attribute and replacing it with the newer, CSS3 standards based, text-shadow: attribute corrected my hideous looking, black rounded corners/box shadow effect in IE9.

Not sure if anyone else is looking to solve this, but hope it helps in some way.

OK; this was another one of those WTF-CSS moments after spending a couple of hours scratching heads trying anything and everything.

A website currently in production; we're doing some X-browser testing and a very odd scenario kept occurring in IE7 only. The website looked beautiful in everything except IE7 (usually it's IE6 we're cursing at). For some reason DOM elements kept 'vanishing' even though they were there!, there in the HTML. We thought we were going mad!

A cursory glance at the 'vanishing' elements in the IE Developer Toolbar > DOM Inspector highlighted their "hasLayout" property, and it's "-1" value (not set) which led me to a solution, but I'm still scratching my head as to why!?

Firstly the solution in-case anyone has Google'd looking for the same answer:
For IE7 ONLY, to make your vanishing elements magically re-appear, applying ONE (or more) of the following properties to the 'vanishing' elements will force those DOM elements to have a "hasLayout" value of "1" (true), in affect forcing them to render. HOWEVER in typical Microsoft fashion some of these CSS attributes have UNIQUE values that really do not stick to any x-browser standard. (Typical M$! *evil*).

• display:inline-block
• height:{any value}
• float:left (or) right
• position: absolute
• width: {any value}
• -ms-writing-mode: tb-rl
• zoom: {any value}

Secondly, the theory for anyone interested:
From what I can make out; and I'll probably add to this as I found out more, but from what I can make out, under a given set of circumstances absolutely positioned elements near floated elements will 'cause them to 'disappear'. This article (http://www.brunildo.org/test/IE_raf3.html) exploring this scenario led me to another article (http://msdn.microsoft.com/en-us/library/ms533776%28VS.85%29.aspx) at the Microsoft Developer Network (MSDN) and ultimately a solution. By forcing hasLayout to 1 you're telling IE that this element hasLayout, has form, shape and substance. In other words don't hide the damn thing! I'd definitely welcome any comments as to WHY this happens because it's one of those incidents where the solution works but you don't quite understand the underlying principals behind it.