Slashdot Mirror

Hello margins my old friend.

They do however show that it IS possible for other browsers to support features that MS have invented, features that (many of them) actually make things better.

Yes, but a lot of them make life harder, and a lot of IE's quirks are just plain buggy. The point is that the web should be cross-platform: you have a standard and you code to it. Vendors should not have to implement features invented by a third party that may or may not be properly documented (ooxml anyone?). This is why we have the W3C to develop and innovate standards. Hell, MS helped write a lot of the standards that they don't implement.

Basically, whatever platform you're used to programming for, be it mozilla or ie, the other one IS going to seem alien to you, and stuff is frustratingly not gonna work on it.

A browser is not a platform. It should implement the standard so that we can code to it... "write once, run anywhere" should not be a paradigm reserved for Java.

But for you, the one you hate is IE rather than FF, which can only lead to the conclusion that IT'S SUBJECTIVE!

It is not subjective. There is a standard. While no browser implements it fully, IE is (still) the worst.

They do however show that it IS possible for other browsers to support features that MS have invented, features that (many of them) actually make things better.

Yes, but a lot of them make life harder, and a lot of IE's quirks are just plain buggy. The point is that the web should be cross-platform: you have a standard and you code to it. Vendors should not have to implement features invented by a third party that may or may not be properly documented (ooxml anyone?). This is why we have the W3C to develop and innovate standards. Hell, MS helped write a lot of the standards that they don't implement.

Basically, whatever platform you're used to programming for, be it mozilla or ie, the other one IS going to seem alien to you, and stuff is frustratingly not gonna work on it.

A browser is not a platform. It should implement the standard so that we can code to it... "write once, run anywhere" should not be a paradigm reserved for Java.

But for you, the one you hate is IE rather than FF, which can only lead to the conclusion that IT'S SUBJECTIVE!

It is not subjective. There is a standard. While no browser implements it fully, IE is (still) the worst.

To repeat what Archon-X said in another part of this thread:

Tell me why you'd possibly need 32 style tags in a HTML document?

to which I'll add "You're doing it wrong!"

IE does make it more difficult for web developers, but this is a terrible example as to why. Position is Everything has an entire list of valid reasons; the style tag limit isn't on that list for a reason.

I can easily set up a three-column layout without tables. It's not that hard as people make it out to be (especially considering that people have already set everything up* for you), and it produces cleaner code than a table-based solution.

* Unfortunately, the Holy Grail layout has an annoying IE bug. Here's a fix.

I can easily set up a three-column layout without tables. It's not that hard as people make it out to be (especially considering that people have already set everything up* for you), and it produces cleaner code than a table-based solution.

* Unfortunately, the Holy Grail layout has an annoying IE bug. Here's a fix.

Yeah, get back to me when Opera fixes this CSS bug that is over five years old.

As such, Opera can't do uneven-width 'sliding doors' tabs that extend to fill a container, which is what we needed recently. Some might call that an isolated bug, but honestly - a CSS1 rendering bug should not survive this long, while they're implementing more advanced and newer features.

My regret is that (both the) Opera users who visit our site think we've failed to use web standards when really it's -- gasp! -- Opera's fault.

It's just too bad that Microsoft didn't learn this lesson. With their browser safely at 90%+ market share and no real competitors in sight, they stopped development (except for bug fixes, of course).

And only bug fixes that they considered critical -- security, crashers, etc. Nothing that would have fixed rendering bugs. And I don't just mean spec violations, I mean outright bugs that would make content disappear. When they did IE7, they combed the net looking for descriptions of known rendering bugs so they could fix them.

You build for Firefox, Opera, Safari, or something else that supports standards

Last time I checked, none of these browsers are 100% compliant on most W3C standards.

Yeah, and nobody's perfect, so we should all be killed. Kidding aside, standards support is not a binary property, and I shouldn't have to point out that there's a world of difference between something that's 95% correct and something that's 5% correct.

IE7 is far more standards compliant than IE6, so I would think if you're truly worried about standards compliance in Internet Explorer, you'd welcome the upgrade.

...and 35% is a much greater percentage than 10%! IE7 is still much worse on standards than pretty much any other browser worth mentioning. The fact that IE7 still manages to be that much better than IE6 should simply give you an indication of how bad IE6 is (it's very very bad). So, while it would be nice if IE6 never existed and they skipped straight to IE7 in 2000 or so, that's not what happened, and now we're stuck with adding in a whole new host of workarounds for IE7, because it still doesn't render pages correctly a non-trivial amount of the time, provided that you want to support IE at all.

On the opposite end of the scale, I can develop a page in Konqueror (which is very standards compliant), and then check it in Firefox and Opera, and not end up needing to make any changes, because everything works the same. Checking in IE will almost certainly result in IE producing something largely wrong, but at least IE6 is a relatively known commodity, with a well known set of workarounds. IE7 on the other hand is still largely undiscovered. Given Microsoft's past and the fact that they have no reason to produce a browser that doesn't suck, don't be surprised when people treat a new release of IE with scorn.

Not supporting IE at all is, without a doubt, the easiest approach. Supporting IE6 but not IE7 is still easier than supporting both IE6 and IE7. Supporting IE7 but not IE6 probably won't be feasible for most people for several years yet.

Firefox is the closest, but Opera and Safari are in no way better than IE when it comes to implementing standards.

I don't really test in Opera, but limited experience shows that to compare it to IE is no less insulting than comparing Firefox to IE. Konqueror (and presumably Safari, given that it was forked from Konqueror (or rather, KHTML)) is generally better about standards than Firefox, and unquestionably better than IE. Firefox is compatible with more pages on the general Internet than Konqueror, because it tries to emulate a lot of IE quirkiness, but that doesn't push it any closer to following standards.

So how do I create a tabular layout for non-tabular data without using a table? Say, two columns - nav sidebar and main content area - having equal, but liquid height (let's say I'd like the column borders to line up)?

There are ways to do that (example 1, example 2, example 3, example 4, and so on). Some are hackier than others, each one has its own set of quirks and restrictions, but then table-layouts have their own issues and drawbacks as well.

They'd be no secret about what I'd be doing if I was running the Internet Explorer 8 team. Here's a few things I'd do:

1. Turn everything on this page that is red to green for the Trident engine.
2. Fix everything on this page.
3. Correctly support the mime-type for XHTML and display an error if *anything* on that page is incorrectly formed. The last part of this sentence is absolutely crucial. We need to start breaking pages that are not correct, XHTML is a good chance to push this.
4. Get rid of the Trusted Site, Internet, Untrusted security model and just have Untrusted.
5. Get rid of ActiveX. Support Internet Explorer 6 for ActiveX for another five years to allow people to transition to other platforms.

For bonus points, do all this faster and with less memory than Internet Explorer 7 takes.

This is a fairly modest list but if they fixed all of that, Internet Explorer would be a joy to develop against. Hell, I might even consider replacing Firefox as my default browser on Windows. However, as much as we can collectively dream, you know they'll rejig the interface slightly, crank up the version number by one and call it a day.

Microsoft is a text-book example of a market failure. Nearly every other browser has Internet Explorer boxed off in terms of functionality, security and speed. The only reason it is the world's number one browser is because it comes pre-installed with WIndows.

As a program Internet Explorer is simply trash. I simply hate it. Actually I fucking despise it. It is a big ball of shit. It's the ugly building in the middle of a city that everyone wants torn down but it just sits there damaging the community's spirit.

I once joked with a colleague that Internet Explorer has probably wiped billions off pounds off the world economy. I laughed, paused for a moment, and realised it's probably completely true. What could the world have done with all those countless hours hacking their CSS to support the trash that is Internet Explorer?

Doesn't it make you depressed?

Simon

Well they had to.. The abuse of IE 6 bugs in the star-html selectors is so heavy that pages would break each time the IE 7 team fixed a bug. Standard-compliant web pages are filled with hacks like these:

* html ... { height: 1%; }

Do you really want that to be rendered at 1% in IE 7? That's what your code really states, and it's what IE 7 will render because they fixed the expanding box problem. That bug is abused heavily to enforce containment for the floats in IE 6, since IE 6 magically enlarges the box if is too small.

I haven't had any real problems when the star-html parser bug was removed. IE 7 renders almost everything like Firefox because Microsoft fixed most of the bugs. There is one thing that I did have problems with, which is missing support for :after. This is typically used to enforce containment for standard-compliant browsers.

Fortunately, there is a simple way to work arround that problem. A min-height of 0 will also trigger "hasLayout", and cause the box to contain all floats. So a nice way to clear floats without structural markup becomes:

#header:after { /* Standard compliant browsers supporting CSS 2 */
content: ".";
display: block;
clear: both;
visibility: hidden;
height: 0;
}

* html #header { height: 1px; } /* IE 6 */
*+html #header { min-height: 0; } /* IE 7 */

Yes, and note the *+html selector. :-)

Very good, but not 100% correct: adding the IE version number to the title bar is so *you* can keep the versions apart, but the Windows feature called "process specific subroutine library" is what makes the IE stand-alones, well, stand alone. Read more about it here, and get prepackaged IE stand-alones here.

Now I have IE6 stand alone next to normally-installed IE7, and really the only difference is that IE6 can't use ActiveX plug-ins. Unfortunately that doesn't help when you have a layout heavy with transparent PNGs and are trying to fix it for IE6 :-)

It's a known bug with IE5/6 that they don't display PNG images correctly. I'd found the info on this page to be useful in regards to CSS hacks. You might need to use conditional comments to point to a non-PNG image. Gotta love Microsoft standards compliance.

Using JS for something like this is a bad idea. Thanks to CNet's JavaScript hysteria (see below), more and more people seem to be turning JS off these days.

Better solution: use the IE-only conditional comments feature to show one type of input element to IE, but the image input to everyone else. Done properly, your markup will even still validate despite the proprietary cruft. (because the cruft just looks like comments to the validator and every sane browser on the planet)

That's if this is actually an issue.

References

CNet tells how JavaScript will eat your babies: http://snipurl.com/16u4z

Conditional comments: http://snipurl.com/16u5j

Complex selections with conditional comments: This is totally cool and absolutely invaluable. Look toward the bottom of this article -- http://www.positioniseverything.net/articles/multi IE.html

I'll give you a very depressing example. Everyone knows about the well-documented IE CSS bugs on Position is everything. A pain they are, but with sufficient hours of slaving away you can hack-around or workaround them, because they are known problems.

But nearly every project, I run into some mysterious *new* IE bug that takes hours to figure out. Here's my favorite example.

Circa 2004, I'm working on the site for Ecliptic Enterprises when I discover that the drop-down navigator menu doesn't work on all the pages. On the staff profile / resume pages, mousing over the menu does not cause it to drop down. It works on all the other pages.

But those menus are defined in an external file that is included on every page. So why would they work on some pages, but not the others? I check several times to make sure that the php code is rendering the menus identically on every page. diff confirms that the HTML, css, and javascript for the menus are 100% identical on all pages. So obviously (I think), some weird interaction with the page's content is breaking the javascript.

I begin systematically removing blocks of HTML trying to find what is breaking the menus on these specific pages. I remove each block, reload to see if the problem is fixed, diff the PHP outputs to check what I've done, replace the block, move on to the next block. I get to the end of the file and nothing has fixed the problem. So I try it over again from the beginning, removing code blocks and NOT replacing them before going on to the next.

After quite some time, I have stripped these pages down to zero content -- just the menus and other nav structure that is common to all pages. Yet the menus still won't function! I strip the remaining common parts of the page until there is nothing but a bare menu in my test file -- it still doesn't work! But the menus work happily on ~50 other pages on the site! About four hours have gone by.

By now I have so many copies of the page (dozens) that I am losing track of what I've tried in what order. profile_test001.php. profile_test002.php profile_whatthehellisgoingonhere.php. Eventually I copy the original page to an entirely different name to start anew. That copy, apparently identical to the original ... works just fine. I start to think I am losing my mind. I have been at this for five hours. I must have copied a different file than I thought. I try it again, using fresh copy of the file from backup. Menus don't work. I copy it to a different file name. Now the menus work. I really am losing my mind.

But no, after testing for an hour, I come to this bizarre, but inescapable conclusion:
if the filename of the webpage contains the string "profile", the drop-menus do not work in IE6. And no, the javascript does not examine the URL or any part of it in any way.

I rename all of the resume pages from "profile_.php" to "bio_.php". Suddenly the drop-menus on those pages work again in IE. My problem is fixed.

That's right, a sensitivity to the filename caused a javascript fault that broke my menus.

You can see it yourself, the files are still around. Boot up IE6, and visit the two following pages. They are bytewise identical, differing only in the filename. You can diff them to check:

http://www.eclipticenterprises.com/bio_ridenoure.p hp (menus work)
http://www.eclipticenterprises.com/profile_ridenou re2.php (menus break)

This bug, which I have never bothered to characterize further, cost me almost an entire workday. And in my experience, that kind of crap is absolutely typical of IE and has plagued me in every web project.

I haven't tested it in IE7. My windo

Indeed. That comment was so unfair, one might almost think the OP was a Microsoft-hater. They fixed *ALL* the worst bugs in IE6, listening to people like positioniseverything who've been cataloguing them for years, and don't seem to have created too many new ones.

Not an IE7 fan, particularly, just a truth-pedant.

Check out http://www.positioniseverything.net/ for the latest hoops you need to jump through for IE

IE7 and FF2, I have to say its really no contest. Despite just plain hating how much vertical real estate the new tab toolbar takes up, performance with IE 7 is just horrible. Even a light page like the Google home page take about about half second longer to render on my Core 2 Duo machine. Let's not forget only really giving lip service to CSS standards, there is still going to be a ton of web pages that need hacks or workarounds for IE CSS issues. Check out http://www.positioniseverything.net/ for the latest hoops you need to jump through for IE. In no means is Firefox perfect in its CSS support but at least they respond to incompatibilities in a reasonable time frame.

I tryied surfing through some demos at www.positioniseverything.net

So, what can i say ? Many bugs realyl are not seen anymore, but...

They told they fixed most of them in that blog, for example they told they fixed the "italic fonts" bug... Did they ?

Italic bug consists of two parts:
    1) with italic font, text becomes a bit wider, especially with letters like "g" in the beginning and letters like "t" at the end. IE 4=5=6, following its usual habit, expands the box to fit the font. IE7 does not expand the box, instead text is correcty written outside the box.
    2) with non-italic font IE just does not renders text outside the box, it just crops it. Both IE 4-5-6 and IE7

http://positioniseverything.net/explorer/sidepages /IEt_fps.html

It seems, those Indian guys been told "fix this!", then they looked at the title, said "a-ha! Italics..." and paid absolutely no attention to non-italic font.

I wonder, if IE7 just contains all those CSS/HTML well-known hack-arounds built inside its guts :-)))

PS: what is everyone silent about that 1st IE7 bug, so funny "found" by Secunia and so funny denied by Microsoft IE7 team ? :-)
"She made a fuss, they made apologies, but everybody though the show was funny" :-)

Why would they when other people are already doing that

The wonderful folks at PositionIsEverything have resolved those problems. It's a pain in the royal ass to fix but definitely possible.

Since browser compliance testing is something I do when I build websites I'll need these instructions when I (unwillingly but necessarily) install IE7 on my machine. I have not done so yet because I don't want to test IE7 until it is essentially complete. No point in coding for a bug that will disappear on final release.

• A List Apart
• Position is Everything
• CSS Beauty
• css Zen Garden

• Be prepared to abandon hope of absolute pixel-level control over everything. Seriously, if you want that, go into print design, that's not how the web works.
• (Sometimes this one works as an OR to the above point...) Fix the box model by adding an extra non-semantic div. Simple as that. Voila, no more broken box model, but no invalid CSS full of Tantek hacks either. I don't know why more webdesigners are so against this. Banging on about favouring standards, yet they'd rather deliberately break (invalidate) their own CSS than add a single non-semantic wrapper div? I never quite grasped that. The broken IE box model is responsible for the vast majority of places where pixel-accurate control breaks down between IE and, well, the rest. Of course, it doesn't help fix your 3-pixel jog (for example), but it certainly cuts out the biggest offenders.
• Be prepared to lose a few bells and whistles - for example, no :hover pseudoclass on arbitrary elements. So you can't have table cells that change color as you mouseover. This is pure candy though, so I'm prepared to "not support" IE in this regard. The overall layout/style is exactly the same, so it's not like I'm making IE degrade to "plain, unformatted hypertext" as you suggest - just they miss a few tiny "cherry on top" effects.
• (Again this is a bit of an OR to the previous point) - use javascript. For example, get the effect of arbitrary :hover by using suckerfish javascript techniques.

Web developers can use conditional comments to target a specific version of IE, and here is an article that goes into the details of what hacks are "supported" by IE7.

Supporting IE7 will require some extra work by webdevs, but it's doable even if code already contains hacks for previous versions of IE.

You know what you were told to do, and you know what you were told not to do. I think that meeting went something like...

"Firefox is making people realize that IE is crap, we need to do some damage control. We need a new version of IE."

"OK."

"Plus, Longhorn is a good enough reason to upgrade IE, right? Add IE7 to the list of Vista-only features... On second thought, since we don't know when Longhorn will ship, we better be prepared with a build for XP, but only for Service Pack 2."

"OK."

"We'll completely reconfigure the security model, that'll drive Administrators nuts, haha!"

"HA!"

"Security improvements are top priority. Exploits for IE are coming out almost weekly, and the patch team can't keep up."

"Yessir."

"But those damn developers have been whining for standards compliance for years now. Let's throw them a bone or two. What can we fix to shut them up for a while?"

"Well, there's a lot we don't have right, sir... PNG transparency, various RFC violations, real XML support, our CSS could really use a major overhaul--"

"Alright, let's give 'em PNG transparency. Most people seemed to buy the bullshit we've been stalling with for this."

"Yessir."

"But most of the compliance complaints I hear about have to do with this CSS thing. Apparently there's this site called, um... Position Is Everything dot net that has better documentation of these CSS bugs than our internal tools."

"Yessir."

"I dunno, pick 10 or so that'll take the least amount of time to fix, but that we can make the biggest deal about. Try to pick the ones with names, and make the developers rue the day they asked for standards compliance in IE."

"Yessir."

"But remember, only spend about 10% of your time on compliance. There's a new security model to develop before it goes to retail for testing, and we might as well make the user interface of the new IE completely different from the other browsers... so if anyone switches from IE, they won't be able to figure out how to use Firefox. Move the buttons around or something."

"Yessir. But won't a new UI confuse the people still using IE6?"

"They'll just have to get used to it. Now get to work."

Now, almost 2 years later, we get to see the results, and the numbers don't lie. Sorry, Chris, we know a mandated token effort when we see one.

>
> It would seem more logical to me if standards reflected how
> the most prevalent browser rendered things, and designers
> designed around THOSE parameters.
>

Did you ever coded a website in CSS? (I mean, really using no tables, and using at least one floated block, like for the main menu...). Important features of CSS are "missing", basic ones are bugged to death... I mean, check websites like http://www.positioniseverything.net/ :/ They are full of bugs like you cannot even conceive they might be involuntary, and even less that they have not been corrected in like 7 years... For a webmaster, building clean, accessible websites, without tables, is hell... You can't do any tight design (by tight, I mean like a 3/4 pixels error is ugly), without wasting hours correcting stupid problems Microsoft is perfectly aware of for years and years... (if they didn't introduced them voluntarily... -I mean, anyone in the business knows about MS practices about standards...).

>
> Are any of you in the habit of testing your CSS docs
> for strict compliance, then complain when it doesn't
> render properly, then change it? No..you just know what
> will work (unless you are a newb) and write that way.
>

I code for strict compliance, because I want my code to work on other browsers than IE. After I coded everything, I waste a day or two on adding compatibility stylesheets (and maybe even JavaScript), and try to correct bugs, for my website to look somewhat ok under IE. This is not just a matter of learning the Microsoft's variant of CSS... this is a matter of learning dozens of bugs and dozens of lack of features, and the way to workaround these problems...

>
> Just remember the rest of the world probably isn't with you.
>

Yeah, it's been quite a few years already I understood this. If we are only talking about websites, "the rest of the world" mostly have inaccessible websites, webpages twice or thrice the weight of my webpages (because of presentational markup inducing huge code redundancy), unmaintainable websites (try to change something other than correcting typos, in a website using tables for everything), websites which probably won't work in ten years (yeah, you can always build a new website... it's just more costly), websites which need to restart from zero, if you want to change the design, etc.

It's still a bit hard on me, but I'm quite content with "the rest of the world not being with me" (and we aonly talked about websites... don't get me started on politics, philosophy, sports, games, other parts of computer systems, etc.).

You stil doubts me? check the original article:

>
> One of the things I said in my post is that I think
> it's very difficult, if not impossible, to have an
> analysis of exactly where we are as a number with
> supporting or complying with CSS - given that there
> isn't an official test suite that exhaustively tests
> whether you comply with the standard or not. And any
> analysis you can do is going to be somewhat biased.
>

I mean, is this guy for real? They don't know where they are? Dozens of websites, if not more, list every single part of the CSS which is supported, not supported, or buggy, in Microsoft Internet Explorer, 4, 5.0, 5.5, 6, and soon, 7. These people just read the CSS recommandations, candidates, drafts, etc., and just tested if if worked or not (and this is done for other browsers too).

Is anyone here, believing that Microsoft cannot do that, if they really were so inconscious about the functionnality supported by *their* browser?

They coded it, and they don't know what they support, and do not support?

They need official test suites? Why? The W3C papers are generally quite clears... if there is part Microsoft (who participate in most W3C ativities, being an important member) does not understand, they just nee

From Chris' Blog...

... Solid test cases we can access and bug reporting would help which is why we have a public bug database....

Last I heard IE7 does not fix the Expanding Box Bug?

This is a troublesome bug when you're populating DIV tags with generated data. You don't even have to be doing anything advanced.

Microsoft knows about the Position Is Everything Explorer bug list. I've seen IE engineers mention it on their blogs. So I don't buy the "we don't know of specific bugs" routine. And if he wants more concrete bug reports after that set, then theres the Comparison of Layout Engines page which goes through the CSS specs in detail. I'm sure Micrsoft has fixed a bunch of those since IE6, but there are outstanding issues in IE7.

Most software engineers would pay large sums of money to have that type of detail in bug reports. Microsoft is getting that for free, but he is complaining that he does not have solid cases.

From Chris' Blog...

... Solid test cases we can access and bug reporting would help which is why we have a public bug database....

Last I heard IE7 does not fix the Expanding Box Bug?

This is a troublesome bug when you're populating DIV tags with generated data. You don't even have to be doing anything advanced.

Microsoft knows about the Position Is Everything Explorer bug list. I've seen IE engineers mention it on their blogs. So I don't buy the "we don't know of specific bugs" routine. And if he wants more concrete bug reports after that set, then theres the Comparison of Layout Engines page which goes through the CSS specs in detail. I'm sure Micrsoft has fixed a bunch of those since IE6, but there are outstanding issues in IE7.

Most software engineers would pay large sums of money to have that type of detail in bug reports. Microsoft is getting that for free, but he is complaining that he does not have solid cases.

Recently the Microsoft blog told us that some of our CSS hacks will stop working in IE7, a fact we detailed in our first IE7 article. While this is generally good news, it is a bit disturbing that the Holly hack in particular will cease to function while many of the layout problems it is meant to fix will still be there, and will still need fixing.

Well the good news is, they fixed most CSS2.1 bugs in IE7. They killed almost every bug mentioned at positioniseverything.net. They also added support for CSS2 selectors.

The bad news is they didn't add ":after" support..
If you used this to clear floats without structural markup, you need to find another way.

And worth mentioning:

• the new bugfixes are not applied in quirks-mode. Shouldn't be a problem, quirks mode is ment for backwards compatibility anyways.
• most of my pages rendered exactly like Firefox and Safari already did. In fact, if I left a "bug" there because it was only visible in Safari, it will likely be visible in IE7 too due their better support for standards.
• If you coded your pages for standards, and only used "* html" for IE5/6, most pages still look fine in IE7
• they removed the "* html" bug because it broke web sites since they also support of the child-selector (html>body) in IE7.
  Note that pages render fine now without this hack!
• they appear to have left a new hack, *>html, but they recommend conditional-comments instead

Well the good news is, they fixed most CSS2.1 bugs in IE7. They killed almost every bug mentioned at positioniseverything.net. They also added support for CSS2 selectors.

The bad news is they didn't add ":after" support..
If you used this to clear floats without structural markup, you need to find another way.

And worth mentioning:

• the new bugfixes are not applied in quirks-mode. Shouldn't be a problem, quirks mode is ment for backwards compatibility anyways.
• most of my pages rendered exactly like Firefox and Safari already did. In fact, if I left a "bug" there because it was only visible in Safari, it will likely be visible in IE7 too due their better support for standards.
• If you coded your pages for standards, and only used "* html" for IE5/6, most pages still look fine in IE7
• they removed the "* html" bug because it broke web sites since they also support of the child-selector (html>body) in IE7.
  Note that pages render fine now without this hack!
• they appear to have left a new hack, *>html, but they recommend conditional-comments instead

Instead of using some WYSIWYG editor I decided to strike it out on my own and write a page from scratch using the "standards" that the W3C touts.

Writing web pages following the standards is a good thing, but making a complex CSS layout work with some buggy browsers out there is hard. The solution is to not recreate the CSS from scratch, but starting from an already debugged existing layout.
E.g.:

1. http://css-discuss.incutio.com/?page=CssLayouts
2. http://www.dezwozhere.com/links.html
3. http://www.positioniseverything.net/articles/onetr uelayout/

Too many CSS web developers are trying to reinvent the wheel.

Oh, and there are of course the IE-specific CSS bugs to bear in mind too - http://www.positioniseverything.net/explorer.html

actually you can

That's funny, they claimed to have fixed a number of bugs.

Not that I'm pleased with IE, as they've fixed the Star-HTML Hack while other bugs not mentioned in the IE Blog still remain.

Position Is Everything features CSS bugs from all modern browsers, though it mainly focuses on IE.

Yeah, I'd like to thank Håkon for taking the time to answer my question, but it's not really the answer I was looking for.

position: fixed will stick a footer to the bottom of the viewport, but not to the bottom of a page (perhaps I am not using the correct terminology). That means that if the content is longer than the viewport, the footer will just overlap the content and stay put, while the content beneath it will continue to flow and scroll. What I meant was a footer that will always be at the bottom of a page "in dependance of the content" (as I mentioned). That means, it's at the bottom of a viewport until the content gets larger, which would then push down the footer accordingly. The lack of such a feature is the reason faux columns and hacks like the "One True Layout - Equal Height Columns" exist. I'm sure Håkon is very busy but perhaps he could spare a little more time to look at the examples I linked to in my initial question to get a picture of what exactly I am talking about.

The examples I mentioned work perfectly via tables without the browser knowing the exact height of a page. I know CSS works fundamentally differently but there must be a way to emulate the behavior?

How do you do a three-column layout, with the central column coming first in the markup, and all three columns the same height, without using tables?

By using the One True Layout method.

On the whole Table vs DIV thing...
Let me try to be more clear. If you are looking for the holy grail of web design, the three col layout without tables, you won't find a good, clean, and easy solution that has what I believe are good principles of design. Sites like the Slashdot front page can have 20%+ white space, once you scroll down, with a big monitor.

Sites that are badly designed because they don't use tables.
Example One... Three cols, no tables, but no footer. Try to put the footer on it, and it will float.
Example Two... Not really three cols... It's two, and the footer might float over the right hand side if the body isn't long enough, so it isn't used on comments, or any page that has user generated content that may not exist.
Example Three... Looks like three cols, and it is, with all divs, but it's 60% whitespace, because the body size is fixed. This is a case where you can have a nicer monitor, and the site would look worse. Again, its just not right.

It is silly to try to use divs where they don't fit. Use tables when appropriate. Using a table to float a picture in a paragraph would be silly. You would have extra cols every where, and it wouldn't render correctly. Using a div to float the picture is the right thing to do.

On not using the DOCTYPE
If you say it's Strict XHTML, it will use an XML parser, and browsers won't function alike. If you don't use the DOCTYPE statement, it punts the sites content to the HTML parser that will try to render most anything, and you will be less likely to get large differences in the way it renders in different browsers.

First: this is assuming "correctly" is not defined as "pixel perfect", which was not and is not the point of the web. I concede that in many real world situations, the client expects a pixel perfect recreation of a PSD they give you, in which case you may run into problems. Things like the 3 pixel jog will screw you over. But if by correctly you just mean "looks exactly the same so long as you don't literally measure pixels", it rapidly gets easier.

Broken box model? No problem. Just don't use padding, and use an extra internal div with margin instead. Yeah, the hardcore purists say will say "but that extra div isn't semantic". But... let's face it... your first div probably wasn't semantic, was it? Furthermore, what's better - one extra div, or an enormous maze of tables (the old school approach), or standards-busting deliberate CSS hackery (seemingly the preferred method of standards junkies, which always completely puzzled me. Let's just say I'm slightly smug now they're all sh*tting themselves trying to fix their deliberate CSS hacks in advance of IE7).

I think one extra div is no small price to pay and voila, box model is sorted.

I'd say there are pretty easy, non-standards-breaking workarounds for most of IE's quirks. If you MUST use alpha transparent PNGs then you'll be stuck. But if you're not bound by a designers' PSD it's not actually as bad as all that.

Well, the first question is (as I said), are you using the right box model? If not, width/padding/border will not work according to CSS rules.

http://msdn.microsoft.com/library/en-us/dnie60/htm l/cssenhancements.asp
http://css.maxdesign.com.au/listamatic/about-boxmo del.htm

If so, congrats! You've taken step 1 in dealing with IE and now width/padding/border/margin works for most cases. But it's still filled with all sorts of annoying bugs. Here's a really comprehensive list:

http://www.positioniseverything.net/explorer.html

And the W3C validator only checks for syntactical correctness and does not prove your page is rendering correctly or incorrectly.

I have one question for the IE team, if you ever care to ask: why is a 6+ year old bug with margin's on CSS floats still not fixed in IE 7?

Making IE secure as part of the OS is difficult, I'll grant that, but not impossible. Keeping IE up to date with other, more innovative and more nimble companies and foundations is difficult, but not impossible.

But for the one thing IE is really EXPECTED to do, render HTML, it does it sporadically, unreliably and dismally. I've been doing web development for over ten years now... why can IE just not seem to function in the standards department?

Anyways, that's just my short rant.

However, it is important to note that IE5 on Mac is more compliant than IE5 or IE6 on Windows, at least according to the Position is Everything Explorer page.

The following (which you are probably aware of, but others may not be) are good references on CSS/HTML/XHTML etc. which I came across whilst trying to work out why my standards compliant pages were so badly broken in IE6 -- it absolutely amazed me how much of the websites about CSS etc. are devoted to IE bugs and workarounds.

• PIE
• ALA
• (support pages for) the CSS Zen Garden

Cheers,
Mark

If Opera 9 has decent CSS support I might agree. Opera 8's CSS support was pretty crappy.

No offense... but WTF have you been smoking?

Opera 8 had pretty damn good CSS support. Well ahead of IE (but then what isn't these days) and comparable to Firefox and Safari. The problem is that no rendering engine today supports the *entire* spec, and each engine supports a slightly different subset.

To make up some numbers, Gecko 1.8 and Opera 8 might each support 90% of CSS2 specs, plus 5% of CSS3, but the subset of CSS2 covered by both browsers might be 85%, and the shared subset of CSS3 might be 2%.

Position Is Everything and How To Create have some nice examples showing errors or gaps in various browsers' support. There are techniques Opera gets right that Gecko doesn't alongside techniques that Gecko gets right that Opera doesn't.

Mostly bugs in alignment of elements it seems. The site I'm working on now is having a lot of issues with it and I've had similar issues on other sites I've done.

Have you looked around here and here to find out whether the issues you're seeing have explanations or workarounds?

Part of the problem is that every single site that offers user-agent statistics is in some way biased by its userbase. I really wish Yahoo and/or Google would publish user agent statistics; that would be probably as close to a proper sample of the world as you could get.

Right now, make sure you're turning on user-agent logging for your new site. Yes, the logs do waste some disk space, but they compress to nothing, and there's nothing better than seeing exactly what percentage of your users are using various browsers.

As an example, I made my life much easier when I stopped supporting IE 5.16 on Mac. There's a few very subtle differences between 5.16 and 5.17 when it comes to div's encosing other div's, and 5.16 rendering will break when every other browser is OK. I was able to end this nightmare when I showed my boss that he was the only user in the past six months who had accessed the site with IE 5.16 (which implies, of course, that every 5.16 rendering bug ended up at priority 1.)

And just a reminder that IE 7 is coming, with an, er, interesting collection of fixed bugs, maintained bugs, and removed hacks