IE7 line-height refuses to work

HTML & CSS
1

Hi all,

To simplify the code and cut out a lot of the same I basically have something like this:

<div id=“featured”>

<div id=“featured-nav”>

<a href=“#” id=“left” class=“activeSlide”>

<img src=“images/car_deals.png” width=“110” height=“75” alt=“get the best car deals” />

<h6>Whatever your chosen make or model, we have a deal right for you</h6>

</a>

</div>

</div>

#featured {
width: 1144px;
height: 480px;
overflow: hidden;
margin: 0 8px -10px 8px;
}

#featured-nav a {
height: 82px;
float: left;
cursor: pointer;
display: block;
padding: 20px 10px 0px 130px;
line-height: 18px;
text-transform: uppercase;
text-decoration: none;
text-align: center;
}

This is part of an auto-slider on the index page. The <h6>'s get pasted over background images making up a silder button selector.

Since most <h6> are pretty long and each slider button is only about 150px they extend over multiple lines (i.e. 2 or 3).

All browsers meaning IE8, Chrome, Firefox, Opera, Safari, Flock do the rightful thing of rendering a line-height of 18px. All but not IE7.

I’ve researched this online and it seems to be one of those IE7 bugs. A bug as it may be I’ve yet to find a way of forcing IE7 to give in.

The only DIV around the “featured-nav” DIV is the “featured” DIV but this doesn’t seem to be interfering any. This is proven by the fact that all browsers except IE7 change behaviour when I amend line-height: in “featured-nav”. They do exactly as they’re told.

IE7 is just entirely ignorant to whatever line-height: I try and give it.

IE7 doesn’t like percentages, okay it gets em, doesn’t like em, gets px but doesn’t take note either.

It’s not a show stopper but would be nice to fix, especially as it’s on the index page.

Thanks many,

2

Not sure if this has anything to do with it, but unless you are using HTML5, you shouldn’t have the <h6> inside the <a> element. It would be better to have the <h6> on the outside of the image and link. Have you tried to apply the line-height directly to the <h6>? And really, it’s rarely if ever worth using an h6. Headings have meaning. Might be better just to use a <p> with style.

3

Hi,

The code you posted (although invalid as Ralph points out) doesn’t exhibit the problems you mention. Do you have a link to an online version (or full html css)?

It’s likely an easy fix as there should be no real problem with this.

4

Thanks for your response.

Unfortunately I don’t yet have an online version, was hoping to fix it all up on localhost before uploading it.

It’s just IE7 that’s the culprit, did you test with IE7 and if so what version? I’m using IETester 0.4.4 on this end.

On mine with a line-height set as 18px, in IE7 it looks more like 27px, i.e. 50% wider (taller) than in all other major browsers.

Perhaps there’s some padding creeping in there somewhere, hmmm.

5

I’ve found why it does it in IE7. Sadly I know why but somehow I feel fixing this won’t be pleasant.

The h6’s are cufon-ted via
Cufon.replace(‘h6’, { fontFamily: ‘DejaVu Sans Condensed’ });

As soon as I disable that IE7 works fine -/+ 2px or so (hardly visible).

I’ve also just tried a different truetype font (Umbrage) and it appears to work better in IE7 than DejaVu Sans Condensed.

Ahh the joy hey. Even fonts cause problems when least expected.

6

At least you know where the problem lies now. :slight_smile:

7

Web font technologies are a total disaster, particularly when one uses some crap javascript (NOT a fan of cufon) to do the job of four lines of CSS. Between the scripting for nothing and bloating out the page load, much less the delayed ‘snap’ of the layout into place as the CSS gets delayed waiting for the Font – I say if you REALLY ‘need’ a particular font, you’re in the wrong business :wink:

But the block level tag inside the inline-level one and other coding decisions are likely just as guilty here – especially since given the text that doesn’t look like it should even BE a heading, though I’d have to see the whole page to be sure. That it’s a h6 either means a page that’s too good for it’s own good, or you’re skipping heading levels which is pitching accessibility in the trash while at it.

Though the thing that’s really sending up warning flags for me is you violate one of my personal rules for making my CSS – never declare a height on the same element you declare padding… admittedly that’s because I still design with some IE5.x graceful degradation built in – but it also seems to just make life easier across all designs.

Also, I question if that double-div is even neccessary – though again, I’d have to see the whole page to make that determination; It APPEARS though that you have multiple div’s for nothing, id’s for what should be classes (like #left), presentational classnames (like #left), classes for no good reason (.activeSlide – lemme guess scripting hook doing CSS’ job?) etc, etc…

Even more so, you realize you are declaring a line-height, but where’s your font-size? IE7/earlier won’t let an element go shorter than the font-size while other browsers will, so if after you load that font it’s larger than the line-height, the line-height will be ignored. (Just part of why if I set a line-height I ALWAYS declare font-size at the same time!). Also, since you set the line-height on the anchor it’s going to get overridden by whatever the default for the h6 is – and is going to cause problems for your 75px tall image!

Also, the inline-level next to the block-level can have spacing wierdness, so I’d be sure the img is set to display:block;

I have the feeling that you’ve overcomplicated something simple and are using heading tags for no good reason and/or incorrectly.

8

Some valid points, thanks.

As for IE5.5, I don’t see support IE6 anymore, if Google say enough is enough with rewriting code just for some more conservatives folks out there (likely with older computers) then so can I.

With jquery I just find IE7 is the lowest one should go really. IE5.5 and IE6 is slow anyway, visibly slower than IE7 which is by modern standards slow anyway.

We need to move forwards, evolve, modern pages need more processing prowess.

The Cufont effect is granted a delay on page init but in modern browsers the delay is 1-2 seconds, providing it’s run on a modern computer (i.e. Core 2 Duo). I find Safari and Opera are the fastest. I think it’s got something to do with the browser’s rendering engine, namely how well they’ve multi-threaded it.

I’m in the process or tidying up the code, lots of id’s have become classes. Since the #left is only used on the index page once I just left it as an id.

.activeSlide just informs the jquery which feature is shown first, hence which button is pressed under it.

9

much less the delayed ‘snap’ of the layout into place as the CSS gets delayed waiting for the Font

Depends on the browser, unless Cufon specifically throws in a default font until the other font can get loaded. (wait, I have DejaVu Sans Condensed… wow, OP’s giving a Linux font to Winblows users?? hahahahha that’s awesome)
Some browsers show no text until they have a font, while others show a system default until they have the font.

With jquery I just find IE7 is the lowest one should go really. IE5.5 and IE6 is slow anyway, visibly slower than IE7 which is by modern standards slow anyway.

We need to move forwards, evolve, modern pages need more processing prowess.

Careful there. If your site is an intense web application for high-powered rich folks and pampered gamer kids sitting with expensive equipment and ADSL in their parents’ basements, yeah, you’ll drop IE6 and make a bunch of assumptions of your target group to give them the experience you want to give them.

But MOST websites are just websites. It’s true, developers do what childless couples do in McMansions: we fill the space without thinking. I get a new fast fancy computer with phat-cable super-snel download capabilities, I start assuming everyone else does internet that way except maybe grandpa with his Windows 98. But it’s not so.

I have a poor view of jQuery plugins as most of the ones I’ve had to touch either needed extensive help just to get accessible (do jQuery people know what a keyboard is?? .slider for example) or someone else has modified greatly to make it accessible (which I like much better because I’m lazy… example <–they even have ARIA junk in there!). Make sure your site works with plain, valid markup, does all the stuff it has to do, and test in all browsers and other user agents (mobile users don’t haz teh mice, etc).

Then layer the java-junk, funkmaster fonts and the 1terabyte gradient images or whatever on top of that. A site that looks really cool but takes more than 10 seconds to load is a site I’ve probably left before it finished. Users do that. Speed matters. The higher someone’s connection, the less time they are willing to wait… though this also means those with crappy connections are willing to wait longer because they always do.

As a developer you are allowed to kiss IE6 users goodbye. It’s your site. Some people even forget IE altogether because they are aiming for web developers, who tend to use slightly more awesome browsers. But restrain yourself from requiring everyone has dual-core processing, lawlz.

The Cufont effect is granted a delay on page init but in modern browsers the delay is 1-2 seconds, providing it’s run on a modern computer (i.e. Core 2 Duo).

What do you want for people using anything other than a modern desktop browser? Do people use phones in your country? (In my country they are used all the time for Internet, but I noticed much much less of this when I was last in the US for instance)