@Matt: Re: "Why not just check the value, and if it is 0 or undefined/
null, apply the "visibility" fix?"
Because this is a generic method - some properties can be read when
hidden and some can't. Plus '0' is a valid dimension, so it might mean
there is no border or it might not! I *could* create and test a bunch
of alternate work-arounds, but if it ain't broke, don't fix it!
Just for the heck of it, here's another example from the same plugin.
I'm sure there are other ways to detect IE6 and IE7 quirks-mode, but I
doubt any are more consise and readable than this if-statement...
/*
* Extra CSS for IE6 or IE7 in Quirks-mode - add 'width' to NORTH/
SOUTH panes
* Normally these panes have only 'left' & 'right' positions so pane
auto-sizes
*/
if ($.browser.msie && (!$.boxModel || $.browser.version < 7)) {
if ($Ps.north) $Ps.north.css({ width: cssW($Ps.north,
cDims.innerWidth) });
if ($Ps.south) $Ps.south.css({ width: cssW($Ps.south,
cDims.innerWidth) });
}
"Browser "sniffing" relies on the user-agent header of the browser.
This has been shown to be unreliable."
A non-compatible browser that *claims* to be IE will break millions of
websites, so frankly I don't care about such fringe examples. The
dozens of browsers I've tested that emulate/shell IE - including
FireFox with its "IE Tab" plugin - all work *perfectly* with browser
sniffing. Why? Because they are designed to do so - it's become a
defacto standard. (I'm in a IE shell program right now!) I cannot say
the same for conditional comments though.
"Nearly every issue can be addressed using proper feature detection
strategies rather than browser sniffing."
Except your own example that is, or mine. "Nearly" is not "all". Isn't
that the point?
I agree that ANYTHING can be done given enough time and ingenuity -
like the maxHeight hack suggest above. So I could spend hours writing
and testing work-arounds on 20 different browsers/versions, and litter
my code with multiple, confusing hacks to replace browser detection.
OR I can use simple, clear, concise browser/version detection that
efficiently handles well-know legacy cross-browser issues.
Many such things - like box models & bgIframes - will soon fade away
like all the IE3/4, NN2/3/6 and FF1/2 issues before them. So I'm not
concerned about NEW browsers appearing with the same issues as IE6.
When handling forward-looking issues (like CSS3 compatibility), I try
to use feature detection, because it is better suited. That's why
$.support is a great addition. But my point is that forcing feature
detection into code better served by browser detection is not
*automatically superior* just because it's 'possible'. It's also
'possible' to cut meat with a spoon and eat peas with a knife, but I
prefer not to. Choice is good.
I would not presume to tell you how to write code (though some point
out it may not compress). I merely want my chosen toolkit, jQuery, to
support my own coding choices.
But I've belabored this issue too long. IF I still have a need by the
time $.browser disappers, I'll just write a plugin. I already use a
library of custom jQuery extensions anyway, so one more is minor.
Thanks for the feedback though.
Kevin Dalman
On Jan 26, 12:10 pm, Matt <m...@thekrusefamily.com> wrote:
> On Jan 26, 1:02 pm, Kevin Dalman <kevin.dal...@gmail.com> wrote:
>
> > @Matt: This may be functional...
> > useIframe:/*...@cc_on @*//*...@if (@_win32) true, @else @*/false,/*...@end
> > @*/
> > But using a conditional comment 'hack' is just browser/platform
> > sniffing by another name.
>
> It's a different, more reliable method.
>
> > You could have written:
> > var isWin32 = false;
> > /*...@cc_on isWin32=true; @*/
> > var useIframe = isWin32;
> > So how is this 'better' than:
> > var useIframe = $.browser.msie && $.browser.version < 7;
>
> Browser "sniffing" relies on the user-agent header of the browser.
> This has been shown to be unreliable. Any browser can insert any
> string it wishes. Browsers are known to fake this to appear as IE, for
> example. Just because a browser says it is IE doesn't mean that it has
> the IE functionality that you may be expecting. This is why the
> concept of feature detection is vital.
>
> Conditional comments will be ignored by any browser except IE. If
> another browser is pretending to be IE, it would fool your test, but
> not the cc version. It is a more robust (although still imperfect)
> test.
>
> > Even the skilled developers in this forum cannot agreement how best to
> > 'replace' $.browser functionality.
>
> It would be great to address each concern as they come in. Nearly
> every issue can be addressed using proper feature detection strategies
> rather than browser sniffing. And once this is done, jQuery and
> plugins may begin working properly in browsers that technically aren't
> in the supported list. This would be a great step forward.
>
> > FYI, here is just one example of where I use 'browser detection' to
> > optimize functionality...
> > // IE CAN read dims of 'hidden' elements - FF CANNOT
> > As with bgIframe, there is no 'feature' to check, so $.support is
> > useless.
>
> Why not just check the value, and if it is 0 or undefined/null, apply
> the "visibility" fix? Then you are completely browser-agnostic.
>
> Matt Kruse
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
