Display table in IE7

[Chris Ramsay]

I have noticed that the CSS display:table attribute is not supported by
IE7 - is there a workaround/hack for this?

 

[Chris Ramsay]

I have noticed that the CSS display:table attribute is not supported by
IE7 - is there a workaround/hack for this?

Actually, I have just discovered this:

height: 1%;
display: block;

As found here: http://archivist.incutio.com/viewlist/css-discuss/69930

 

[Bergamot]

Chris Ramsay wrote:

height: 1%;

Be advised that this will have different results in IE6 (and prior
versions) from other browsers, including IE7.

IE7 respects the height property the same as other browsers. IE6 does
not, but treats it as min-height. All bets are off if your DOCTYPE
triggers quirks mode, but you shouldn't be doing that anyway.

Try using zoom:1 instead of the height property. It's a proprietary MS
property and usually gives the same results, plus it does not negatively
affect other browsers.

 

[Michael Fesser]

..oO(Bergamot)

Be advised that this will have different results in IE6 (and prior
versions) from other browsers, including IE7.

That's where conditional comments come in handy.

Try using zoom:1 instead of the height property. It's a proprietary MS
property and usually gives the same results, plus it does not negatively
affect other browsers.

The stylesheet won't be standards-compliant anymore. With a CC you can
easily include an IE-only stylesheet without tainting the others.

Micha

 

[Bergamot]

.oO(Bergamot)


The stylesheet won't be standards-compliant anymore.

So what? Passing validation is a worthy goal, but is not the be-all and
end-all. There is nothing wrong with using proprietary properties if you
know what you are doing. That's not in the same category as exploiting
parsing errors, if that's what you're thinking.

BTW, how would you get gecko to use its version of display:inline-block
without using -moz properties or values? That is another case to use
proprietary rules, so it's not just IE.

With a CC you can
easily include an IE-only stylesheet without tainting the others.

You'd rather taint the HTML on all pages with IE-specific bloat? :-\

I would rather add a few bytes to one CSS file than several lines in
every HTML file, plus have the overhead of downloading an additional
file on top of that. But that's just me.

 

[Spartanicus]

So what? Passing validation is a worthy goal, but is not the be-all and
end-all. There is nothing wrong with using proprietary properties if you
know what you are doing. That's not in the same category as exploiting
parsing errors, if that's what you're thinking.

I'd go further, validation is only a tool that may be of some help to
beginners to discover basic syntax errors. But there is no intrinsic
value in CSS that "validates". Most competent developers never check
their CSS with a syntax checker, ergo nothing is lost by their code not
passing a dumb bot check.

 

[Bergamot]

validation is only a tool that may be of some help to
beginners to discover basic syntax errors.

Beginners aren't the only ones that might benefit from that. The only
time I run my stylesheets through the validator these days is if I have
a rendering problem and can't find the cause right away. The validator
is handy for finding things like colons that should be semi-colons and
other typos.

 

[Michael Fesser]

..oO(Bergamot)

You'd rather taint the HTML on all pages with IE-specific bloat? :-\

In this case yes, because I usually need some more fixes for IE.
I can also use the same CC to include an IE-specific JavaScript.
I consider that an ugly, but acceptable way.

Micha

 

[Spartanicus]

Beginners aren't the only ones that might benefit from that. The only
time I run my stylesheets through the validator these days is if I have
a rendering problem and can't find the cause right away. The validator
is handy for finding things like colons that should be semi-colons and
other typos.

When I have a typo I am alerted to it by some CSS not working in my
browser, from what doesn't work a developer should know exactly where to
look in his code.

A CSS checker bot is useless for things like specificity issues, for
that there are tools like the DOM inspector.

CSS syntax checker bots have very limited uses, even if the errors
and/or messages they do and do not produce are correct and/or
appropriate, and don't confuse people (all of which they to often do). A
CSS checker bot is certainly not something that should be appeased.

 

[Bergamot]

from what doesn't work a developer should know exactly where to
look in his code.

If you look at something for too long, you stop seeing it. Maybe that
doesn't happen to you, but it does to me, at least now and then.

 

[dorayme]

I'd go further, validation is only a tool that may be of some help to
beginners to discover basic syntax errors. But there is no intrinsic
value in CSS that "validates". Most competent developers never check
their CSS with a syntax checker, ergo nothing is lost by their code not
passing a dumb bot check.

Still, if one is using iCab and the little face (a brilliant
little invention of the browser maker) is not smiling, it would
be unlikely that the hardiest and experienced developer would not
want to click it and at least take a peek at what is causing such
unhappiness...