We host a number of online, distance-learning courses. Those in Math
and Chemistry use MathML. As far as I know, in order to view such
material with commonly-found web browsers one needs to be using
* Firefox 2.0+ with the Computer Modern fonts, or
* Firefox 3.0+ with the STIX fonts, or
* Internet Explorer 6.0+ with the Design Science MathPlayer plugin
(which comes with appropriate fonts).
In addition, for Firefox, the material is served as "application/xhtml
+xml", while for IE it is served as "text/xml".
It seems to me that when it comes to displaying appropriate material
for potential viewers, we're locked into browser-detection rather than
feature-detection.
If anyone has any inspiration as to how we might improve matters, I'd
love to learn about it.
... Ed Martin
On Feb 2, 12:34 pm, Kevin Dalman <kevin.dal...@gmail.com> wrote:
> "Feature detection is all about new and unknown browsers - hoping that
> your code will continue to persist. You conflate it with supporting
> old browsers that are lacking features - which is a completely
> separate set of discussions."
>
> "You're worried about old browsers failing gracefully - and that's a
> completely different set of issues from what normal bug fix feature
> detection should be handling."
>
> Thank you, John, for summarizing the seeming confusion on this topic -
> forward-looking VS legacy issues.
>
> This discussion was never about "which is better", browser or feature
> detection. The issue was whether there is *EVER* a proper use for
> browser-detection. If there is even a single instance where it is
> necessary or beneficial with no downside, then the fact is that
> browser detection remains a useful tool to have on hand.
>
> For *forward-looking compatibility*, feature-detection is clearly the
> way to go - I don't see anyone in this thread disagreeing with this.
> But when dealing with *legacy browsers* - IE6 & IE7/quirksmode in
> particular - it is often easier (and more reliable) to use browser
> detection instead. The idiocyncrisies of IE6 are well documented, so
> in my opinion, creating feature-detection 'hacks' serves no purpose
> other than being an interesting exercise. Unless someone can tell me
> another browser that does box-models *exactly* like IE6/7-qm, or a
> browser other than IE that requires bgIframe for SELECT fields, then I
> rest my case.
>
> Hopefully, when these old browsers are retired, the need for browser-
> detection and similar bug-detection may disappear. Until then, IE6/7
> still holds a dominant place in the market, and therefore often
> deserves special handling. Personally, I don't to waste ms when I
> don't have to, so I will continue to optimize for legacy IE browsers
> and sites (when writing plugins) by using $.browser when it seems the
> best and simplest option. Others can make their own choices.
>
> /Kevin
>
> On Jan 28, 7:30 am, John Resig <jere...@gmail.com> wrote:
>
> > > Feature Detection is all about checking how a feature behaves, and if
> > > it behaves in a known faulty way, then apply the known fix. Instead of
> > > checking whether browsers "support" each of the standard way of doing
> > > things, the detection should be checking for known failures that need
> > > fixing. Knowing that a browser does not support a standard way of
> > > doing something does _not_ logically tell you the correct way to fix
> > > it. You need to test to see how the feature behaves to know which fix,
> > > if any, is most appropriate.
>
> > You're still assuming that there's more than one possible fix. If we
> > need more than one fix then we would certainly test for the
> > applicability of each and work our way down - but as it stands there
> > is no point in progressing that far (we already use many more browser
> > features which would immediate exclude, or break, old browsers - such
> > as document fragments, advanced regular expressions, etc.)
>
> > There are two ways a one-fix situation can be done:
>
> > if (standards_supported)
> > use_standards_method()
> > else
> > apply_ie_fix()
> > // non-ie, non-compliant, browsers are broken
>
> > if (standards_supported)
> > use_standards_method()
> > else if ( can_do_ie_fix() )
> > apply_ie_fix()
> > else
> > // non-ie, non-compliant, browsers are broken
>
> > It doesn't matter - one way or the other the broken browser is still
> > going to be broken - the only difference is that IE is going to be
> > slower.
>
> > Feature detection is about providing fixes to bugs in a manner that
> > will gracefully continue to work when those bugs are fixed in new
> > browsers (or if duplicate bugs are introduced elsewhere, in an other
> > new browser).
>
> > Feature detection is all about new and unknown browsers - hoping that
> > your code will continue to persist. You conflate it with supporting
> > old browsers that are lacking features - which is a completely
> > separate set of discussions.
>
> > For example, right now different parts of jQuery may break in older
> > browsers - but the library, as a whole, will continue to try and
> > operate. It's not clear if that's desirable - if we can't guarantee
> > that all of the library should work, should we just quietly fail
> > instead? One idea that I've been thinking of is to make it so that the
> > callback passed to $(document).ready(function(){}) will just not
> > execute if we can't guarantee that all of jQuery will work.
>
> > This does a couple things:
> > 1) Users of old browsers will simply have no JavaScript run (which is
> > fine, since users of jQuery should be doing graceful degradation
> > anyway).
> > 2) This limits the set of possible browsers that will ever even hit
> > the "jQuery.support" code to those that we actually have solutions
> > for.
>
> > I'll need to collect an assortment of older browsers, first, to
> > determine what can and should be checked for a failure state (probably
> > check Firefox 1.5, IE 5.5, Opera 8, Safari 1, etc.). This will be good
> > since if we can't make a check to properly exclude an older browser
> > (since it would be missing some critical feature) then we should
> > probably work to support it fully.
>
> > But - again - this is not feature detection as it's typically defined
> > and should not be confused with feature detection. You're worried
> > about old browsers failing gracefully - and that's a completely
> > different set of issues from what normal bug fix feature detection
> > should be handling.
>
> > --John
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
