Oddly, we seem to have lost the supported browsers list in the transition to 1.6 (or I'm just too blind to see it). The 1.5 doc read as follows:
- Internet Explorer 6 and 7 (Windows) - Firefox 2 and 3 (Linux, Mac, and Windows) - Safari 3 (Mac) - Opera 9.5 (Mac and Windows) - Google Chrome If I were rewriting these now, I would add a '+' to each of those versions. Like most tools and libraries, we support back to some minimum version of every major browser. I'll make sure this gets moved over properly to the 1.6 doc (or at least linked more prominently if it's there and I just missed it). If an issue comes up with a new release of an existing browser engine, we deal with it as fast as we can. This is relatively rare, as most browsers stay mostly backwards-compatible with their own previous versions. IE8 has been a bit more complex for two reasons: 1. They changed quite a lot, and added a new "super standards" rendering mode. 2. We have had a single IE target for a long time, which if left as is would require one target to support IE6, 7, and 8. Heretofore, there hasn't been a coherent theory for how we decide when to break user-agents into separate targets. As you correctly describe, there's an inherent tension between compile time and the compiler's ability to optimize the output. Ideally, we'd simply add a new target for every browser sub-version that comes out, adding and removing tweaks as necessary, but of course, that would lead to massive permutation explosion. I've just begun a wiki page where I plan on writing up this decision process with a bit more clarity (as well as a few proposals for cleaning up the existing user-agent support, such as the bizarre naming issue you mention; one small nit -- when we drop "old mozilla", it will be the "gecko" user-agent, meaning Gecko versions *before* 1.8). Everyone's comments and ideas are as always welcome: http://code.google.com/p/google-web-toolkit/wiki/UserAgentCleanup (It's only a skeleton now, but I'll be fleshing it out over the coming days) Also not entirely well-defined is when we decide to pull support for an old version of a browser. It's a tough, multivariate decision, and thus far we've only ever done it for Opera 8 and Safari 2 (then only after these browers' usage dropped to an extremely low level, and they became very difficult to support). We need to add more clarity around this process as well. I also welcome any ideas on how we can make sure people don't run a full compile more than necessary. Obviously we're working to make that faster as well, but I believe that OOPHM will make it much less necessary than it is presently. Cheers, joel. On Fri, Apr 24, 2009 at 1:31 AM, Vitali Lovich <[email protected]> wrote: > Is FF3.5 on the plan as well? Safari 4? Opera 10? Chrome? Are there > guidelines on when a browser version gets its own axis (i.e. HTML5 support) > or is it just when it feels appropriate or there are significant changes? > > Shouldn't then we refactor the other browsers as well to be named after the > layout engines (i.e. DOMImplGecko with DOMImplMozilla or DOMImplFirefox as > specific subclasses, or DOMImplWebkit with DOMImplSafari and/or > DOMImplChrome). > > Also, I'm still trying to find a good list of supported browser versions > for browsers other than IE. Is FF really supported all the way back to FF > 0.9? Probably not since I was told that MozillaImplOld is should disappear > with 2.0, meaning presumably gecko 1.8 & earlier browsers will become > unsupported. What about Safari & Opera. > > On a side note, the number of permutations is especially important as a > developer-facing issue because time & time again on the mailing list it > comes up with people complaining about the compile time because that's how > they think they should be developing (instead of using hosted mode for > development or limiting to a specific configuration to fix a > browser-specific problem). > > Adding more documentation doesn't seem to help because that doesn't seem to > be read thoroughly - this seems to be more from the jump in with both feet & > hack till it works crowd (not that there's anything wrong with that approach > :D). > > Maybe have the compiler print a warning with a reference to the > documentation indicating it's not a good workflow to compile for development > if the last successfully compiled code was like in the last 5 hours. > > > On Thu, Apr 23, 2009 at 4:31 PM, <[email protected]> wrote: > >> >> Reviewers: jlabanca, >> >> Description: >> This monster of a patch adds what I believe to be full support for IE8. >> >> Review strategy to make your life easier: >> - All the .gwt.xml files, with the exception of DOM and History just add >> ie8 to the existing ie6 cases. >> - The giant diff around both DOMImpl's stems from the fact that in both >> cases I renamed DOMImplIE6 to DOMImplTrident (Trident is IE's rendering >> engine), and created IE6 and IE8 subclasses. The IE8 subclasses are >> currently empty, and I pushed down a few IE6/7-only method >> implementations into the DOMImplIE6's. >> - I would save the HistoryImpl changes for last. IE8 implements the >> HTML5 standard "onhashchange" event, which is going to be the proper way >> forward on new browsers, so I refactored the implementation such that >> HistoryImpl uses that. >> - I also ditched the no-longer-supported Safari 2 history >> implementation and collapsed the HistoryImplFrame/Safari/IE6 into a >> single HistoryImplIE6. >> - I added a new HistoryImplTimer which uses a timer to simulate the >> "onhashchange" event (this isn't actually a change, just a slight >> refactoring -- the Mozilla and Safari implementations have always worked >> this way). >> >> Also see this document for some more detail: >> http://code.google.com/p/google-web-toolkit/wiki/IE8Support >> >> Please review this at http://gwt-code-reviews.appspot.com/29803 >> >> Affected files: >> user/src/com/google/gwt/dom/DOM.gwt.xml >> user/src/com/google/gwt/dom/client/DOMImplIE6.java >> user/src/com/google/gwt/dom/client/DOMImplIE8.java >> user/src/com/google/gwt/dom/client/DOMImplTrident.java >> user/src/com/google/gwt/user/ClippedImage.gwt.xml >> user/src/com/google/gwt/user/DOM.gwt.xml >> user/src/com/google/gwt/user/Focus.gwt.xml >> user/src/com/google/gwt/user/Form.gwt.xml >> user/src/com/google/gwt/user/History.gwt.xml >> user/src/com/google/gwt/user/Hyperlink.gwt.xml >> user/src/com/google/gwt/user/Popup.gwt.xml >> user/src/com/google/gwt/user/RichText.gwt.xml >> user/src/com/google/gwt/user/SplitPanel.gwt.xml >> user/src/com/google/gwt/user/TextBox.gwt.xml >> user/src/com/google/gwt/user/Tree.gwt.xml >> user/src/com/google/gwt/user/UserAgent.gwt.xml >> user/src/com/google/gwt/user/Window.gwt.xml >> user/src/com/google/gwt/user/client/impl/DOMImplIE6.java >> user/src/com/google/gwt/user/client/impl/DOMImplIE8.java >> user/src/com/google/gwt/user/client/impl/DOMImplTrident.java >> user/src/com/google/gwt/user/client/impl/HistoryImpl.java >> user/src/com/google/gwt/user/client/impl/HistoryImplFrame.java >> user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java >> user/src/com/google/gwt/user/client/impl/HistoryImplMozilla.java >> user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java >> user/src/com/google/gwt/user/client/impl/HistoryImplStandard.java >> user/src/com/google/gwt/user/client/impl/HistoryImplTimer.java >> user/src/com/google/gwt/xml/XML.gwt.xml >> user/super/com/google/gwt/emul/EmulationWithUserAgent.gwt.xml >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
