[
Lists Home |
Date Index |
Thread Index
]
Le lundi 19 juin 2006 à 13:42 +0200, Robin Berjon a écrit :
> On Jun 19, 2006, at 09:54, Eric van der Vlist wrote:
> > Le lundi 19 juin 2006 à 08:43 +0200, Robin Berjon a écrit :
> >> 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?
>
> Well it seems to be taking less time than it took for HTML or CSS to
> stabilise, but yeah, new technology in browser space means new
> interoperability issues no matter what technology you're talking
> about. We don't have any kind of silver bullet...
>
> >> 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?
>
> Not too worrying no, at least not yet. We'll see what comes of
> Microsoft's noises around SVG.
I meant worrying for IE users relying on a plugin which you call a dead
product. Of course, only Adobe can tell, bu what would happen if this
plugin stopped working with the next version of IE and/or Windows?
If your feeling is that this is a dead product (which I personally can't
tell), is it realistic for a web developer to roll out an application
that heavily rely on it for 80% of his/her 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?
>
> By "in general" I mean "across all browsers". Or more precisely,
> across all desktop implementations. In the mobile space, the
> interoperability of SVG is rather well achieved.
Good!
> > I have nothing against partial implementations but what I find hardly
> > acceptable is when these partial implementations are de facto
> > imposed to
> > web developers.
>
> But what do you propose we do instead? Start shooting browser
> developers in the kneecaps until they get their jobs done right?
>
> > 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.
>
> In the same way that previous browsers made using HTML, CSS, or
> Ecmascript much worse.
Not exactly in the same way IMO. People using HTML, CSS or Ecmascript
could hope that things would be incrementally improving. That doesn't
seem to be the case here with Firefox 1.5.
> > 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.
>
> I haven't investigated but I think there may be a way of telling
> Firefox to use a plugin no matter what.
I'll try to check that.
> > 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.
>
> That is no different from the track most Web technology has to go
> through. It's nothing new.
>
> > 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.
>
> That discussion took place many months ago before the release of FF
> 1.5. There were arguments both ways. However, it's too late to fix
> that now.
Too bad I can't spend all my time following all the things that can go
wrong :-( ...
> > 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...
>
> Down that path lies madness as one will then end up with UA branching
> all over the place.
Yes, that would be a risk.
Thanks for your analysis.
Eric
--
GPG-PGP: 2A528005
Freelance consulting and training.
http://dyomedea.com/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?=
|
