Slashdot Mirror

This page on that site goes on and on about Quirks Mode, Almost Strict Mode (a unique-to-Mozilla beast), and Strict Mode. This page goes further and delineates how different browsers pick among those three modes.

If you always code Strict and never have to support a quirks-only browser, then lucky you!

Personally, there's a reason I never became a web developer and I keep my HTML simple. :-)

which follows Web standards pretty well

please read :

http://www.quirksmode.org/

I am familiar with strict mode and doctype switching, I develop webpages for a living.

There are two things wrong with this. First, take a look at http://www.quirksmode.org/css/quirksmode.html (this is me looking up doctype switching like you asked). See all the things that are still not the same cross browser after you enable strict mode? Second, even in strict mode, who says we're developing for IE 6 and above.

My main point is that you can't just say "Oh, I think I'll code this webpage using proper syntax this time" and get it right because sometime, back in the day, Microsoft built IE and said "You know what, maybe we'll just do it this way... screw what the w3c has to say." It's like running a java program on windows and having the instruction i++ be the same as i += 1.2

Next time the parent to this subthread tries to make an informed comment about something, they should think about it first. Just because you can write code doesn't mean you know the intricacies of HTML and that the same design decisions apply. HTML is not an exact language and is not the same cross platform/browser -- this is exactly why I'm changing jobs pretty soon.

This article on Opera's UA string should give the information you need.

But we don't encourage browser sniffing, object detection is a much better method to give the right content to browsers. Instead of "If your name is John cut my hair" do "If you're a hairdresser cut my hair".

If you do browser detection check for version number and be prepared that browser sniffing is a high maintenance technique. Browsers constantly change and every browser sniffing script will become obsolete, doing more harm than good in the long run.

heh.
Good riddance to that Bug ridden crash prone piece of junk

The memory leaks are inherent in the design of JavaScript, not MS' implementation: http://www.quirksmode.org/blog/archives/2005/02/ja vascript_memo.html.

Although I agree that IE7 will slow down the growth of firefox I doubt it will really diminish the current market share. Slightly better support for web features will cut a little bit out of the "it only works in IE" problem, and most of the new stuff in IE7 is in firefox, or a plugin. In the end a lack of new features combined with any possible previous bad IE experiences will keep the new FF users where they are.

In the future I see technologies like xul as "where things are going".(and yes microsoft has one too) HTML+Javascript is only going to get us so far, and although using the javascript to dynamically update pages can do some (comparatively) awesome things, it does not have the feel of a real solution to it. So if I were a web developer[1] I would start playing with these tools now to be ready in ~3-5 years when they become a preferable alternative.

[1] I am not a web developer. If you are one, and I sound like I don't know what I am talking about, that is probably because I don't.

Actually, for the record, you can run IE 4, 5.0, 5.5, 6.0, 6.eolas, and 7 all on one box....

check out QuirksMode Multiple IE

IE does understand and parse the XHTML doctype correctly.

You might want to do some research on why XHTML is over-hyped and can lead to future problems, because most web servers don't serve XHTML in the correct MIME type.

HTML4.01 is a standard too, ya know.

And yes, you can get IE6 to operate in STRICT mode (box type, etc.) if you supply the correct DOCTYPE. Further complicating things is the fact that Mozilla, Safari and Opera have an "almost standard" mode, which you can read about on the site I just linked.

For more information, check out QuirkMode's section on doctype and what it changes on the different browsers.

The designer of the flash application would have to supply all the features normally available in the browser - maybe you can get flash components that do this.

Part of my point was that you can't emulate the browser features properly - see my middle-clicking example.

By the way I have written DHTML code and it is *not* trivial the differences in the DOM between IE and Mozilla.

Well that's the DOM, not AJAX itself. While I agree that the differences can be quite annoying at times (although not at the 50% you claim), the majority of the API people actually use on a regular basis is fairly consistent between browsers, and work like IE7 etc etc increase conformity considerably.

Table of CSS support in various browsers: http://www.quirksmode.org/css

Has anyone mentioned http://www.quirksmode.org/?

More about conditional comments from quirksmode, and a clever usage of it.

Sounds like a great idea, if I have the time I'd love to. But one quick and dirty method is to go through http://www.quirksmode.org's list of css incompatibilities with IE 6 and see if they work. I know most don't have access to the beta, but yeah, maybe I can document.

Only 2 of the many CSS bugs have been resolved, no improvement in CSS implementation/support, no good debug tools.

Maybe try a IE Blog 'standards' search... even though they are pretty quiet about it, when they do say something it's pretty encouraging. Especially the fact that they link Quirksmode and Position Is Everything. If the IE Team fixes the bugs outlined there, a huge weight of debugging will be lifted from web designers (well, in like 7 years when everyone is finally upgraded :)

You're probably having trouble with addEventListener because IE doesn't support it. As always, there's a proprietary solution, but it doesn't support capturing/bubbling like the W3C solution does.

You can half-ass it in IE with the traditional model (element.onclick = function;), but, y'know, it's half-assed.

See here.

e.g., if you need to select DOM elements, see if the document.getElementById method exists, rather than checking for IE >= 5.

It's no use for sites using browser detection to send working CSS rules, though, since they need to work even if JavaScript is turned off.

But, the page would be perfectly valid

It would be perfectly valid, sure, but it wouldn't be perfectly valid XHTML. It would be a perfectly valid document in your own private markup language. Even PPK admits it. I can write a DTD that adds <marquee> to XHTML 1.1 - that doesn't mean documents using <marquee> are valid XHTML 1.1 documents.

We need support for input type="file"...

Try this.

"Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element.

Completely and utterly wrong.

Elements are nodes in the document tree. Tags are merely the delimiters that tell the parser where the elements begin and end. Don't believe me though, read the HTML 4.01 specification.

One example of something that fits your definition of "element" but doesn't fit the reality is an attribute. Attributes are objects in the document structure, but they are properties of elements, not elements themselves. And the HTML specification actually says "elements are not tags".

Basically, you are full of shit. Read the specifications. Learn a little about SGML. You are wrong and have resorted to name-calling ("trolly-wolly"? How old are you?) and inventing your own definitions instead of admitting you are wrong.

He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler.

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there. This makes your style of code unsuitable for generic scripts. The correct appropach is to use attachEvent and addEventListener. Some discussion of the brokenness of onclick assignment here.

Sure, in some situations it doesn't matter, but why bother with learning two ways of doing it when one way works fine all the time and your way breaks some of the time? Like I said, it's a stupid way of doing things.

If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards".

You're just making this shit up as you go along, aren't you? Compatibility with non-CSS user-agents is a design principle of CSS. Again, you are full of shit. Want more? The W3C, which published the CSS specifications, also published WCAG, which states Organize documents so they may be read without style sheets..

I've backed up my argument with links to explanations, hints on where to find more information, and authorative quotations from specifications. You've just blown a lot of hot air and called me names. Who's the real troll?

this styling trick for file input form elements impressed me much more than this:

http://www.quirksmode.org/dom/inputfile.html

oh how i hate the browse button!

Either you didn't try hard enough, or you didn't know enough

It's quite a hack to have an IFrame for this and all that. XmlHttpRequest is cleaner because you can read headers , set headers and even check on status code on return.

Read through quirksmode importing xml tutorial . Also anyway, only XmlHttpRequest lets you POST xml content to the webservice at the other end - not stupid old www-encoded form posts.

There is almost nothing that can't be done in any modern browser. What exactly do you mean by "dynamic"? Check out some of these sites.

A very similar approach can be found here: JavaScript Browser Detection. If you're running JavaScript, though, you can detect the browser more accurately using other techniques that don't rely on the user-agent header. The code gets pretty complicated, though.

If all you're interested in is a way to detect IE then you'll probably be interested in IE's Conditional Comments, which is really a horrible hack but it works...

The problem with doing things in JavaScript, of course, is that it's a client-side technique and it doesn't work if the browser's disabled JavaScript support.

> You can detect opera on the server just fine

Oh? Perhaps you can tell me what happens when you set an entry in ua.ini to 4 or 5?
http://www.scss.com.au/family/andrew/opera/browser ids

> And no, you don't need to test for browser or version ever, for any reason, period.

So I guess I shouldn't care that earlier versions of Opera don't support certain CSS parsing behavior
http://centricle.com/ref/css/filters/?whitebg

And I shouldn't care what improvements happen between versions of the same browser in case someone is using an older one
http://www.quirksmode.org/css/selector_attribute.h tml

And I shouldn't care when Firefox implements CSS3 and eventually deprecates/drops the -moz equivalents like -moz-box-sizing
http://www.blooberry.com/indexdot/css/properties/e xtensions/nsextensions.htm

Just because you don't think knowing the browser version is important doesn't mean that everyone thinks the way you do. Plenty of people care enough about it enough that there are plenty of client side version detectors out there
http://www.mozilla.org/docs/web-developer/sniffer/ browser_type.html

Perhaps, before calling us all idiots, you may want to offer an alternate solution that works.

> test "does this feature I want to use work"

It would be nice if I could do this, but the unfortunate reality is that CSS does not work this way.

Unfortunately, CSS capabilities are not testable from script in any browser. You can only rely on the browser version to determine what is or is not available. Getting it wrong might result in a minor cosmetic problem or a browser crash, or maybe a hang. It is cleaner instead to base CSS on the browser version.

This is a problem, yes. And it was made worse by not being able to rely on the user agent string.

CSS hacks were the result. eg.
http://www.albin.net/CSS/OwenHack.html

But CSS hacks are an ugly workaround and don't solve all your problems.
http://digital-web.com/articles/keep_css_simple/

The CSS hack approach seriously lacks elegance.
I believe that version detection is far more elegant by comparison
(providing you get the detailed version info - IE needs to report the service pack level).

Unfortunately, since the cat is already out of the bag (all the existing opera browser instances), relying on the user agent string will never truly be an airtight solution.

Perhaps instead, it would be easier and better to restore elegance to CSS. We just need to convince all the browser manufacturers to make the browser version truly testable in the CSS @media descriptor. Or maybe propose an @version descriptor.

I agree, PP Koch has definitely put in some hard work, quirksmode is a great resource.

fixed

http://quirksmode.org/

Amazing site, this guy has done some painstaking cross-browser testing for JavaScript, CSS and HTML and come back with compatibility tables and recommendations for everything from the basic box model (how browsers managed to fuck this up i don't know) to robust JavaScript that doesn't use crappy "if browser equals X" statements. Working with HTML/CSS and JS is highly painful if your project specifies that it must look _good_ in all browsers, so any tricks you can learn will save your life.

Seriously, you should give Firefox a try (or another try, as appropriate).

Good advice.

I was one of those "I'll just continue to use IE because it works on all websites" type of people. I used to assume that the people who used Mozilla, Firefox, and Opera were just the usual group of discordians using this as some silly way of striking out against Microsoft. After several debates on the issue with friends who had switched to FF, I finally decided to give FireFox a try.

At first I thought I'd use it alongside IE, but after a couple weeks I find that I am using FF exclusively -- now I only open IE when I need to confirm that my DHTML webapps work properly in IE as well as FF.

In fact, I've discovered that FF has much more useful debugging capabilities for JavaScript than IE, and QuirksMode makes it easy to write JS that works in both.

The tabs are nice, but what I really like most is the FlashBlock extension. It's a perfect way to manage those unstoppable Flash ads that are often so distracting it makes it impossible for me to read the text on the same page. And when I want to see a Flash element, I just click it, and it starts.

FF rocks. If you last tried it before 1.0, give it another go; you'll probably be pleasantly surprised. It renders most everything just fine now and it works perfectly with the secure websites I use (bank, brokerage, etc). Get the FlashBlock extension and enjoy the web again =)

AFAIK Javascript is not "standard free".
Javascript itself has been standardized by the ECMA as ECMA-262 (ECMAScript) ever since Netscape donated the language to said ECMA (even though ECMA's work blows and no one ever read the normative definition because it sucks donkey balls), and W3C's DOM and DOM Events have extensive documentations [u]including documentations on how you're supposed to implement ECMAScript bindings[/u].

And that's not to mention really good reference sites such as QuirksMode, which is pretty much a Javascript bible (only sound, logical and actually holding relevant information... not a bible at all after some more thought).

Now if we specifically consider GMail and Google maps, they're not using only standardized javascript, they're using a feature called XMLHttpRequest which isn't normalized (and isn't even Javascript everywhere, the only way to use XMLHttpRequest-ish code in MSIE is to create ActiveX objects), and about that very command your point (about the lack of normalization) stands true.

BTW Google Suggests also uses XMLHttpRequest

We have the same problem with javascript, only that is 10 times more disturbing because if javascript was actually the same all other the place web surfing could be enhanced so much. The only reason people don't like javascript is because the popups, and that's not everything in javascript.

• Popups, of course
• Stupid effects (shitty animated gifs following cursors anyone?)
• Messing with browsers (resizing, changing parts of the global UI, alert boxes)
• Code design so bad that browsers grind to a halt (oh, i so love seing my CPU usage skyrocket to 100% and stay there because i opened a bugged page)
• Slowing the browsing
• Disabling the browsing altogether because of non standard or stupid scripts (mmm, yummy Javascript links, I mean anchor tags are certainly not hip enough for a damn link are they?)
• Probably many other i can't think of right now

IE will (mysteriously) ignore the underscore prefix and parse the second style, while compliant browsers only recognize the min-height style.

If designers didn't rely on obscure parsing bugs like the one in your post, that wouldn't be a problem. There's nothing elegant or clever about exploiting parsing bugs to fix another bug. In an ideal world the browser developers would fix both the parsing bug and whatever other bug the parsing bug is designed to work around. Since we're never gauranteed of this, why take the risk? If you're a professional developer with past projects in the hundreds when IE7 hits the streets, can you then afford to turn back the clock and revisit most of them because you relied on parsing bugs, rather than more concrete methods. (Ahem, conditional comment style sheets) You'd be completely screwed. If you don't fix your client websites, your reputation will go the way of the dodo. If you do you'll have weeks upon weeks of unpaid work.

IE may have miserable CSS support, but at least it provides some very clear, built-in work-arounds for its problems. (JScript, behaviors, conditional comments, all that propreitary garbage that we can use to fabricate something resembling standards support).

But it's very very hard to sort through it all. Every so often I start playing with various features common to Mozillaish browsers like XPI, XSLT, and Javascript. It always strikes me how much potential there is to make some very cool applications using these. One pet project of mine is to see if I could create a set of XSLT documents that would transform glade projects into XUL applications, which could be themed via css.

The biggest impact Firefox will have on web development is it will increase the cost of entry into run-almost-anywhere scripted websites.

Note that I'm not saying this is bad or that there aren't good effects Firefox has (in fact, I believe it is a great browser). Just that the biggest impact on *development* is it will increase the cost of entry on scripted sites.

This may be a good or bad thing. When the web first started, it was possible to be an "HTML Expert" by doing layouts with tables. I kid you not. This was advanced at one time and people had to figure out how to do it.

With browsers having pretty much settled down (meaning that Microsoft stopped releasing new browsers and 90% market share belonged to Microsoft), the wealth of knowledge on HTML coding has grown considerably. It was hard to be an *expert* at HTML or Scripting because everyone had done it before. That said, there are some truly brilliant people at sites like QuirksMode.

Now I feel that the new direction that uber-coders are going for is *useful* DHTML scripting (also known as JavaScript, Cascading Style Sheets and the Document Object Model to manipulate HTML live). By useful, I don't mean a cursor with a trail of stars. I mean things like popup calendars for date selectors, rich text editors, GMail and WYSIWYG page editors with live previews.

DHTML is still hard and mostly poorly documented. Anybody who has made a rich text editor for MSIE knows that it isn't too bad anymore. There is more documentation on how to do it. Definitely not *a lot* but enough that you can find your way through it.

Try this though: Make an iframe window that simulates a regular window. Okay. Now do it so that is supports MSIE, FireFox and Safari. If you want to (eventually) support more than 75% of the market, you have to support FireFox now and I'd throw Safari on the list as it is the default browser (I think) on the Mac.

Some of the toughies are the event handlers for these browsers which are quite different. I've written code to make them both work with one code base but there is virtually no documentation on this. There are dozens of quirks not listed and the only way you can figure 'em out is through trial and error.

Okay, I know I haven't covered all my bases in making this argument, but I think the smarts you will need to be an uber-coder for DHTML just got harder. This is good because there is room for new experts. If you are a great coder, there is a chance to be a brilliant cross-browser DHTML coder. If you are strictly average (nothing wrong with that), your job may have got harder.

Ironically, code re-use on JavaScript seems to be very low.

By the way, if you need evidence that cross-browser DHTML is hard, it even took Google a while to get Firefox compatible with GMail. Think how much cash they've got.

Signing out...

I think the CSS working group are not focusing on CSS achieving it's full potential.

Take a look at the display properties

Why would anybody want to use display: inline-block. The article I link to says "The real use of this value is when you want to give an inline element a width. In some circumstances some browsers don't allow a width on a real inline element, but if you switch to display: inline-block you are allowed to set a width." How many times are people going to run into a situation to need this? The typical solution would be to have a

They keep on developing useless things like this, when they really should be focussing on making the stuff that everyone does super simple easy to do, and super clean.

For a long time I've been trying to get a list that will appear like a table. You can make a list set them to display as inline. It works, but then you can not set a width, which then makes it useless. It works in IE, but not firefox. Or you can do all the "HACKS" can you believe that people actually call it __HACKS__, which is to make them float:left. This works, except that if your elements text-wraps, and god forbid that they do, then your whole display gets messed up.

Again, useless.

CSS could be sooo damn good, it's so close to being so unbelievably good, except it falls flat on it's face.

Personally I agree with you. We should have css and html totally seperate. CSS is currently focusing on the elements of a layout. This is not full control of the layout which people keep on claiming it is. It is an improvement over plain old html. But they need to focus on elements and also the full layout.

Ideally I would imagine html being only used for grouping information. Then using CSS you can manipulate those groups of information into columns, lists, floating elements, etc, etc...

Let's get away from exploiting "hacks" until they become the standard way of doing something and make something that works from the start.

I would gladly write up a spec and make some illustrations, but I don't have the time to argue my ideas with the CSS working group, because I'm pretty sure most would disagree with me. Plus, I've already spent to much time on this subject.

Disclaimer: This is not a rant saying that microsoft is right in not using CSS2. If anything it's the opposite, we are so despeartely in need of standards across the board.

Actually, IE6 in strict mode, although still heinous, is reasonably good in terms of CSS. The box model is largely OK, although not entirely without faults. The floats model is still a bit buggered though, with various spurious margin bugs and soforth. Overall, IE6 in strict mode is sufficiently functional that cross-browser development is for the most part fairly straightforward, unlike IE6 in quirks mode, where the broken box model makes life hideously dificult.

If they can get strict mode cleaned up for IE7, sort out the doctype switching to allow for XML declarations, recognise the XHTML MIME type, and generally get the CSS implementation properly in line with CSS2.1, then things will be good.

I find it a little ironic that much of the CSS work has already been done within the Microsoft camp in the form of IE5 for the Mac, which in my experience has the most CSS2 compliant rendering engine of all the major browsers (excluding Opera, which I have practically no experience with). It's certainly the case that Gecko and KHTML lean much more towards the more practical CSS2.1, and sometimes oddities in CSS2 can actually spring the odd surprise in their manifestation within IE5 Mac.

Maybe they're using plain ol' HTML and CSS
And maybe it should thus work just fine regardless of which OS you use. Actually, no maybe involved there.

It's not "plain ol' HTML and CSS". They're also using JavaScript. And there are known minor differences in how browsers handle the DOM, which lead to different offset calculations for things like that drop-down menu.

• http://css-discuss.incutio.com/
• http://css.maxdesign.com.au/
• Layout-o-matic
• firdamatic
• http://www.quirksmode.org/index.html?/css/condcom. html
• http://www.devguru.com/Technologies/css/quickref/c ss_index.html
• CSS Quick Reference
• 181 Manually selected references

CSS is incredibly well documented, both officially and by its users.

Dealing with browser quirks takes nothing more than time and a little pit of patience. You have to set your goals of which browsers with which features, plan for graceful fallback, and test test test. Just like any trade with numerous and subtle exceptions, if you do it long enough it all becomes second nature and you find yourself writing CSS that not only validates, but looks right on every browser you desire.

CSS would be nowhere today if it had been an XML-based language. The spec is pretty well written and (numerous gotchas excepted) pretty well supprted, even by Microsoft.

Mozilla (Camaro, Firebird, whatever the hell they're calling themselves this week) just sucks compared to Safari.

You had me until here; Gecko (the Mozilla rendering engine) is generally regarded as the best rendering engine available. It's not the fastest, mind you, but it's the most developed with regards to web standards. Safari isn't far off, but some of it's quirks can get a bit annoying at times. Just ask Gmail users what they thought of Safari up until about 2 months ago.

As a web developer, I'm generally pretty happy with how Safari renders websites, but I really do wish that Apple had forked Gecko instead of KHTML. Given the popularity of Firefox, the Gecko engine has some serious momentum behind it from web developers; twiddling with a 3rd major rendering engine (KHTML) just adds to testing time. And at this point, Firefox and its brethren run as fast as Safari, even though they're not Cocoa applications.

I know that Apple wants to bring as many applications in house as possible, but as a Mac user, at this point I question the value of Apple continuing to sink resources into its own browser when a clearly equal if not superior peer product exists in Firefox (and even moreso after Firefox 1.1 with Mac-specific tweaks is released). Firefox isn't Cocoa, but not everything has to be, either.

And the Firefox developers aren't even trying to fix the bugs people want fixed.

Now, I'm not saying your pet enhancement-bug isn't important, just that the devs have decided it's not worth the amount of work at the moment. Remember that there are over 5000 open non-enhancement bugs on the firefox product only...

Also, the enhancement you're talking about is going to be very, very difficult to implement without breaking stuff. I'm 99% sure that it's not even possible to do it without breaking some valid web-pages with onload and onunload javascript (and no, Opera hasn't succeeded in this, see this for an example). Unless you have a solution for those problems, I suggest you choose a different tone for your critique...

Your signature line:

How to detect Internet Explorer

For those who are browser agnostic and simply wish for a browser to work on their web pages, it's more useful to check for the existence of a feature. Since Javascript allows you to check whether a function or object is defined without causing an error, one can gracefully fail -- simply don't use a feature if it's not available -- instead of trying to respond properly to innumerable browser versions. Feel free to read more on this from Quirks Mode.

As a side note, if all one wishes to do is detect Internet Explorer, even clever Javascript is more work than necessary, let alone server side shenanigans. IE supports conditional comments which can easily provide for any sort of IE criticism you want. And last I checked, Opera doesn't see these things (correct me if I'm wrong), so it would be more useful if all you were doing was haranguing people for using the default browser of their OS.

http://www.quirksmode.org/css/contents.htmlshows some useful comparison I believe.

Javascript is not Java

Having said that, I'm looking forward to CSS3 as (AFAIK) it'll offer transparency support, that feature alone makes it worthwhile to me (yeah yeah, you can get variable opacity with current browsers using proprietary CSS. I'd prefer standards.)

I generally write to the standard, and then spend a few hours after the fact making it work in ie. Safari/Khtml and Mozilla/Firefox are really very good at following the standard.

There are of course quirks in all of the browsers though. There is a REALLY great site to help with that though. quirksmode.org lists each css attribute, and has a table showing which browsers it works in, and which it mostly works in and so on.

You really can do some amazing things if you follow the standards AND work around the quirks. I try to avoid the comment-within-comment hacks, because they are ugly, and there is almost always a better way. Once you have a good knowledge of the quirks its not so bad.

I can say though that somewhat vague requests for "better standards support" are not as useful as a specific example of what you'd like to see changed and specifically why it would improve things.

IMHO, many or most of the web developers available today don't know how to develop web page with good compatibility and accessibility is because of their arrogance and ignorance, and partially, lack of good guidance of web developing.

However, we are all arrogant and ignorant, nobody can change this. So a good guide of web developing is the solution to the problem.

But the web was constructed in such a quick manner that most of the developers are not well trained. I bet, third of the web developers around the world don't know what or where is W3C. I also bet, fifth of the web developers around the world don't know ssh and scp, or even ftp. I can even bet tenth of the web developers of the world don't know the difference between Internet Explorer and Internet. And those well payed web developers are so well payed and pround of themselves that, I believe, half or two third of the web developers around the world don't show any respect to people with disabilities, like blindness and deafness.

Nonetheless, the bubble of web was broken so quickly that though some wise people saw the problem here, and provided the solutions like xhtml and css, nobody in the avalanch will care about it anymore. As the web has broken, who cares about the flaw of the web anymore.

Now everything has calmed down, and dawn of light arrived again. But these can not be a solution to the arrogant people. The solutions to that people could be a law that enforce them to show respect to the people with disability and improve the accessiblity of their products and fierce competetion.

As the new Internet Explorer, it may improve the CSS and XHTML support, but I am wondering what kind of trick they will play to keep web developers stupid and arrogant and happy and dreaming...

Why would you ever be hired with that attitude? The fact is, all the IE moaning is a BIG MYTH.

While I agree with you that one has to make pages work with IE; allow me to say that you are talking out of your ass.

My sites always have the proper DOCTYPE, they have to in order to validate (I validate all pages prior to posting). Sometimes _having_ a doctype makes IE show new bugs.

Frankly, unless you're building some fancy site with the absolute latest CSS and Javascript features, IE will render your page *just fine*.

Your sites are obviously _very_ basic with minimal design. The moment you pass into medium complexity you start running into problems. I don't use any Javascript.

Yet, why exactly do you need to be using 32-bit images on your page? It's quite easy (and beneficial for download speeds) to get by with 8-bit images.

We need 32 bit images in order to have variable alpha. If you don't have variable alpha, then you can't have any image without including the background it's going to be over.

Including the background in your image completely negates the advantage of declaring colors in the CSS. Normally I could change the background of my site by changing one line, now I have to change all images as well.

There's other reasons why you might want a variable alpha, say to have transparent graphics or windows (the navigation on the left). Which are not heavy as the image is just 2 x 2 pixels and weighs in at a hundred bytes or so. In fact there are tons of creative uses that people haven't even thought of.

and tell me why they play such an integral part of your development process that you cannot find a way around them.

You're missing the point entirely. The idea is to allow the designer do her thing (so I can get a beautiful unique website) and then translate that to CSS, compromising wherever needed; not just half-assedly add some design to a text document.

However, when one tries to do anything remotely interesting, Explorer completely dies on you.

The best solution I found so far is using IE conditionals and serving IE a different and sometimes strange CSS file. In the end I usually figure it out reasonably, but it takes ridiculous amounts of effort and the site is never as good as it's Safari/ Mozilla /Opera counterpart.

If you want an example you can look at my current site (I linked it above too), I've only starting the IE fixing, you can see the ugly IE file with filters: and other weird junk so that PNGs show up with alpha: here. So far it's taking a serious effort and even when finished won't look as well anyway. Look at it under both IE and then Firefox.

I should have probably posted a link to this in my other post, but anyway:

Browser Javascript Compatability, Browser DOM Compatability, Browser CSS Compatability.

As you can see, the problem is clearly not FF (or Mozilla, anyway). It's most probably bad code written to work on IE, which won't work on the standard-obeying browsers.