Oh man, this is one of the reasons I don't like replying on big lists. I have to explain every detail or I get "flamed" by someone.
Duh, the rendering engine does not render everything properly and the community has found the necessary hacks to work around them. Did you think I was talking about 5 years ago or now? You even said most hacks are known now. Of course I'm talking about now. I don't know of a "bug" or feature that a hack hasn't been discovered. So, in detail, fix your CSS issues = find out the necessary hack to fix your issue. CSS developers aren't considered such unless they can make things work cross-browser. Would you agree? Even if you don't, that is my take. I won't hire anyone for XHTML/CSS unless they can work cross-browser. So, again...fix your CSS. Yes, IE 6 bites big time. MSFT has admitted it and pretty much every developer that has ever worked with JS or CSS knows this. I never said it doesn't have bugs but to put a blanket statement of "something not rendering properly is a bug" is a little much. With every link you provided, isn't there a way around it? Again, fix your CSS. ;-) lol. Man...it isn't that serious Mark. I'll try to be more careful in the future not to make statements without being extra detailed. On 10/1/06, Mark Henderson <[EMAIL PROTECTED]> wrote: > > On 9/30/06, Robertson-Ravo, Neil (RX) wrote > > He was being sarcastic, that was obvious. > > Then John C. Bland II wrote > >Apparently not. ;-) > > and the text in question from Jochem: > > So next time I find an issue where for instance a bug in IE results in > > incorrect rendering, I can just call and I get a bugfix a month later? > > That is not my experience with MS support. > > I think Jochem was simply putting the acid test on Matthews previous > support claims (with particular emphasis on the time frame for a fix). > It's certainly not wrong to test the validity of a particular statement > while meeting the specified criteria, or is it? > > > Are you seriously stating you called MSFT about IE not rendering > something > > right? That is definitely not a bug. IE has a rendering engine. > > I'll add an LOL to that. I think you needed to do a little bit more > research before making such a blanket statement, since it seems you are > associating *all* differences in IE rendering with its engine. Sometimes > that is the case, sometimes, but not always, which logically makes your > statement false. A difference in IE rendering can sometimes be put down > to the engine in question (expected behaviour, even *if* it conflicts > with the docs), versus faulty rendering (defective rendering equates to > buggy behaviour, no matter what the engine is). The two are not the > same. FWIW, all IE7 bugs can now be reported on their blog: > <url:http://blogs.msdn.com/ie/archive/2006/01/31/520817.aspx> > > > CSS developers know what it can and can't handle. > > Historically, that has simply not been the case. Maybe now that *most* > IE bugs have been discovered, it is a little closer to the truth, and > those taking up CSS are able to easily apply the hacks relevant to their > problems. However, when said bugs were still in their infancy (with > plenty still yet to be discovered), it was an extremely frustrating time > for a lot of developers, having to break things down to, at the very > least, a minimal test case before attempting to resolve the issue. > Remember, this was at a time well before the release of IE7 where we had > to try and nut these problems out for ourselves (with little knowledge > of the IE rendering engine, I might add). And they were *not* easy to > resolve - just see the solution to the 3 pixel text jog below for proof > of this. > > An example might help serve my point better. Some IE weirdness can > definitely be grouped under the category of "it's a feature", an example > being the 3 pixel text jog: > <url:http://www.positioniseverything.net/explorer/threepxtest.html> > Hardly a handy feature in my opinion, but I suppose that was Microsoft's > call and the browser *was* designed to behave that way. Now, the > guillotine bug on the other hand can in no way, shape, or form be > interpreted as anything other than a bug, period. > http://www.positioniseverything.net/explorer/guillotine.html > > If you really want to argue that this (and many many others) are simply > a product of the rendering engine and that this is not buggy behaviour, > then by all means, go right ahead. But before you do, please read this: > <url:http://blogs.msdn.com/ie/archive/2006/08/22/712830.aspx> > > if Microsoft are prepared to admit to their bugs, maybe it's time you > accepted that they exist. > > > If you did something it can't > > handle, tough cookies. Fix your CSS...not IE. > > This ties in with the faulty perception that all rendering differences > in IE are solely related to the engine. It's not so much what it can't > handle; we know IE versions prior to 7 don't support pseudo classes for > instance, so we just don't use them where IE is concerned. The problems > tend to arise when its output differs to the specifications, and how it > renders differently compared to other more standards compliant browsers > (based on correct and valid code). What you see is not always what you > expect to see, at least where IE is concerned. Most issues can be fixed, > but to do so often requires the use of various *hacks* to help IE fall > in line (sometimes even exploiting one IE bug to counter another) and > has nothing to do with *fixing* what is not broken CSS. > > > Mark > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:254909 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
