You raise a lot of interesting issues. I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.
I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types. One thing you might be interested in is that we've been talking recently about the idea of a backend "linker" that would be pluggable/configurable, so that the compiler output is a lot more customizable. This sounds like a good use case for that architectural idea.
You raise a lot of interesting issues. I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.
I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types.
Ian
--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com
On Nov 7, 10:52 pm, "Archie Cobbs" <archie.co...@gmail.com> wrote:
> Some issues:
> - How important is IE wrt. SVG? Basically Microsoft has chosen not to
> support SVG; so as long as "browser independence" is defined only over the
> domain of browsers that actually support the target document type, this
> shouldn't be a problem. Different browsers exist for different document
> types. Is accepting this as a fact of life reasonable?
IExplore does not suport SVG natively and Adobe after purchasing
(merging) Macromedia (Flash to be strict) announced - guess what -
that they SVG plugin support is ended (will be ended with end of that
year) - and yes,, IE is still predominat browser which does not
support SVG (did they talked about Silverlight?),
related fresh topic on regular group:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/83dba7de10d92adc/
regards,
Peter
also I wonder how many libs already are written for SVG:
http://gwt-svg.googlecode.com/svn/
http://wiki.svg.org/SVG_and_GWT
and more,
considering incubator existance I wonder if you can join forces with
other people to merge efforts to have one, well maintained library,
regards,
Peter
On Nov 10, 12:28 am, "Archie Cobbs" <archie.co...@gmail.com> wrote:
> Thanks... yes, I'm keenly aware of all the corporate maneuverings :-)
>
> If IE doesn't support SVG that's fine... it then simply doesn't fall into
> the category of "SVG browsers".
>
> The SVG document type support only attempts to target SVG browsers.
>
> In other words, if you are speaking the language of HTML then I completely
> agree with you that it would be crazy to not support IE. However, in the
> case of SVG the picture is quite different.
>
> On 11/9/07, Peter Blazejewicz <peter.blazejew...@gmail.com> wrote:
>
>
>
>
>
> > hi Archie,
>
> > On Nov 7, 10:52 pm, "Archie Cobbs" <archie.co...@gmail.com> wrote:
> > > Some issues:
> > > - How important is IE wrt. SVG? Basically Microsoft has chosen not to
> > > support SVG; so as long as "browser independence" is defined only
> > over the
> > > domain of browsers that actually support the target document type,
> > this
> > > shouldn't be a problem. Different browsers exist for different
> > document
> > > types. Is accepting this as a fact of life reasonable?
>
> > IExplore does not suport SVG natively and Adobe after purchasing
> > (merging) Macromedia (Flash to be strict) announced - guess what -
> > that they SVG plugin support is ended (will be ended with end of that
> > year) - and yes,, IE is still predominat browser which does not
> > support SVG (did they talked about Silverlight?),
> > related fresh topic on regular group:
>
> >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
> > regards,
> > Peter
You raise a lot of interesting issues. I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.
I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types. One thing you might be interested in is that we've been talking recently about the idea of a backend "linker" that would be pluggable/configurable, so that the compiler output is a lot more customizable. This sounds like a good use case for that architectural idea.