Hi Doug,
Many thanks to you too for your kindness. I find your remarks also
valid. I wonder why though you too advance arguments that I never
disputed and that don't address directly the issue that I raised. If
anything those arguments are proposed to counterbalance the
negativity and make an average of the outcomes, positive and
negative.
I spent some time today to have a closer look. I could easily
identify a situation that provokes a browser crash.
Given an svg example as simple as this:
<g>
<g onmousedown="showSM('XmaspresentsMenu')">
<path fill="#f2f5e9" stroke="#606060" stroke-width=".5"
d="M0,0h240v18h-240z M94,0v18 M220,0v18"/>
<use xlink:href="#arrow" x="225" y="5.5"/>
<text x="6" y="13.5" pointer-events="none">Xmaspresents</text>
<text id="sel_th" x="210" y="13.5" pointer-events="none"
text-anchor="end">none</text>
</g>
<g id="XmaspresentsMenu" transform="translate(0 18)"
display="none">
<g onclick="setTheme(7);showSM('thMenu')">
<path fill="white" stroke="#606060" stroke-width=".5"
d="M0,0h240v20h-240z"/>
<text x="6" y="13.5" pointer-events="none">none</text>
</g>
<g onclick="setTheme(0);showSM('thMenu')">
<path fill="white" stroke="#606060" stroke-width=".5"
d="M0,18h240v18h-240z"/>
<text x="6" y="31.5" pointer-events="none">roller skates</text>
</g>
<g onclick="setTheme(1);showSM('thMenu')">
<path fill="white" stroke="#606060" stroke-width=".5"
d="M0,36h240v18h-240z"/>
<text x="6" y="49.5" pointer-events="none">svg implementation
debugger</text>
</g>
</g>
</g>
This file crashes the browser (for skeptics see screen shot at
http://www.dotuscomus.com/svg/FFtest/crash_scrn.gif). File for test
is here:
http://www.dotuscomus.com/svg/FFtest/FFtest.svg
Originally the "guilty" <g> container reads like this:
<g id="thSelect" transform="translate(708 336)" fill="#404254">
which explains it's presence. I took attributes out to eliminate all
doubts. What produces the crash is the bare fact that this structure
is being used:
<g>
<g>
...
</g>
<g>
<g>
...
</g>
<g>
...
</g>
<g>
...
</g>
</g>
</g>
The removal of the outermost <g> container (with or without
attributes) makes it work.
Is anyone actually proposing that rather than wait for fixes to
nasty problems in an immature implementation, hundreds of developers
should rewrite (totally rethink in same cases) works and
applications that conform to SVG 1.1 specification, and use its
capabilities, simply to accommodate for serious lacunae? Does anyone
still think that we should audit or provide elegant downgrading
solutions (from Ronan's subsequent post)?
I must say that I find all this very embarrassing and
counterproductive in that:
a) The browser crashes and users don't normally care to know why,
they simply consider it obnoxious. A legitimate remark that the more
aware user might make would be "this svg file made my browser
crash", and not "How could Mozilla implement an svg renderer that
messes up an svg file?".
b) Mozilla's reputation is penalized altogether, not just its svg
implementation. The SVG format, along with the guy who produced the
file, and Mozilla will pay a devastating tribute.
c) The probability, not to say certainty, of competitor vendors not
wanting to miss the opportunity to capitalize over the exposed
amateurism.
> 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.
Which I'm not confusing. I think I know how to detect arrogance. And
of course I appreciate his efforts and dedication, as I already
said, and I even gave him credits on http://www.dotuscomus.com/svg/
well upfront (for what it's worth) in spite of an earlier
manifestation of arrogance which I didn't consider, attributing it
to over excitement and fatigue. This brings me directly to Francis
Hemsher's post. Maybe some will be shocked by the term he uses,
which betrays exasperation. I too think I explained more than
clearly my unique point and this will be my last draw because I
don't want to appear like a Savonarola, but a few facts stand:
humility is the only valid way of learning; upon leaving school
that's when you really start learning (many writers); the more you
learn the more you become humble; quality of tutoring has been
constantly falling for the last 30 years, if not technically at
least humanistically; everybody complains about corporations
dominating politics yet most obey to corporative rules and most make
politics or talk politically; respect is a vague notion from the
past for some; way too many want to make things faster, in a
destructive competition, sacrifice quality and draw as much profit
(of any kind) as they can; the struggle for territory and sphere of
influence has reached the paradoxal level where it resumes to who
pisses furthest; titles count more than realities. Maybe this, among
other things, is what Francis Hemsher calls stupidity.
While writing this I could read Ronan's post and I agree with what
he says except with
> I strongly believe that if a commercial player regrets that
Firefox is missing
> a particular capability, then the commercial player should pay for
this
> support.
Ronan, I'm not regretting missing capabilities, I know that in any
number of moths the svg implementation for FF will be more than
satisfactory. I didn't ask for this project, but I'm happy it was
started. I cannot contribute to funding. I cannot contribute to its
development because 1) I don't know C++ well enough, 2) I think
students are in a better position for contributing, 3) I could
bypass the first two arguments, but I've given already.
Domenico
--- In [email protected], "Doug Schepers" <[EMAIL PROTECTED]>
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.
>
------------------------ 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/
