Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SVG interoperability
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.
>> 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.
> 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.
> 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.
> 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.
> 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.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
