[
Lists Home |
Date Index |
Thread Index
]
> That's probably the path followed by Microsoft in Windows Live Local,
> then.
Very possible.
>> The fact that several major players are using SVG in their web 2.0 apps
>> successfully indicates that it is at least the basis for a short term
>> strategy.
>
> I took a look at Windows Live Local and they seem to be using SVG only
> for rather minor tasks (like superposing driving directions on a map).
>
> Which other major players do you have in mind?
I know that under Firefox there are certain developments that Google was
working on for maps (they use VML under IE). I also know that they are
using png files so I don't remember where the SVG came in.
> My experience (and private feedback I have got so far) is rather with
> people giving up SVG with the arrival of Firefox 1.5 that has "broken
> their applications" and I'd prefer to give a more positive view of the
> situation!
Right. That kind of feedback is excruciatingly frustrating. On svg-dev
there were long discussions about Firefox "breaking their applications"
and I have to say that in almost all cases the applications were broken
to begin with. This is why Robin was so right in his comparison to the
browser wars of the mid 1990s. Adobe created the leading plugin for SVG
and most folks tried to make their code work. When it did they stopped.
Or worse, they published an article about how to use it and everybody
followed the wrong advice.
In general the common problems you see are common XML problems: e.g.,
wrong mime-type, missing namespace declaration [1]*, incorrect DOCTYPE
decl. Also Adobe did a bit of interpretation on the specs and added
"get" and "set" prefixes to most property items in the SVG DOM (making
it incompatible with compliant implementations).
Again, if people had created 100% compliant code then they would have
run into one or two problems in the form of bugs or unsupported
features. In truth, I have seen several very large applications be
updated within hours-- I haven't seen anything yet that was a show-stopper.
Probably the most nettlesome bug for FF 1.5.x is the problem of timing
and establishing the rendering box model for access in script. FF 1.5.x
requires a first render before functions like getBBox will return valid
results. This is a known bug and will be fixed (I'm told) but not for a
while. Luckily, instead of using onload directly you can put a
setTimeout into onload to call your initialization code. Again, its a
bug but there is a workaround. It wouldn't keep me from building an SVG app.
In terms of Microsoft, my outsider's perspective is that they are making
a bet on XAML and Vista and will support SVG as needed and as useful.
This is purely a guess though.
[1] * In the SVG 1.0 and 1.1 DTDs the xmlns "attribute" has a default
value-- but Firefox does not apply this default in the case of a missing
DTD or incorrect DOCTYPE decl.
Cheers,
Jeff Rafter
>
>> In terms of detection in FireFox, my guess is that you could design your
>> page to be embedded in HTML (using the description from the SVG Wiki)
>> and insert a simple detection script. Adobe supports a lot of
>> non-standard script functions so a detection script in a try catch would
>> be fairly easy. In the case of a single SVG page-- UA detection is
>> simple regardless (and is used fairly often when trying to work with
>> some of the ASV3 bugs).
>
> Yes, that could be an option.
>
> Thanks,
>
> Eric
|
