Re: SVG Feedback on HTML5 SVG Proposal

Hi Doug and the rest of the SVG WG

It is great to get your feedback and to see that it seems like the
HTML and SVG WGs seem to be getting closer to an agreement.

Please note that I'm only speaking for myself, and not for the HTML
WG, mozilla or anyone else.

There seams to be a few goals, or rather priorities, where I differ
from the SVG WG which leads me to different conclusions in a few
cases.

Specifically, the SVG WG seams to highly value the ability to copy
markup from a text/html document directly into a image/svg+xml
document. I instead think it's highly important that HTML authors will
be able to add SVG to their documents, and that doing so is not so
hard that they choose not to. I also think it's desirable that they
can not just create documents that render as desired, but that are
also valid. This is because having people write valid document is
likely to both result in the documents working as authors intended,
and work similarly across several implementations.

So just as the SVG WG values a small learning curve for people that
author SVG in XML today, I would like to minimize the learning curve
for people that author HTML in text/html today.

I do agree that the ability to copy from text/html into image/svg+xml
is desirable. However for me this takes a lower priority than
minimizing the learning curve. The main use case for copying content
that I can see is that all SVG tools today require image/svg+xml. So
if a user sees an image on the web and wants to edit it, he is
required to get a valid image/svg+xml file somehow.

An alternative way to allow authors to copy SVG from text/html into
image/svg+xml is through tooling. Cameron McCormack suggested hooking
in to the 'save image as' context menu that most browsers have today.
This is great since it's simple enough that you don't even have to be
a developer to use it. I also think that many developer tools expose
similar functionality. Just checked in Firebug and if you bring up the
context menu for a node inside firebug there are menu items for "Copy
HTML", "Copy innerHTML" and "Copy XPath". Seems like the first one
should change to "Copy SVG" when clicking an SVG element.

These priorities leads to a few different conclusions than the
proposal from the SVG WG. For example it seems better to use a case
folding tokenizer and parser, even in foreign content. Similarly empty
or unquoted attributes would not be parse errors. I'd also think it
would be very valuable for <script> and <textarea> inside SVG
fragments to be parsed as <script> and <textarea> in HTML (see
separate thread regarding the challenges here). Poorly nested tags
would of course still be parse errors, like they are in HTML.

I would like to better understand the issue with the case fixup table.
Is the concern here that such a table exists? Or that the table is
tied to the HTML5 spec (or HTML WG) which makes it harder for the SVG
WG to add new elements to new versions of SVG. If it's the latter,
maybe we could define it in such a way that the SVG WG could add
entries to the fixup table as new versions of SVG are developed.

There may be more issues in the SVG WGs proposal, but I have to spend
more time looking at the details before giving more feedback.

Best Regards,
Jonas Sicking

Received on Wednesday, 11 March 2009 01:29:26 UTC