I typically don't respond to this type of thread, but this one kinda threw me...
While I wholeheartedly agree that one should be able to "make things work cross-browser", it is absurd at best to suggest that to "fix your CSS issues = find out the necessary hack to fix your issue". The very fact that it's a HACK means there's no way in hell that one *should* have to do it. And to suggest that a HACK is the equivalent as a FIX? WOW! A hack is a hack, always has been, always will be. A HACK is diametrically opposed to a FIX. Does that mean that I don't use CSS hacks? Hell no it doesn't. I use them all the time. Do I do it because I need to show off my mad skillz and prove my cross-browser worth? Hell no. I do it because IE is a complete P.O.S. and it is riddled with so many rendering bugs that I have no choice but to do the hacks if I want 70% of the web-viewing public to be able to see a decent copy of my page. If your argument was that a developer could be considered lazy if they decided on a tables-based layout instead of CSS/XHTML because they didn't want to learn the hacks necessary to do a pure CSS layout, then I could agree. But to assert that it's not a bug/problem with IE since there is a hack available... That's frequin delusional. :-) -----Original Message----- From: John C. Bland II [mailto:[EMAIL PROTECTED] Sent: Sunday, October 01, 2006 10:20 AM To: CF-Talk Subject: Re: CF vs. .NET presentations? 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:254914 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
