Every browser implementation has serious shortcomings. This is something that
all the companies that generate content on the internet (svg, html, or
streaming media)
As a matter of fact, ASV is the only browser solution to support SVG (full),
SMIL, and scripting together without help. All the other browser solutions
have fallen short.
Whereas I commiserate with Domenico that there are not enough implementations
out there that are sufficiently compliant, there is nothing special about
this condition, nor there any reason to expect this situation wil dissapear
any time soon.
We had the same problem in sgml in the 90s, and we have always had this
problem with new technologies. I fully expect that Ajax will cause new
frameworks to be developped, and that widget libraries will be built around
particular Ajax flavours. I am fairly pessimistic about the prospects for
inter-connectivity between Ajax-ish back-ends and front-ends from different
supplies. We have not hit this level of sophistication in the SVG industry
yet, but I am sure it is coming soon enough.
We need to build our systems around the tools we have, and we have to keep in
mind the risk of building complex applications or websites around a cocktail
of technologies which is only available from a single vendor. This is of
course the opposite of reacting to commercial pressure to be unique and to
stretch the limits of the technology...
Today, the risk-adverse SVG developer will identify the lowest common
denominator and build the SVG content accordingly, keeping in mind bandwidth,
processing cost, and platform support. Alternatively, the developer will
provide an elegant downgrading solution for their content, or will allow the
user to select the content to match the workstation capabilities.
Building a commercial livelihood around the capabilities of a single
commercial solution like ASV is a very dangerous strategy. Every one of us in
the tool and content development spheres has felt the consequences of being
subject to a single vendor at least once. This has been a hard lesson for
many SVG content developers and I personally have seen several contracts be
lost as a direct result of relying on a single vendor for a critical
component of SVG visualization toolchain. For that very reason, it is
critical for companies who operate in the SVG sphere to champion efforts of
groups like Opera, Mozilla, and KDE (and Adobe if they ever move forward in
SVG again).
Since the content developers rely on the tool developers for browser and tool
creation, maybe the commercial interests in the SVG community who are
directly dependant on the SVG tool makers would be well served by
contributing to the free software built by the tool makers that the content
creators rely on to earn a living. Tool makers need resources to proceed with
their work, and the most logical source of these resources (time, labour, or
funds to pay for them) is the content and application developers.
I strongly believe that if a commercial player regrets that Firefox is missing
a particula capability, then the commercial player should pay for this
support.
The great thing about open-source software is that if you don't like it, you
can contribute to it to change it.
Ronan
--
Ronan Oger
RO IT Systems GmbH
...Extending the web with SVG since 2001
Tel: +41 76 527 3552
Fax: +41 44 274 2402
http://www.roitsystems.com
On Sunday 04 December 2005 06:52, Doug Schepers wrote:
> Hi, Domenico-
>
> While you know I respect you, your work, and your opinions, I have to say
> that I must respectfully disagree with you here.
>
> Do things render quickly and perfectly in FF? Is FF feature-complete as
> regards SVG graphical elements or DOM methods? Is there support for 2 of
> my favorite features, SMIL and SVG Fonts? Sadly, no. However, does it help
> spread SVG? Emphatically, yes.
>
> Over the past few months, I've tried to clean up a lot of my content so
> that it renders as well as possible in FF. I've gotten many of my WebApps
> to behave tolerably well (though others are a lost cause). It is far from
> my ideal platform. But a *lot* of content will render just fine.
>
> Let's face it, just browsing legacy SVG, you are bound to stumble on a lot
> of mistakes that Adobe should never have rendered. In this way, alone, I
> see value in Firefox... it will make authors and authoring tools create
> real, valid XML, which will aid the transition to Compound Documents. This
> is where I think SVG will find a whole new audience, with SVG as just a
> part of a larger mixed-namespace context.
>
> But let's not talk about technicalities like that, of interest only to
> standards wonks. Let's talk real-world cases.
>
> There is a whole new generation of SVG authors that neither know nor care
> about SVG scripting or animation. They are using Inkscape to make static
> SVG, which many argue should be the primary use case for a Web-oriented
> vector graphics language (obviously, I'm not one of those, but it is a
> valid argument). SVG as simply graphics in a Web page really does work
> right out of the box on FF... no need for a plugin that your workplace
> might not allow.
>
> Inline SVG works in FF. Now those HTML+SVG apps that only worked in IE+ASV
> before, using HTML input widgets, can work across the 2 major browsers
> (see Jonathan's example for how to do this)! Many simple WebApps now have
> the bar lowered for newbies who don't want to or can't make an SVG
> dropdown; this will result in a net gain of casual SVG users.
>
> Basically, FF with SVG makes SVG simply more *common*. And since it will
> improve with time, soon (a year or so, perhaps) it will be a perfectly
> acceptable platform for more advanced WebApps, too.
>
> Moreover, SVG in FF and Opera (neither perfect) raises the bar for other
> browsers (IE, maybe?) to start adhering to open Web standards, and will
> increase the demand for SVG. Maybe just a little at first, but it will
> grow. Heck, it might even have the affect of raising awareness about SVG
> such that more people will download the Adobe viewer.
>
> For these reasons, I think it was worthwhile for FF to release with the
> limited support for SVG. It is only a step back for those of us used to a
> near-complete specification. It is a major step forward for those who will
> discover SVG because of Firefox. And ultimately, that will help us all.
>
> You are dead right that it will hurt the previous works of SVG authors,
> but only until FF is improved. This will be a new ramp-up period for SVG,
> in some ways starting over. And I contend that with a more common SVG
> viewer, new, well-rendering content will quickly outnumber older content,
> and people will not be so quick to dismiss SVG once there is more good
> content out there. Remember, without a plugin, your excellent work, and
> that of other creators, does not render at all... in SVG, it shows that
> there is at least something there. And while the public is starting to get
> used to this "new" thing called SVG, we can all be creating new content
> that works well, and counting on FF to improve.
>
> p.s. Don't confuse Jonathan's politeness for insincerity. He's a stand-up
> fellow, and deserves a good deal of recognition and consideration for all
> he's done.
>
> Optimistically-
> Doug
>
> [EMAIL PROTECTED]
> www.vectoreal.com ...for scalable solutions.
>
--
Ronan Oger
Director
RO IT Systems GmbH
...Building Web2.0 with SVG since 2001
http://www.roitsystems.com
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/1U_rlB/TM
--------------------------------------------------------------------~->
-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
