[
Lists Home |
Date Index |
Thread Index
]
Le lundi 19 juin 2006 à 08:43 +0200, Robin Berjon a écrit :
> On Jun 15, 2006, at 11:55, Eric van der Vlist wrote:
> > Am I missing something or is cross-browser SVG interoperability
> > still a
> > dream?
>
> As usual with interop issues, you can figure out how to make it work
> by targeting the least advanced/most buggy implementation, in this
> case Firefox.
Like in the worse days of browsers war, you mean?
> > For the upcoming book on Web 2.0 (http://web2.0thebook.org/) that I am
> > writing with a bunch of very smart people, I have done some a
> > couple of
> > simple tests which seem to indicate that the Adobe SVG plugin is still
> > far away and that native support in Web browser often means silent
> > failures when a feature is not supported (which can arguably be
> > considered as worse than suggesting to install a plugin like we do
> > when
> > there is no support at all).
>
> The Adobe plugin is indeed far away, but far away *behind*. Its
> numbers have apparently started decreasing rather regularly. It's a
> dead product anyway.
Isn't it that worrying for SVG knowing that this is still the main (if
not only) option of IE users that represent about 80% of web users?
> In general, SVG interoperability got worse before it started going
> better, due to the fact that three major browsers entered the fray of
> implementation.
By "in general", do you mean for non IE users and are IE users supposed
to wait an hypothetical IE 7.2 supposed to support SVG (according some
non official blog entries) with a fading Adobe plugin support?
> That's a good thing of course, but it causes some
> amount of chaos when it begins. If other browsers manage to catch up
> as fast as Opera seems to do (going from very fragmented small pieces
> of support in v8.5 to almost everything in v9) it might not take long
> for greater interop to show. In the meantime, just stick to what
> Firefox can do. It's not much, but it's a useful start. And you can
> make up for its lack of animation support by using the SmilScript
> library.
I don't think I have been clear enough...
I have nothing against partial implementations but what I find hardly
acceptable is when these partial implementations are de facto imposed to
web developers.
One of my point is that for web developers who have developed SVG
applications following the recommendation, Firefox 1.5 is making things
much worse.
Before Firefox 1.5 it was possible and easy to use a <noembed> element
to suggest to your users to download a plugin.
When your users upgrade to Firefox 1.5, they will very probably not be
able to render your SVG pages any longer and, what's worse, these
failures are silent, there is no warning of any kind that mention that
the browser has found features that it can't render and no way for a web
app to detect that and suggest to install a plugin and disable native
SVG support.
Of course, all this is documented but 99+% of users don't even know what
SVG is (and of course they don't have to) and will just think that the
page they are loading is broken.
To me, it would have been far better to disable native SVG support by
default and/or to display a warning when an unsupported feature is found
and/or to ask if the plugin shouldn't be used when an unsupported
feature is found and a SVG plugin has been installed.
An other option would have been to activate native support of SVG
documents with a moz:version attribute or something similar showing the
the document has been designed to be displayed in Firefox...
Eric
--
GPG-PGP: 2A528005
Weblog:
http://eric.van-der-vlist.com/blog?t=category&a=English
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
|
