@Chris - yes I realise it *might* be a hack but it isn't *really*,
e.g.
The opera object (in window)
Pros:
has been around since Opera 5 - it's used mostly by User
JavaScript files (http://www.opera.com/browser/tutorials/userjs/specs/
index.dml)
is unique to Opera
Cons:
not part of any standard - so there's no guarantee that Opera
will include it in future versions.
Conditional compilation (http://msdn.microsoft.com/en-us/library/
7kx09ct1(VS.80).aspx)
Pros:
is unique to Trident/JScript
Cons:
not part of any standard - so there's no guarantee that MS will
include it in future versions.
watch()/unwatch() methods
Pros:
is unique to Gecko
Cons:
not part of any standard - so there's no guarantee that Mozilla/
Gecko will include it in future versions, this has been hi-lighted
recently as some JS libraries use another Gecko only method
(getBoxObjectFor()) to detect Gecko - which has been removed in FF3.6.
Although the user-agent string does have a standard (http://
tools.ietf.org/html/rfc1945#section-10.15 and
http://tools.ietf.org/html/rfc2068#section-14.42)
they differ (Http 1.0 doesn't have to have a user-agent field where as
http 1.1 does)... they are also quite ambiguous I especially like...
By convention, the product tokens are listed in order of their
significance for identifying the application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
IE7 - Mozilla/4.0 (compatible;.....
FF3.5 - Mozilla/5.0 (Windows;.....
O9.6 - Mozilla/5.0 (Windows NT 5.1;....
S4.0 - Mozilla/5.0 (Windows;....
Therefore according to the specs all the above user-agents are
"Mozilla" with IE being the only version 4.0 - the rest are 5.0...???
WRT content negociation yeh, I understand why/when you need this - but
to turn this on it's head why would I want a user to be able to view
my application knowing that it will break e.g. Opera pretending to be
Firefox?
I still stand by my original point, if there is no *good* reason GWT
is sniffing the useragent string then it shouldn't do it - it should
follow best practise.
It almost does - in that in detecting IE8 it looks for
document.documentMode (which is a proprietry MS property... not part
of any standard - so there's no guarantee... etc, etc) rather than
looking for MSIE8 and/or Trident/4.0???
Perhaps the UA string should be (unchangable) in the format "Engine/
Version UserAgent/Version OS Locale" e.g. Webkit/542.45+Safari/
4.05+OSX 10.05.6+en_gb - but thats another bag of worms...
Cheers,
Dave
On 25 Feb, 19:17, Chris Lercher <cl_for_mail...@gmx.net> wrote:
> Well... I don't know if this will really be more reliable - to be
> honest, it looks a little bit like a very, very dirty hack ;-) At
> least, I can't look at it and without knowing a lot of details about
> all existing browser versions ever, understand what this does. If
> there was something like "document.browserInfo.product",
> "document.browserInfo.majorVersion", ... (similar to JDBC's
> java.sql.DatabaseMetaData), then this could be a different discussion.
>
> However, even then I might still use the user agent string BTW, for
> the reasons I explained above: Think of the user agent string as a
> form of content negotiation, which can be influenced by the user if
> they want to. To make an analogy: If I go to pt.wikipedia.org, then I
> want the Portuguese version, no matter what the locale of my user
> agent is.
>
> I understand your decision, if your site really must ignore such a
> user setting. I also agree, that user agent strings should ideally be
> less ambiguous. So if I ever run into a situation, where the user
> agent string isn't enough to decide, I might actually fall back to
> your test - so I'll keep it bookmarked :-)
>
> Chris
>
> On Feb 25, 7:22 pm, mmoossen <mmoos...@gmail.com> wrote:
>
> > thanks dave for sharing :)
> > i think i will start using your code for browser identification
>
> > Michael
>
> > On Feb 25, 10:44 am, DaveC <david.andrew.chap...@googlemail.com>
> > wrote:
>
> > > Thanks for all the replies.
>
> > > Thomas, I get your point - but I don't agree ;o), I think there are
> > > more reliable ways for testing... here's something I've used in the
> > > past:
>
> > > <script>
> > > var isPresto = !!(window.opera); // The "opera" object/property
> > > has been in existance since version 5 (I think) and is consistent
> > > regardless of changes to the UA string.
> > > var isTrident = /*...@cc_on!@*/false; // Or use !!(document.expando
> > > && document.uniqueId) if you don't *like* conditional compliation
> > > var isGecko = !!(document.watch);
> > > var isWebkit = !!(!isPresto && !isTrident && !isGecko &&
> > > document.evaluate && document.querySelector);
>
> > > var ie8 = !!(isTrident && document.documentMode >= 8);
> > > var ie87 = !!(isTrident && document.documentMode === 7);
> > > var ie8q = !!(isTrident && document.documentMode === 5);
> > > var ie7 = !!(isTrident &&
> > > document.documentElement.currentStyle.maxWidth !== undefined && !
> > > document.compatible);
> > > var ie6 = !!(isTrident && document.implementation && !ie8 && !
> > > ie87 && !ie8q && !ie7);
>
> > > var sOut = "Presto ? " + isPresto + "\n";
> > > sOut += "Trident ? " + isTrident + "\n";
> > > sOut += "Gecko ? " + isGecko + "\n";
> > > sOut += "Webkit ? " + isWebkit + "\n\n";
>
> > > sOut += "IE8 ? " + ie8 + "\n";
> > > sOut += "IE87 ? " + ie87 + "\n";
> > > sOut += "IE8q ? " + ie8q + "\n";
> > > sOut += "IE7 ? " + ie7 + "\n";
> > > sOut += "IE6 ? " + ie6;
>
> > > alert(sOut + "\n\n" + navigator.userAgent);
>
> > > /*
> > > * Tested on IE6 - 8, Firefox 1.5 - 3.6, Opera 8 - 10.5,
> > > * Chrome 4, Safari 4, Maxthon 2 - only on Windows.
> > > *
> > > * Maxthon 2 identifies itself (UA string) as IE7
> > > * even though the system only had IE6 installed
> > > * (which is the Trident engine Maxthon is using).
> > > *
> > > */
> > > </script>
>
> > > I appreciate these methods aren't infallable - but IMHO they are more
> > > robust than UA sniffing. I just wondered whether there was some
> > > missing piece of information the Google engineers had (via Google's
> > > vast aounts of browser data) that showed that UA sniffing was
> > > necessary.
>
> > > Cheers,
> > > Dave
>
> > > On Feb 24, 11:30 am, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > > > On Feb 23, 1:41 pm, DaveC <david.andrew.chap...@googlemail.com> wrote:
>
> > > > > > So perhaps your question ought to be why GWT uses the user agent to
> > > > > > put
> > > > > > the browser into its 6 categories rather than using browser
> > > > > > capability
> > > > > > detection to put them into the same 6 categories.
>
> > > > > Errrr... isn't that what I asked?
>
> > > > > "So my question is NOT- why do we have deferred binding or why does
> > > > > gwt
> > > > > test for different browser platforms BUT:
>
> > > > > Why does gwt parse the useragent string rather than using object/
> > > > > feature detection - due to the fragility of sniffing the ua string? "
>
> > > > You'd end up checking only some features to give you a hint, which is
> > > > way worse than using the useragent string.
>
> > > > Want an example?
> > > > if (!window.XMLHttpRequest) {
> > > > // this is IE6, so I know:
> > > > // - I'll have to synthesize a click event from ondblclick
> > > > // - there'll be gotchas with image (pre)loading where the load
> > > > event
> > > > // might happen synchronously or even not at all
> > > > // - I'll have to use AlphaImageLoader for sprites
> > > > // - ...}
>
> > > > And now look at issue
> > > > 3608:http://code.google.com/p/google-web-toolkit/issues/detail?id=3608
>
> > > > (keep in mind that the selection script executes in the host page's
> > > > context, the iframe "sandbox" isn't created yet, so there's no $wnd)
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
