(again, responded off list) On 10/1/06, Matt Quackenbush <[EMAIL PROTECTED]> wrote: > > 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:254926 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
