Re: SVG in text/html

On Wed, Mar 25, 2009 at 6:09 PM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Sam-
>
> Sam Ruby wrote (on 3/25/09 3:04 PM):
>>
>>  From what I can see, there is agreement that the desired behavior for
>> user agents (in particular browsers) which encounter inline SVG in
>> content served as text/html is to treat the following as identical:
>>
>> <svg xmlns='http://www.w3.org/2000/svg'><circle r='20'/></svg>
>> <svg><circle r=20></svg>
>>
>> I don't sense that there is any remaining disagreement on this point. If
>> I'm wrong, please correct me as that is more fundamentally important
>> than the point I explore in the remainder of this email.
>
> Actually, I strongly disagree, and while I see the SVG WG doesn't seem to
> have much choice in the matter, I think this is a huge mistake.
>
> Given this fragment:
>  <html><svg><g><circle ...><animateTransform ...><rect
> ...><title></title></svg></html>
>
> This is the resulting tree:
>  <html>
>  <svg>
>   <g>
>    <circle ...>
>     <animateTransform ...>
>      <rect ... >
>       <title></title>
>      </rect>
>     </animateTransform>
>    </circle>
>   </g>
>  </svg>
>  </html>
>
> (Albeit with parse errors.) This results in a rendered circle that is
> animated.  The rectangle is not rendered.  It's not clear whether the title
> belongs to the circle or the rect.  If these had been self-closing elements
> had been closed properly,
>
> 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.

Is this your opinion, or the opinion of the WG?

Your email actually surprises me. I did think there was at least a
general agreement that inproperly nested tags should be considered a
parse error, but still be parsed and produce a DOM which is then
rendered.

Are you saying that there is no such general agreement, or that there
is, but you don't agree with it?

>From my understanding the main remaining disagreements centered around
what should be considered parse errors in a validating implementation,
and what isn't. For example if casing different from what SVG-in-XML
uses, or unquoted attribute values, is a parse error or not.

> 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.

This particular downside of not using more fatal error handling I am
not worried about at all.

The work flow that Flash/Air/Silverlight offers is something like this:

* Use a tool to create content. This tool is often proprietory.
* Use a tool to open other peoples content to see how they did it.

This exact behavior works just as well with HTML and tag soup. As long
as you use tools, it does not matter how un-well-formed your content
is, as long as all tools parse it into the same DOM. In fact, as long
as you are using tooling, as a user you don't even need to notice that
the content you opened in your tool is riddled with parse errors.

However, with HTML you also have the following options available:
* Use any of the myriad of tools available for creating HTML.
* Use a text editor to create content.
* Use server side scripts to create content.
* Use a text editor to inspect other peoples content to see how the did it.

In these cases I agree it does matter how well formed the content is.

So while I do think there are advantages to people producing well
formed content, and thus advantages to requiring well formed content,
I don't think competitive advantage over Flash/Air/Silverlight is one
of them.

And of course there are downsides of requiring well formed content,
such as making using a text editor or server side scripts to create
content less likely to produce pages that don't render as intended.

> 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.

I do agree that the error handling for non well formed content is less
likely to produce the rendering that the author intended in SVG than
it is in HTML. However, not rendering anything, or just rendering
things up to the error, is IMHO even less likely to be what the author
intended.

/ Jonas

Received on Thursday, 26 March 2009 17:57:29 UTC