Hi Demenico,
On 12/1/05, domenico_strazzullo < [EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have a few remarks,
>
> var fnt_size = parseInt(txttoformat.getAttributeNS(null,"font-
> size"));
> vs
> var fnt_size = parseInt(txttoformat.getAttribute("font-size"));
>
> These both work in Ffx 1.5. I read that
>
> > As pointed out several times already, Mozilla SVG and Batik are
> > stricter regarding invalid SVG elements, missing namespaces,
> > mimetypes
>
> Am I missing something? Or someone else is?
Some browsers, Mozilla included, treat the non-NS *attribute* methods as
being equivalent to the NS counterparts passed null. The DOM specs allow
them to do this, but don't prescribe the behaviour, so using the NS methods
for attributes as well as element is safer.
On another note, I am very concerned about the release of the svg
> implementation under it actual state. The implementors seem to worry
> a lot about the validity of the works and not so much about the
> validity of the renderer.
I don't think that's a fair statement. I guess the reason you think that is
because of my authoring doc and posts to this list etc. My concern has been
that the launch of SVG support in Fx 1.5 should be as painless as possible
for SVG content authors. To achieve that I felt it was not only necessary to
fix Firefox bugs, but also to provide fair warning (and fixes) to content
authors regarding the very widespread content errors that will cause SVG
content to fail in Fx, regardless of the completeness of its SVG
implementation. The latter task may have been more visible to most people,
but rest assured, our (my) primary concern and the focus of our work has
been and continues to be the implementation.
I would forward a motion for the removal of the automatic rendering
> ('lax' mode) for the greater public until the implementation is
> complete, not just "satisfactory". That is so subjective! The build
> is 1.5, but not in respect to the svg implementation. Only when the
> implementation reaches maturity (1.0) should it be transparently
> integrated.
"Complete" is also a very subjective word. The SVG specification is very
large, and it's next to impossible to create a truely complete
implementation. Details on what you miss would be helpful.
My worry is
> about the large public looking at those works misrendered or not
> completely rendered, no matter how good or bad they are originally.
I do realize that getting Firefox-svg out is a good mission for the
> svg world and that the time race is an important factor
> strategically, but at the same time a premature release means more
> arm than benefit. I'm very unhappy about it. I know the FF crew were
> using the works for testing.
We've not just been using it for testing. We poled the SVG community asking
whether the SVG support in Fx 1.5 should be on or off by default. The
majority of people replied "on". Since then we made it quite clear, I hope,
that we intended it to be on. If you read this list regularly I'm not sure
how you missed that. We have also made custom test builds, and publicised
the betas and release candidates so that people could test the support prior
to this release.
I am, of course, very sorry that you find that the SVG support is not up to
your needs. But as you yourself acknowledge, the decision was not an easy
one, and always going to result in some unhappy people, whichever way we
decided.
I've been asked to audit my works and I
> did so. Now I see improvements, but far from what one has the right
> to expect. The result is that the damage is done to the artists and
> programmers in the SVG community, not to the browser. If you don't
> trust me ask any designer, painter, musician, film maker, writer...
> Would you imagine a theater showing a movie to the millions where
> you randomly get the screen cut in half, tiny rectangles scattered
> all over, the actors all grouped in the top left corner, superposed
> perhaps, or you name it.
Those sound like rather nasty problems. Bug reports with testcases would be
helpful.
Publication is the uppermost step in the
> process of art production and one of its ultimate goals. Who needs
> to be published this way? Is this some kind of a joke? A browser is
> a public publisher. Is this a children's sandbox or a serious
> business? Once again, you don't do that kind of thing in the art
> world!
>
> Finally, let's not forget that many of the advancements we were able
> to make in svg have been possible thanks to ASV. Like Jonathan says,
> Adobe's DOM extensions were designed to palliate NS 4.7
> deficiencies, at a time when it was still popular. Let's not spit
> too much in the soup. Many or all of the works we were able to sell
> were only possible because ASV was (is) around.
I'm not sure what you're saying here with regards to Fx 1.5.
In conclusion, I too, applaud and have the greatest consideration
> for the work the Firefox guys are doing, but way way too many svg
> works use SMIL and many use some less common methods of the complete
> DOM2 subset. It's unconceivable to me to make the firefox svg
> implementation available to the general public until it renders SMIL
> and it has the complete DOM2 subset implemented.
What have you found to be missing from DOM2? Or do you mean the SVG 1.1 DOM?
Needless to say, I can technically sustain what I said above with
> the weight of tests and examples. I know many others can as well,
> for and against, and that can generate an endless debate. The thing
> is that SVG is an Art medium and no artist wants to see his/her
> creations misrendered. It's unacceptable. Artists and technicians on
> this list are concerned and should be consulted.
I don't think the desire for your content to be rendered as you intended it
is limited to artists. I would hope that most people who read this list with
any regularity would have noticed that we planned to release Fx 1.5 with SVG
support and taken the chance to test the pre-release builds.
My motion is for asking the immediate removal of 1.5 from the
> download page and the release of a 1.6 build with switchable svg,
> off by default.
Unfortunately for those who take your view I can't see that happening.
Pulling the rug from under everyone like that would result in a much bigger
outcry from those who take the oposite view. Besides that, the current
volume of SVG on the web is insignificant compared to the volume of other
content, making it very unlikely that the Mozilla Foundation would take such
a drastic step.
The option should also be accompanied by a notice
> specifying in non technical language the type and extent of
> limitations and how they can affect and damage the works displayed.
> Although I think the most sensible thing would be to not implement
> it until finalized.
>
See http://developer.mozilla.org/en/docs/SVG_in_Firefox_1.5
If the SVG support in Fx 1.5 is really so unusable for you, there are things
you can do of course. For example, since we support scripting you could put
a script in your SVG files that reloads a bitmap image in its place (or to
recreate whatever behaviour would currently occur if Fx 1.5's SVG support
were to be turned off). Such solutions are inconvenient, but if you feel
that strongly about people viewing your site with Fx 1.5 they'll be worth
the effort.
Jonathan
[Non-text portions of this message have been removed]
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/I258zB/QnQLAA/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/
