On 2 juil, 17:03, Joel Webber <j...@google.com> wrote: > 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.
There's also the Gears Canvas (you could get a data: URL out of it and give it in an Image for IE8+) and of course Flash (think Chronoscope ;-) ) and/or Silverlight. > 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. And for IE compatibility, Silverlight again (see http://intertwingly.net/blog/2008/01/26/SVG-Shiv and similar articles on Sam Ruby's blog) > 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. It definitely is: http://google-code-updates.blogspot.com/2009/05/gmail-for-mobile-html5-series-common.html > Cross-Document Messaging: > I'm pretty sure this can be emulated with window.name hackery. Cannot we rather consider this an "optional feature", just like database, geolocation and app cache? > 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. Drag'n'drop! (using Gears or Yahoo! BrowserPlus as an alternative to browser-native support –if detectable–) And there are a few other things that have been split from HTML5 into their own spec: - Web Workers ("optional feature", same as database, geolocation, etc. see above) - WebSockets (using long-polling –eventually in a Worker– for now as no-one implements it) - File API (use Gears or BrowserPlus as a fallback when available) - XMLHttpRequest 2 (progress events and ability to send binary data from the File API; again, Gears could be used to emulate it, BrowserPlus to a lesser extent) - Selectors API (already supported by GQuery) See http://www.w3.org/2008/webapps/ --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
