Hi Chris, yeh I think we're on the same page but... ;o) ... *Here* we're talking about GWT not about the public facing web so...
> ... e.g. I'd like to be able to view the pages also with Konqueror > (whose KHTML engine is BTW is not so similar to WebKit browsers > anymore). It may work best when the browser sends me the Firefox > version, or it may work best with the Webkit version. I'll want to > decide that as a user, because the site owner won't care about > Konqueror. The same is true for any completely new browser that may be > released in the future - if the site isn't maintained anymore, or the > site owner doesn't care, I will be unable to view it, although I could > view it, if only I could retrieve the site for example in the WebKit > version. ... (for the public facing web) here's where browser detection fails - and feature detection + progressive enhancement wins. " The same is true for any completely new browser that may be released in the future - if the site isn't maintained anymore, or the site owner doesn't care, I will be unable to view it, " - not sure I agreed with that - unless browser vendors release a breaking change and/or they fix a bug that developers had built logic on. For example I can view/use a website in Firefox 3.6 that would have been built/tested against (and hasn't been changed since) IE4/NS4... I would not recommend GWT (or Echo2 or Echo3 or any other JS based widget toolkit) to build a public facing website/application (without progressive enhancement) - you lock out too many potential customer/ users - not everyone in the world uses the six browser platforms/ versions GWT builds against (as you mention) - and yes it's possible to use GWT to progrssively enhance but you have to jump through a lot of hoops from what I've seen/understand. However, for intranet/extranet apps that get "installed" by large corporates - then yes GWT et al has a benefit. If say, a software vendor says "we support Firefox on Linux" and one of their customers says "we're going to use Konqueror... but it doesn't work" - then thats up to the customer (who was made well aware of the fact that the app they bought was only supported by Firefox) to negociate with the vendor on supporting that particular browser... IMHO. Cheers, Dave On 1 Mar, 13:01, Chris Lercher <cl_for_mail...@gmx.net> wrote: > Hi Dave, > > I believe, that basically we share some of our attitudes about making > detection stable (I totally agree on the sickness of UA strings). > But.... > > > 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? > > ... e.g. I'd like to be able to view the pages also with Konqueror > (whose KHTML engine is BTW is not so similar to WebKit browsers > anymore). It may work best when the browser sends me the Firefox > version, or it may work best with the Webkit version. I'll want to > decide that as a user, because the site owner won't care about > Konqueror. The same is true for any completely new browser that may be > released in the future - if the site isn't maintained anymore, or the > site owner doesn't care, I will be unable to view it, although I could > view it, if only I could retrieve the site for example in the WebKit > version. > > So I believe, we may have the _opposite_ of Daniel's assumption: > > > > Why does gwt parse the useragent string rather than using object/ > > > feature detection - due to the fragility of sniffing the ua string? " > > > It makes it easier to NOT support certain browsers. =) > > Moreover, in the case the detection actually errs, because the user > has a browser version that sends a strange user agent string, the ua > string can be changed. Whereas if browser detection fails, there's > probably not much the user can do. > > Chris > > On Mar 1, 1:27 pm, DaveC <david.andrew.chap...@googlemail.com> wrote: > > > @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 > > andhttp://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 > > ... > > read more » -- 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.
