I think it is helpful if we distinguish between optional and mandatory features. If GWT would come with a set of widgets or library components that behave slightly different on different browsers this might not be bad in general. I'm aware that the general approach of GWT is to write software once and run it almost everywhere with identical results. But I can imagine several areas where it may be appropriate to have e.g. widgets that look even better when the rendering engine supports 3d animations etc. If the developer can use the widget as is and will get a "default" behavior on all browsers and an extended behavior on top on some of them, this would be beneficial IMO. Think of a TabPanel widget that takes advantage of the new funky 3D animation and transition feature on WebKit and provides a working default implementation for browsers not supporting CSS3 looking a little bit more boring. When it comes to libraries like Database storage it would be helpful to have a dummy implementation that will do nothing in case when no persistence is available and to provide some "isAvailable()" method for each additional feature.
On Jul 22, 5:00 pm, Arthur Kalmenson <arthur.k...@gmail.com> wrote: > This would definitely be a killer feature. > > A common API for something like Web Workers and App Cache (maybe > wrapper forhttp://code.google.com/p/webstorageportabilitylayer/) that > can seamlessly switch talk to Gears or native HTML 5 implementation > would be very nice. I think it's a lot easier to convince a company to > install Gears then installing and using a completely new browser, so > at least for enterprise settings some common API would be very useful. > > Regards, > -- > Arthur Kalmenson > > > > On Mon, Jun 29, 2009 at 10:24 AM, dflorey<daniel.flo...@gmail.com> wrote: > > > Hi, > > I've been wondering how GWT should deal with upcoming new features in > > HTML5/CSS3. > > There are several areas where functionality that has been implemented > > in GWT is now also available in the upcoming rendering engines. > > > GWT is creating highly optimized JavaScript and the JavaScript-engines > > are getting better and better... but: My guess is that for example > > animations will be smoother when using CSS3 animations instead of > > JavaScript based animations. > > Same about rounded corners/shadows and stuff alike. In GWT you'll > > typically use DecoratedPanel to implement rounded corners with > > shadows. But Firefox3.5 and the latest Safari and Chrome releases also > > support css-based rounded borders and shadows. > > > So my proposal would be to use deferred binding to "emulate" these > > features on browsers that do not support the latest features (IE8...) > > and to use a lightweight css based impl on WebKit/Firefox 3.5. > > > In my example of DecoratedPanel the 9x9 approach should be kept for IE > > and a null impl with css based rounded corners should be available for > > Firefox (css have to match the given theme). > > Animations that come with the standard widgets should also be able to > > fallback to css based animations when available. > > > I've been also reading some posts about the new datagrid html > > extension and thought it might be clever to have a look at the spec > > when moving the tables from incubator to trunk to see how far the > > concepts match. Would be very cool to have a native table > > implementation on WebKit browsers while other fallback to gwt impls. > > > What do you think? --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
