I'm very much on board with the idea of moving forward on new browser features by emulating them on old browsers wherever possible. This is an important benefit of using tools (code generation, deferred binding, monolithic compilation) to get leverage on this problem. I think the best approach is to consider each such feature separately. They're going to require different approaches (e.g., some can be dealt with entirely in CssResource, but others will likely require the use of specific classes), and some will turn out to be impossible, or practically so (e.g., support for the <video> tag without a transcoding server to deal with Ogg, H.264, Flash, etc). So for the specific cases described below... CSS Animations: I think we need to actually measure the performance difference before deciding whether it's even worth the trouble. I suspect that there may not be much of one (though of course I could be wrong), given that it has to do the same work, possibly including layout, regardless of how it's specified. And CSS animations aren't as general as programmatic ones. That said, there might be some utility in having CssResource parse them automatically and write the necessary code for you on older browsers (though I haven't assessed the feasibility of doing so).
Rounded Corners / DecoratorPanel: Here I think it's going to be a practical necessity to require that a specific class (such as DecoratorPanel) be used. The reason is that, to my knowledge, there is no way to get general 9-box rounded corners without a specific DOM structure. But DecoratorPanel could be modified to take advantage of CSS3 9-boxes on newer browsers. DataGrid: I honestly haven't read enough about this proposal to have any idea whether it makes sense or not. But if it is implemented and offers a substantive advantage, then we should certainly have a look. Some others that might be interesting: Canvas: This is a nasty case, because Canvas cannot be implemented sanely or efficiently on top of VML, which is the only game in IE town. Existing canvas-on-VML implementations notwithstanding -- they have wildly different performance semantics, which is pretty unacceptable in my opinion. SVG: Things are a bit brighter here. There are some things (foreign objects and certain gradient patterns come to mind) that SVG can do, which VML cannot. But a sane navigation of the common features could lead to a quite usable and efficient vector graphics library. There's the existing GWTCanvas that Jaime wrote a while back as a starting point (which uses Canvas rather than SVG), but it appears to me that SVG performance has gotten a lot better since that was written, so it's probably worth reconsidering that approach. HTML5/Gears Database: Geolocation: These shouldn't be too difficult, as applications can be easily made sensitive to their presence or absence. The database/client-side storage APIs may need some cross-browser love, as there are a few different approaches and subtle differences across browsers, but I believe that is manageable. Cross-Document Messaging: I'm pretty sure this can be emulated with window.name hackery. App Cache: This is something we should support at the Linker level. And like the database APIs, an application can be made sensitive to its availability without too much difficulty. CSS Transforms: I think we're pretty much screwed on this front. We could *try* to do translation, but I seriously doubt it's worth the trouble (and would probably cause layout issues, as the semantics are subtly different than left: and top:). But rotation and scale (not to mention arbitrary affine transforms) seem impossible to emulate. <audio>, <video>: I'm not terribly bullish on these. <audio> is at least theoretically supportable using Flash, and I could see something like the SoundManager2 js library taking advantage of it. But <video> is rife with codec licensing problems that seem unlikely to get resolved any time soon (If anyone wants to debate the ins and outs of codec licensing, let's *please* do so on another thread, because I can tell you from experience that the thread won't converge). And of course, there are probably others I'm not thinking of, so feel free to chime in with ideas. joel. On Wed, Jul 1, 2009 at 1:09 AM, nicolas de loof <nicolas.del...@gmail.com>wrote: > Transparent support for CSS3/HTML5 on all browsers including IE would be a > killer feature !+1 > > 2009/7/1 tfreitas <tfrei...@gmail.com> > > >> +1 >> >> On Jun 29, 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 -~----------~----~----~----~------~----~------~--~---
