Re: SVG in text/html

I actually don't think I have as much of a problem with the
tag-closing aspect of the proposal as I do with the round-tripping to
SVG tools.

On 3/25/09, Doug Schepers <schepers@w3.org> wrote:
>  Given this fragment:
>   <html><svg><g><circle ...><animateTransform ...><rect
> ...><title></title></svg></html>
>

If someone types in your suggested fragment, they are trying to
produce a result.  When they analyze the results (visually, DOM
inspector, Firebug) they will realize they are doing something wrong
("dude, where's my rectangle?") and correct their code prior to final
publishing (by self-closing the animateTransform and adding a
</circle>, for instance).

In my mind, the person who is going to hand-author SVG-in-HTML fits
into one of three categories (with apologies to Mark Pilgrim [1]):

1) They don't know what they're doing.  Let's call these people Morons.

2) They know SVG-as-XML and are willing to type the namespace
talisman, properly case elements/attribute names, quote attribute
values and close tags.  They are ensuring that someone copying their
code will have the best chance of survival in the SVG ecosystem.
Let's call these people Angels.

3) They know HTML parsing and are able to cleverly author the content
so that the DOM produces a desired result even though the source may
seem ambiguous.  Their code is best studied through the lens of a DOM
inspector.  Let's call these people, um,  not-Angels? :)

Of these categories, only people in category #1 really have a problem.
 Unfortunately this is MOSTLY EVERYONE.  Fortunately I don't think a
lot of invalid svg fragments such as you have pasted will exist out in
the wild to be copied/learned from.

Regards,
Jeff

[1] http://diveintomark.org/archives/2004/08/16/specs

>
>  If people think SVG can be confusing now, what will they make of that? How
> is that useful in the least?  How does that make SVG more "usable"?
>
>  This severely decreases the learnability and usability of SVG in the wild.
> My only hope is that the people who think SVG will be commonly hand-coded
> are wrong, and that the vast majority of content (both SVG and HTML) is done
> with script libraries or graphical authoring tools, so that there is a
> minimum of misnested HTML+SVG content propagated.
>
>  I'm not trying to be negative.  I genuinely hope that this helps spread
> SVG.  But I fear that it will have exactly the opposite effect. Languages
> which are more tightly structured and tightly controlled (such as Adobe Air
> and MS Silverlight), but which have supporting infrastructures of authoring
> tools, commercial promotion, and aggressive distribution networks will have
> the advantage that they are dependable and intuitively predictable, while
> this makes SVG less intuitively predictable, and failing that
> infrastructure, makes it less attractive.
>
>  I think that the people who are arguing for this *particular* aspect of
> error correction (closing elements, not the unquoted attribute values, for
> example, which is relatively trivial) are familiar with HTML structure and
> coding, but don't have enough experience coding SVG content to realize how,
> for all but the most trivial uses of SVG, this will not be useful behavior.
>
>  Maybe the parse errors will be enough to let authors where they've made a
> mistake, and maybe they will be sophisticated enough to correct that before
> they put the content out.  But the pattern of HTML usage seems to indicate
> otherwise.  This gives casual authors just enough rope to hang themselves.
>
>  My preferred behavior is that the SVG in that case simply not render at
> all, removing the ambiguity that it is somehow "working" when it is not
> doing what the author should have been led to suspect.  Failing that, as a
> weak anodyne, the spec should say in clear language, in no uncertain terms,
> that such inline languages were not designed to be have unclosed elements,
> and that highly unpredictable behavior will result.
>
>  Regards-
>  -Doug Schepers
>  W3C Team Contact, SVG and WebApps WGs
>
>

Received on Thursday, 26 March 2009 03:49:40 UTC