On 10/6/05, Francis Hemsher <[EMAIL PROTECTED]> wrote:
>
> I'm willing to meet MOZ halfway...If they recognize that, not just
> myself, but many others need a means of FF accepting their current
> ASV efforts, not totally ignoring their creations.


I'll be frank. I'm a little pissed of here. I don't mind taking part in
genuine discussions, and answering genuine questions like benamou and
richard's, but this just gets on my nerves. Several people have gone to
considerable lengths to explain why this shouldn't and won't happen. Several
people have taken the time to write you code that will provide you with a
means to get your content working in standards compliant SVG
implementations. But you've decide you're above all that and can ignore
everyone's efforts and input. Have you even read what people have written,
or looked at the code they took the time to write for you?

The DOM specification is clear. We will not be breaking it for the reasons
that have already been made clear. I think it's very interesting that you
ignored the advice you were given two years ago to prepare for the future by
using the correct namespace aware methods. Now you're reaping the cost of
your "anti future" stance. Don't come crying asking moz to "meet you half
way". Is it regretable that much of the content already out there that has
been written to ASV rather than the standards won't work in Moz? Yes. It is.
I'm sorry for everyone out there who genuinely didn't know any better when
the wrote for ASV. But unfortunately the situation is now stuck as it is.

As well as contributing my unpayed time to help improve MozSVG, I've spent a
lot of my own time helping authors get their SVG to conform to the standards
and work cross-browser. I've also spent time writing docs explaining
potential problems and how author's can resolve them. Many others have, and
continue to do the same. How about you do something positive here and help
spread awareness of the issues so others don't fall into the trap you did
Francis? How about you at least follow and point out the few pieces of
advice at:

 http://jwatt.org/svg/authoring/

to others? It will be a lot more constructive and helpful for the success of
SVG than your current stance. At lease stop with the rude, antagonistic,
abrasive and inflamitory emails that have come to be your hallmark. All of
this no doubt turns away people who come to this list still not sure if SVG
is for them, and in the long run it harms the success of SVG.

If MOZ incorpoates a parsing process that recognizes this, then I
> will bust my butt to work with them on the browser/viewer
> communication, and probably help a hell of lot in that area.


What's wrong with the browser/viewer communication, and in what way could
help with it?

Otherwise, I will not consider FireFox as an environment for my work
> at this time.


That's your choice. Others won't make the mistake of throwing away almost
100 million potential viewers because they had to make some fairly trivial
changes to their code. (search and replace!)

Regards,
Jonathan

Regards,
> Francis
>
>
>
>
> --- In [email protected], Jonathan Watt <[EMAIL PROTECTED]>
> wrote:
> > On 10/6/05, Robin Berjon <[EMAIL PROTECTED]> wrote:
> > >
> > > Jonathan Watt wrote:
> > > > But what if you go against these
> > > > instructions? What if you use createElement instead of
> createElementNS
> > > in
> > > > your SVG documents? What should happen? Is it possible that it
> could
> > > create
> > > > an element in the same namespace as the element you called it
> on? Well
> > > yes.
> > > > Probably it is. The specifications don't say what the
> namespace ignorant
> > > > methods should do. That's why it says not to use them.
> (Probably the DOM
> > > WG
> > > > when discussing what should happen couldn't come to an
> agreement, so
> > > they
> > > > left it unspecified, making it possible to get into the mess
> we find
> > > > ourselves in now.)
> > >
> > > [sfx: coughing bordering on choking]
> >
> >
> > Careful Robin. I want a SVG 1.1 errata, so don't go dying on me! :-
> )
> >
> > From the DOM 3 Core spec: "A new Element object with the nodeName
> > > attribute set to tagName, and localName, prefix, and
> namespaceURI set to
> > > null." That's what createElement() returns. For setAttribute()
> things
> > > are less directly limpid, but it still says "To set an attribute
> with a
> > > qualified name and namespace URI, use the setAttributeNS method".
> > >
> >
> > What DOM 3 Core spec? Ooooooooh...DOM 3 Core is finally a REC!! I
> don't know
> > how that slipped under my radar. Well, what I said is correct for
> DOM 2
> > Core. I just hadn't noticed DOM 3 Core had arrived (some 18 months
> ago or so
> > no less) and set all this in stone. Probably because I'm busy with
> SVG 1.1,
> > which has DOM 2 as its normative reference.
> >
> > So, basically everyone should read Robin's post. This decision has
> been
> > made, and there's no chance this will change now, for better or
> for worse.
> > We're going to have to get used to it.
> >
> >
> > [Non-text portions of this message have been removed]
>
>
>
>
>
> -----
> 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
>
>
>
>
>
>
>
>
>


[Non-text portions of this message have been removed]



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/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/
 




Reply via email to