Re: SVG in text/html

Hi, Sam, Jonas-

Sorry, reading back, and seeing the responses to my email, I see I 
wasn't very articulate and I didn't get my point across (I was a bit 
sleep-deprived).  I'll try again by commenting on specific points by Sam 
and Jonas.  I hope I'm more clear this time.

Sam Ruby wrote:
> Doug Schepers wrote:
>> 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.
>
> I'd like to understand what you strongly disagree with.

What I disagree with is the notion that we have community consensus on 
how differences are resolved between SVG as XML and in text/html.  I 
think the responses to my email are pretty clear evidence of this, and 
reflect the views of many others who've chimed in on the list 
previously.  Let's not gloss these views over.


>It seems to me
> that you strongly disagree with something that you explain below, but
> not what I said above. What do you think the two DOMs mentioned above
> should look like?

I don't see an alternative to the DOMs being the same in that example. I 
attempted, clumsily, to expand on your simple example, and detail how 
this played out with a more complex (but still very simple) SVG snippet.


> And you *do* have a input in the matter. I'll go further and suggest
> that once I understand what you want, I'll try to help explain your
> position.

It's not my position, it's the position of a large percentage of the 
people who have responded on this matter.  I think the position is 
pretty clear already: the idea of well-formedness is being undervalued 
by the error-correction mechanisms in the HTML5 spec.

The SVG WG, including me, doesn't have a real problem with this error 
correction (or at least, we don't have a better solution); what I have a 
problem with is the implicit notion that because something *can* be 
error-corrected, that the non-well-formed code is of equal value.

The unclosed element in that example is treated as a parsing error by 
the HTML5 parsing algorithm, as it should be.  But other things that are 
equally problematic from the standpoint of SVG's original format, XML, 
are not treated in the same way, e.g. unquoted attributes.

Many people are uncomfortable with error-correction happening at all. 
I'm not asking that no error-correction take place; I'm simply asking 
that it be treated as what it is: error-correction.  The mechanism to do 
that would be to report parsing errors, when they are corrected.

I don't know that this is viable; maybe a real study of the performance 
consequences would show that it's not (though I don't believe that any 
such study has been done).  But it does seem like an approach that more 
people could live with: it provides the well-defined error-correction 
that has been been missing from HTML, and it does so in a way that is 
exposed to the developer for ease of correction (if the developer so 
chooses).

I don't intend to block forward progress based on this point.  To be 
honest, I think it's not a good use of the SVG WG's time to provide 
feedback when Ian already has his mind made up, even if I don't believe 
that he is citing real evidence to back up his decision.  What I see is 
this: one set of implementers and authors (the SVG WG) and the majority 
of the author and user community (in public comments) asking for some 
sort of preservation of SVG as an XML format, even if it's looser and 
error-corrected in practice, and a few implementers (Jonas and Lachy, 
most notably) disagreeing, and Ian giving preference to the minority 
opinion.  Maybe there is sound technical rationale for doing so, but I 
haven't been satisfied on that score.


>> Given this fragment:
>> <html><svg><g><circle ...><animateTransform ...><rect
>> ...><title></title></svg></html>
>
> I just want to be clear: you intentionally left off the close tag on the
> circle.

Yes, but as a representation of a typo or other mistake.


>> (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,
>
> That does happen if you forget to close the circle.

Yes, that is the DOM representation.  As I said, I don't see any way out 
of that.


>> 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"?
>
> As you know, I code my svg elements by hand. I often initially forget
> to close things, but generally am able to fix these things up before I
> publish.
>
> The point is that I see the problems that you describe all the time. It
> is entirely possible (and all to easy, I might add) to produce a
> well-formed but non-nonsensical DOM. In my case, I often use
> self-closing tag syntax when I don't mean to, so when I really want
> children I often get siblings.
>
> If the position is that non-nonsensical DOMs should not display at all,
> then I would assert that this position should also apply to XHTML. Do
> you disagree?

I don't think that necessarily follows.  XHTML was merely an adaption of 
HTML, in which there are very few rendering elements that are also 
container elements (<object> being one such exception).  In SVG, every 
element is a container element, leading to a very different language 
design and content structure.  As I've said before, just because 
something is suitable for HTML (whether text/html or XHTML, same 
language design, different wrapper) doesn't mean that it is suitable for 
SVG.

(As noted, <object> is one notable exception in HTML, and despite bad 
press, I think it works quite well.  It allows the author to provide 
child <param> elements to pass in data to the referenced content, and it 
allows the author to provide fallback content.)



Jonas Sicking wrote (on 3/26/09 1:55 PM):
> On Wed, Mar 25, 2009 at 6:09 PM, Doug Schepers<schepers@w3.org>  wrote:
>>  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?

Mine, the SVG WG (though strength of opinions vary), and many people who 
have posted on this issue.


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

I'm saying that evidence doesn't seem to indicate that there is such 
general agreement.


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

That's part of it.  The bone of contention is how to come back from 
those parse errors.  Implementers seems to have rejected out of hand 
(violently in some cases) the notion of a UI feature to allow access to 
the error-corrected resulting code (though maybe an API might be 
acceptable?).  Indication of error is another option, and if it's 
consistent, maybe the error console is enough... but right now, it's not 
consistent.  While unclosed elements are tagged as parse errors, 
unquoted attributes are not; someone made the argument that since 
browsers *can* recover from unquoted attributes, it shouldn't be a parse 
error, but that same argument can be made for unclosed attributes, or 
understood <html:tbody> elements, or any other markup convention that is 
error-corrected when it's put into the DOM.  At what point does "parse 
error" mean anything at all?


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

I'm neither supporting nor rejecting the idea that "tools will save us". 
  But the fact of the matter is that we do have to take existing tools 
into account.

Right now, there are authoring tools and SVG viewers that could read SVG 
"excerpts" (that is, inline SVG fragments that are removed from their 
HTML markup) if the content is in the canonical XML format.  Maybe in 
the future, Inkscape, Illustrator, CorelDraw, and BitFlash, Ikivo, and 
Renesis viewers could read the more lax syntax proposed.  In the 
meantime, we could rely on tools that extract and error-correct the SVG 
code.  But where are the rules for those conversion tools to know how to 
do the error-correction?  Isn't that a class of UA that also needs to be 
taken into account for the HTML5 spec, if we're talking about something 
that is meant to fit into a large ecosystem?

If so, it seems pretty clear to me that HTML5 should make all non-XML 
conventions used for XML-original code as parse errors, for at least 
some class of UA.  Or is HTML5 just a desktop browser spec?

Right now, there seems to be more handwaving at this point than I'm 
comfortable with.


> 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'm not sure what you mean by this.


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

Probably so for any given error, although the end result of development 
is more likely  not only to reflect the author's intent, but also be 
more usable for those who read the code later, to learn or to maintain it.


I appreciate that you are putting forth proposals to solve specific 
issues, such as the open CDATA and script questions.  If we can find 
specific fixes that address these concerns, I think we can satisfy more 
constituents (users and authors) that the future usability of SVG is not 
being whitewashed over.


Regards-
-Doug

Received on Monday, 30 March 2009 23:02:54 UTC