IE 7 / Quirks Mode and Background color? - css

This is going to be a vague and obscure question, which is probably due to the fact that even using IE Web Developer, I have no idea what is going on.
I have a utility which I am working on. It's mostly JavaScript, and it has a small floating DIV user interface that shows up on a page. So far, standard stuff. The problem is the background color of some DIVs in the UI. The colors are assigned by CSS, and (tired refrain:) it looks fine in Firefox, Chrome, and Opera, but of course IE is being difficult.
The background does not show up in IE in quirks mode or IE7 mode, but it does in IE8 mode. For the life of me, I can't seem to figure out why IE7 isn't showing the background.
The page you can see the offending code is here: Log Hound Demo. Floating DIV is in the upper-right-hand corner - click the "V" to open it up.
Looking at that page in IE and then in [any other browser on the planet] will show you the missing background colors easily enough. I swear, even Lynx renders it better... ahem. The offending DIV IDs are lhPlateHead, lhPlateCtrlPanel,lhPlateTagPanel - easy to find with Firebug at least. They should be heeding the .lhPlateColor class with a background color of #DFEAF8, but that color is never applied.
With IE web developer up, I tried removing the CSS classes and re-adding them. I tried every combination of browser and document mode - again, only IE8 browser mode in IE8 document mode had the background colors working.
If anyone is bored enough to take a look and figure something out, I'd be much obliged.

Well - I finally figured it out, and as far as I'm concerned, this is another reason IE will always suck.
The circumstances of the problem are:
You are creating an element programatically:
myelmt = document.createElement('DIV')
You are setting the styles of that element programatically:
myelmt.setAttribute('class', 'myclass');
You are then adding that element programatically to the DOM:
body.appendChild(myelmt);
You are using IE.
IE hates you.
In cases such as this, IE8 will honour the "myclass" css and style the element properly when it is added to the DOM. IE7 and I'm guessing below will blow off the CSS styling and leave you thinking that employment at McDonald's is probably a whole lot less stressful.
To recap for the impatient:
Works in IE8 and EVERY OTHER BROWSER ON THE PLANET
var myelmt= document.createElement('DIV');
myelmt.setAttribute('class', 'myclass');
body.appendChild(myelmt);
Works in IE7 and below:
var myelmt= document.createElement('DIV');
var attr = document.createAttribute('class');
attr.value = 'myclass';
myelmt.setAttributeNode(attr);
body.appendChild(myelmt);
If someone can expound on exactly why this is a problem for IE7, feel free as I revel in the minutiae. Otherwise, just remember that it's all fun and games until someone loses an object reference.

Try adding zoom:1 to whatever element the background color doesn't work on.

I believe the issue has to do with how IE paints table cells. Try putting in a IE only CSS rule that applies the background color explicitly to TD's. Like this:
.lhWarnMsg .logMsg td
{
* background-color: #fbffbf;
}
Hopefully that will work for you.

Related

Positioning of divs off in Firefox/Camino?

So, I have written out a site in HTML and CSS, and all looked fine and dandy in Safari, Chrome, OmniWeb... even Opera. Then I tested in Firefox and Camino (which I believe uses the same rendering engine as Firefox) and was unpleasantly surprised: some of the positioning of my divs was off - noticeably off - by at least 5 pixels. While that might not seem like a whole lot, I use divs to put borders around things that I would otherwise have difficulty with putting borders around (jquery image gallery, for example), so 5 pixels matters quite a bit.
My question is this - what other quirks does Firefox's rendering engine put in, and how can I get around them? Are there special properties I need to add to my CSS in order to make it behave the same for Firefox/Camino?
Thanks in advance for the help!
You should look into using a css reset, this will give you a blank slate and will for the most part normalize how browsers render the box model.
I recommend http://developer.yahoo.com/yui/reset/

Buttons with equal line-height in ALL browsers

I've been searching for answers, but unfortunately still havn't found one the right one..
I'm creating buttons using images and the button itself looks good in ALL browsers..
The thing is though that the text is placed differently (vertically) depending on which browser you are viewing it from. I've tried applying both line-height, padding/margin, top/bottom and several other attributes, but without success..
Isn't there a way (with CSS) to place the text correctly in all browsers? (Opera, Firefox, Chrome, Safari)... Don't worry about Internet Explorer - I'll apply some speciel CSS for this!
I've put up an example here to play around with: http://jsfiddle.net/GydjP/1/
button::-moz-focus-inner {border:0;padding:0;margin:0;}
and adding Line-height to the buttons is apparently the best solution I can find for my buttons so far.. It doesnt work in very old versions of Firefox + Chrome though

CSS - Div background color becomes transparent, IE8 --

I'm now building a website for my sister. It looks normal on Chrome, firefox and IE9 but for some reasons, some of my div lost all background color in IE 7 --.
http://xx3004.kodingen.com/JDProperties
Open the website and you can see the pop up message has problem with title and button set (background color) - I'm using IE 7 right now. Then the content of the left body lost background color too, and the right column lost background too. I've been doing many searches on Google plus I notice that jQueryUI could not be wrong, so I guess it's because of my DOCTYPE in the begining of the source code. I've tried to change to some other DOCTYPE I saw on the Internet, or even omit it, but the website becomes either messing up or remains the same.
This is the first time I see this situation, it's weird and I hope I don't know how to fix it.
I'm expecting to solve the problems soon :-). Thanks everyone in advanced.
[x]
I started to look, and then saw this
</head>
<body>
</body>
</html>
</head>
<body>..
Try building the structure properly and see what happens yo.
You have mismatched HTML tags. Chrome, firefox and IE9 are cleaning up for you, but IE7 isn't that nice.
Agree with #albert, you do need to recode that page, although it's seeming to mostly working, the nesting of multiple head, body, style elements going to lead to trouble, and I suggest you change to an HTML4 Doctype as the coding is not XHTML, the more conflicts (tag soup) a browser has to deal with the more likely you will get them interpreting your intentions differently.
As for the IE backgrounds in numerous (inline styles) places you have background: inherit IE does not understand the "inherit" value of properties - or more specifically for IE7 and earlier it only applied "inherit to the direction and visibility properties

Why is my CSS tool tip not functioning properly in Google Chrome, but fine in Firefox?

http://betawww.helpcurenow.org/media/press/
You'll see I have used spans within an anchor, with the span.hover-description set to display:none; by default, and on a:hover that span is set to display block and absolutely positioned to create a tool-tip effect when hovering over the name and email of the "For Immediate Release" contact names.
Everything looks as desired in Firefox, but Chrome reveals my unknown blunder somewhere.
Any help on what's the problem that is causing Chrome to not display like Firefox?
Incidentally, Explorer shows the tool tip as expected, although I'm getting a funky bottom margin issue below the names, and Safari has the same issue as Chrome (must be a webkit rendering setting that I need to accommodate for).
OK, I figured it out. Since I'm using a pretty complex nesting structure to accomplish the CSS tool-tips, I overlooked the fact that I had actually nested a p tag within a p, and of course that is a no-no.
Firefox is really friendly to a lot of validation errors, but Chrome and Safari seem to be much more strict.
In the end I changed the p's to span elements and all is well across browsers.

What's wrong with IE?

I fall into an IE bug that I don't find a way to solve
Here's the template http://codecanyon.net/item/tquery-dynamic-tables/full_screen_preview/89478
If you open with Firefox or Chrome, the table header shows correctly, no BLACK, if you use IE7 or IE8, it shows some black space. Why? I tried to change padding, margin... but that didn't work, the black space is still glued. How can I fix such bugs?
Please also, explain what tools, or methods can help fix this bug
Update: Bug Fixed!
The reason is that IE gives an arbitrary size/padding/margin to the img element when the src is undefined.
When the src attribute is defined dynamically through JavaScript, this doesn't correct it. It still undefined, so it doesn't solve the problem.
Solution: Fix a height/width for the image.
The sort image you have in the cells still takes up space - in this case, the space used by IE's default "invalid image" placeholder, because you left the src attribute empty. You can verify this using Developer Tools, and setting the height to 1 pixel.
The problem is that visibility: hidden doesn't mean "don't use any space" - it means "claim the space, but don't show anything there". Use display: none instead if you don't want it to take up any space.
You may still wonder "But why didn't I see this anywhere else?" Well, that's due to the other browsers handling the missing image differently.
One tool that can help is the IE Developer Toolbar, which wil let you look at individual elements and the CSS applied to them. Looking quickly at the real page, not the link you sent (because the IE toolbar can't go through IFRAMEs for some reason), the one thing that pops out is the TD and TH elements in your table head show hasLayout: -1. It's a custom IE property that causes all sorts of bugs. You can read about it here. A couple of quick fixes you can try: apply 'zoom: 1;' or 'position: relative;' to those elements to see if it goes way. That's not a fix, it's a hack, but it often works.

Resources