Summary of IE Hacks?

[deko]

As I understand it, IE7 is still not standards compliant (although it has
cleaned up some bugs). Can anyone point me to a summary of IE bugs and fixes?
I've recently discovered Conditional Comments, which are supposed to be a
reliable solution, such as this:

<!--[if IE]>
<link rel="stylesheet " type="text/css" href="iestyle.c ss" />
<![endif]-->

This looks like a good way to go - that is, just use a separate stylesheet for
IE - but that begs the question of how to fix particular problems in IE. Is
there a good summary of IE quirks and workarounds someone can point me to?

Thanks in advance.

[Jobe]

>Gus wrote:

>Write it and make sure it's as you want it in Fx and *then* check in IE.

I know a lot of people in this discussions do defend the fact that good
browsers should support validated code.
We all know that FF is doing this. We all know that IE6 is a nightmare.

But if you are a professional designer, making a living out of this,
and paying bread and butter...we should respect the fact that IE has 80
% of the market.

Bill was able to take the market and to keep it. Neither FF, Linux,
Opera or Netscape was able to take it away.

If we play tennis we have to accept the rules. If we want to play in
the world wide business we have to accept the rules.

So it makes much more sence to develop in IE, and check if it works in
FF.

br

Johan

www.web-garden.Be
--
deko wrote:

So, maintaining an IE-specific stylesheet like this:

<!--[if IE]>
<link rel="stylesheet " type="text/css" href="iestyle.c ss" />
<![endif]-->

is, IMHO, the cleanest and most effective way to manage the display
peculiarities of IE. An iestyle.css can contain every hack and workaround to
accommodate each IE version (all the way back to IE 5), all cordoned off the
side, where they belong.

Do you mean something like this

/* Hacks for all IE - including IE7 */

... {}
... {}
... {}

/* Hacks for IE6 and before */

* html ... {}
* html ... {}
* html ... {}

/* Continuing with hacks for IE5.5 and below */

and so on...

yep.

If so, I like the approach - better than having lots of sets of conditional
comments. Might use that in the future if I need to hack IE7 and IE6
differently (although I will probably ignore IE<6 - it tricky to test, and I
don't think quite so important).

Yeah, I don't see much IE 5 anymore...

This approach seems like the best solution to me. Still waiting to hear what
others think...

[Andy Dingley]

Jobe wrote:

Gus wrote:
Write it and make sure it's as you want it in Fx and *then* check in IE.

I know a lot of people in this discussions do defend the fact that good
browsers should support validated code.
We all know that FF is doing this. We all know that IE6 is a nightmare.

This is a logical fallacy.

The axioms are:
* Some competent people advocate validation.
* Many sites are invalid.
* It's difficult to make sites work presentation-wise between IE and FF
* Many sites display well in IE, but not in others.

It's a fallacy to take these observations and extend them to your
conclusion, which appears to be that IE _requires_ invalid code.

Valid code works everywhere, equally well. Invalid code works
variably. _This_ is why validation is good, not because it's a magical
route to good display, but because it's a route to _consistent_
display. From consistency you can achieve good design, but you can't
take a good but invalid design and make it consistent, except by going
in circles.

we should respect the fact that IE has 80 % of the market.

A false argument.

* Who is advocating ignoring IE ? No one.
* Why do you put forward the fallacy that valid code is in some way
damaging to IE?

There's also the well-known observation in software development that it
takes just as much effort to support equally complex features needed by
100% of the market and by 1% of the market. You either do it or you
don't. Once you've done it, any number of users can use it. It doesn't
become either easier or harder just because more or less of your market
care about it.

Bill was able to take the market and to keep it.

It took several years (1997 - 2001) for IE to take the market away from
Netscape. IE is far from invulnerable as the Windows browser of choice.
They're lost and abandoned the other non-Windows markets for IE on Mac
and UNIX already. FF has some tens of % of their core Windows market
already.

Neither FF, Linux,
Opera or Netscape was able to take it away.

I wasn't aware that "Linux" was a web browser.

If we play tennis we have to accept the rules. If we want to play in
the world wide business we have to accept the rules.

Do you have any other meaningless aphorisms you'd like to share?

So it makes much more sence to develop in IE, and check if it works in
FF.

Where did _that_ little non sequitur come from ?

It's wrong, it's obviously wrong, it's empirically wrong and it's not
supported by any of your argument so far.

Developing valid code is easier and quicker (to an acceptable level of
"complete") than developing invalid code. This is a truism for FF in
isolation, for IE in isolation, and most certainly for "the web"
(meaning approximately all likely browsers). In no possible way is
there a tangible benefit for travelling the rocky IE road first.

[Bergamot]

Jobe wrote:

>
So it makes much more sence to develop in IE, and check if it works in
FF.

No, it actually makes more sense to check both as you go.

I used to check IE last, but it was too much trouble dealing with its
many quirks after the fact. There were a couple instances where I had to
make some major adjustments to work around IE flaws, so it made more
work rather than less.

Now I usually have a gecko browser and IE side by side as I go, and
check them both for every revision of the stylesheet. A big monitor
helps. :) At a certain point I'll check it in Opera and a KHTML browser,
but if it works in gecko, the others aren't usually much different.

--
Berg

[Gus Richter]

Bergamot wrote:

Jobe wrote:

>So it makes much more sence to develop in IE, and check if it works in
FF.

No, it actually makes more sense to check both as you go.

I used to check IE last, but it was too much trouble dealing with its
many quirks after the fact. There were a couple instances where I had to
make some major adjustments to work around IE flaws, so it made more
work rather than less.

Now I usually have a gecko browser and IE side by side as I go, and
check them both for every revision of the stylesheet. A big monitor
helps. :) At a certain point I'll check it in Opera and a KHTML browser,
but if it works in gecko, the others aren't usually much different.

The point is that you check what you did in Fx first, then in IE and if
done in a compliant way, most of the time IE will also handle it right.
If done in a non-compliant IE-proprietory way, which IE will tolerate,
then all the compliant browsers will puke on your work. If checking in
IE first, then the potential exists to write in a non-compliant and
IE-proprietory way, making the cure more difficult than eliminating the
cause at first.

Of course if you have a lengthy complex document/site, then it does not
make any sense to finish the whole thing, checking it only for Fx and
then afterward check it for IE. It only makes sense to check
periodically with IE and find the problems as you go instead of
diagnosing afterward, which may be time consuming. Awareness of the
possible problem points may also be worthwhile. Check as frequently as
you think fit, *but first in Fx* and *then in IE*.

--
Gus

[deko]

>>So it makes much more sence to develop in IE, and check if it works in

>>FF.

No, it actually makes more sense to check both as you go.

What I do is develop in FF first, then create a separate stylesheet for IE --
using Conditional Comments in the <headto direct IE users to it -- and then
make whatever IE display adjustments (hacks) are needed in the IE stylesheet.

Why FF first? Because we have agreed on standards -- and FF is, mostly,
standards-compliant. The merit of the software is irrelevant. IE may be the
browser of choice for vast majority of my users (this helps justify the decision
for a separate IE stylesheet) but that doesn't matter one bit unless we all
agree on a set of standards to define how to code for it. We cannot communicate
(even with a popular person) if we do not agree on grammar.

[dorayme]

In article <4p************ @individual.net >,
Bergamot <be******@visi. comwrote:

Now I usually have a gecko browser and IE side by side as I go, and
check them both for every revision of the stylesheet. A big monitor
helps.

or 2 monitors...

(I am new to these groups and I am going to making quick darting
telling little interventions as I see fit so as to build a big
solid reputation and gain huge respect...)

--
dorayme

[Andy Dingley]

deko wrote:

What I do is develop in FF first, then create a separate stylesheet for IE --
using Conditional Comments in the <headto direct IE users to it -- and then
make whatever IE display adjustments (hacks) are needed in the IE stylesheet.

So what are these hacks?

I only know of _one_ hack that it's useful to include for an IE only
stylesheet (fixing the default font size smaller than 100%, to
compromise for hi-res Windows displays with large fonts selcted)

Anyone got any others?