Re: SVG in text/html

Hi, Ian-

Thanks for doing this work, and for getting back to us so quickly. 
We'll review this and provide feedback as soon as possible.

We are particularly interested in investigating a single script 
processing model, but like you said, that is a longer thread.

Regards-
-Doug

Ian Hickson wrote (on 3/24/09 8:34 PM):
> I've made the following changes to HTML5:
>
>   * Uncommented out the XXXSVG bits, reintroducing the ability to have
>     SVG content in text/html.
>
>   * Defined<script>  processing for SVG<script>  in text/html by
>     deferring to the SVG Tiny 1.2 spec and blocking synchronous
>     document.write(). The alternative to this is to integrate the SVG
>     script processing model with the (pretty complicated) HTML script
>     processing model, which would require changes to SVG and might
>     result in a dependency from SVG to HTML5. Anne would like to do
>     this, but I'm not convinced it's wise, and it certainly would be
>     more complex than what we have now. If we ever want to add async=""
>     or defer="" to SVG scripts, then this would probably be a necessary
>     part of that process, though.
>
>   * Added a paragraph suggesting:
>
>     | To enable authors to use SVG tools that only accept SVG in its XML
>     | form, interactive HTML user agents are encouraged to provide a way to
>     | export any SVG fragment as a namespace-well-formed XML fragment.
>
>   * Added a paragraph defining the allowed content model for SVG<title>
>     elements in text/html documents. (I haven't made<switch>  work there,
>     since heycam didn't seem to think this was necessary and since SVG
>     doesn't currently allow it anyway. It's not clear that the use case
>     that would justify this is really ever going to be done anyway.)
>
>
> On the issue of making the HTML parser case-preserving or
> case-sensitive, given the feedback regarding the performance risks
> involved, I have not changed the spec in the manner suggested by the
> SVG working group proposal. For more details, see:
>
>     http://lists.w3.org/Archives/Public/public-html/2009Mar/0233.html
>     http://lists.w3.org/Archives/Public/public-html/2009Mar/0240.html
>
>
> On the issue of quotes being required around attribute values, the
> arguments given in the following e-mails seemed technically sound and
> argued for keeping the syntax consistent across vocabularies:
>
>     http://lists.w3.org/Archives/Public/public-html/2009Mar/0233.html
>     http://lists.w3.org/Archives/Public/public-html/2009Mar/0250.html
>
> I have therefore not made missing quotes be a conformance error.
>
>
> On the issue of allowing<svg>  to act as a root element, or even
> disallowing it but having requirements exclusively intended to handle
> this error, I have not added those requirements, for the reasons laid
> out in detail in this e-mail:
>
>     http://lists.w3.org/Archives/Public/public-html/2009Mar/0219.html
>
>
> On the issue of the<![CDATA[ ]]>  syntax, I have left the spec as it was
> before for MathML, which means<script>  blocks in SVG are not parsed quite
> the same as<script>  blocks in HTML. I don't think this is a huge deal,
> and it wasn't really clear what else to do. There doesn't seem to be a
> strong reason to support<![CDATA[ ]]>  in regular HTML, and not supporting
> it in SVG seems likely to make it hard to achieve the goal of having SVG
> in XML be directly copiable into text/html, and would cause all kinds of
> weird troubles (e.g. with scripts that use ">" but have it escaped). If we
> think it's worth it, though, I guess we could just drop<![CDATA[]]>
> support altogether and be done with it, and make<script>  and<style>  in
> SVG in text/html be treated as CDATA blocks. However, if we do this, we
> have to realise that we aren't going to achieve some of the original goals
> that were put forward (like supporting all SVG-as-XML in text/html).
>
>
> The SVG working group also put forward these suggestions:
>
> On Tue, 10 Mar 2009, Doug Schepers wrote:
>>
>>  * The SVG WG suggests that unless proven to be breaking lots of content,
>>  adding character encoding-detection for SVG files served as "text/html"
>>  based on<?xml encoding="..."?>. There would still be an issue with
>>  UTF-8 SVG documents lacking an XML declaration; perhaps the fact that
>>  the first open tag encountered in the document is an<svg>  tag could
>>  make the encoding guesser choose UTF-8 in this case?
>>
>>  * The SVG WG agrees that it may be useful to forego namespace
>>  declarations for the SVG and XLink namespaces (as well as certain
>>  others, such as MathML). However, we believe that rather than hardcoding
>>  the namespace prefixes, those prefixes should default to that namespace.
>>  We are not suggesting at this time that namespace declarations should be
>>  able to override that default in HTML5, but some future revision of the
>>  language may specify that behavior, and hardcoding limits the potential
>>  for future extensibility solutions.
>
> Unfortunately as noted in an earlier e-mail I did not understand them
> and therefore have not changed the spec in any way as a result of
> them.
>
>
> Regarding the topic of which specification the list of case fixups should
> be in, there are several possibilities.
>
> The ideal situation is for people implementing the text/html parser to
> simply have one document to read from which they can implement a fully
> conforming parser with minimal effort.
>
> So long as the HTML specification is actively maintained, doing this is
> easy, even with SVG changing regularly.
>
> If HTML were to stop being maintained, then this would become a problem,
> and instead we would want the HTML document to defer to the latest SVG
> spec and have that be maintained. However, if HTML is no longer
> maintained, it is presumably because the consensus is that the language is
> no longer interesting, and thus it is unlikely that new features will need
> to be added to it.
>
> Given that there is no plan to stop maintaining HTML, it seems wisest to
> continue along the current track. Should HTML stop being maintained, then
> the HTML spec could be errata'ed to point to SVG thereafter.
>
>
> On Tue, 24 Mar 2009, Cameron McCormack wrote:
>>  Ian Hickson wrote:
>>  >  Note that nothing stops a future version of SVG adding names and
>>  >  attributes to the list anyway, acting as a kind of errata to HTML
>>  >  itself, should it be found that the HTML working group at the time is
>>  >  no longer responsive to feedback of this nature.
>>
>>  Really?  This seems strange.  If HTML 5 makes various conformance
>>  requirements, and another spec (perhaps SVG itself, or a small SVG-in-
>>  text/html spec) makes some contradictory requirements, it wouldn't be
>>  possible to have a conforming implementation of both. HTML 5 goes to
>>  great lengths to define "sensible" conformant behaviour, that browser
>>  vendors will want to implement.  Why would you then want them, later on,
>>  to violate this?
>
> Because under this scenario, "the HTML working group at the time is no
> longer responsive to feedback of this nature", and therefore needs to be
> routed around.
>
> One could just as easily ask, in the opposite case of the table being
> maintained by the SVGWG, "what about if the SVGWG goes rogue and starts
> adding crazy tags to the list without responding to feedback from the
> HTMLWG about the advisibility of such additions?". In such a scenario, one
> woudl imagine an exasperated HTMLWG errata'ing the HTML spec to no longer
> point to SVG and to instead have an explicit table.
>
> Both scenarios are highly unlikely, and not worth considering, IMHO.
>
>
>>  It seems a shame to set up the HTML 5 spec to deliberately require
>>  implementors to violate it down the track when future SVG features are
>>  developed and implementors want to make them available in text/html.
>
> Any spec that expects to be updated is deliberately requires implementors
> to violate it down the track when future features are developed. I don't
> see how this is any different. That's why we update specifications and
> release new versions.
>
>
>>  Is the concern that if the SVG WG is the group publishing the table of
>>  SVG case folding names that we might make poor decisions, which HTML
>>  then would normatively require?  I would rather the table ends up in a
>>  separate, small specification, which would be more easily updatable than
>>  one as large as HTML (or SVG, for that matter).  This could of course be
>>  on the Recommendation track, and would thus be afforded with all the
>>  usual chances for review.
>>
>>  I am concerned that this is seen as a "turf war" of some sort, which I
>>  obviously don't want it to be.  If the table is in the HTML 5 spec, then
>>  the HTML WG is effectively the gatekeeper to any new SVG features
>>  (assuming they used mixed case names) being usable in text/html (which,
>>  IMO, will likely end up seeing more SVG content than SVG/XML). If the
>>  table is in a document produced by the SVG WG, then the HTML WG could
>>  say that that gives the SVG WG the ability to change how text/html is
>>  parsed without the direct involvement of the HTML WG.  Would having a
>>  separate document with the case fixup table being produced by both WGs
>>  be a way to avoid these issues?
>
> The only reason to keep the table in the HTML5 spec is ease of
> comprehension for implementors. The above scenarios assume bad faith
> participation of one or both working groups, which isn't really likely.
>
>
> On Tue, 24 Mar 2009, Erik Dahlstr�m wrote:
>>
>>  There is a part that gives the UA the option of doing case fixups for
>>  elements in future SVG specifications, that list isn't explicit.
>
> This is what I am concerned about. I think we need to ensure there is a
> single explicit list in the parser spec so that there is no ambiguity for
> implementors.
>
>
>>  I agree that providing links to the Element and Attribute appendices is
>>  a useful addition, and I've updated the proposal accordingly.
>
> I don't think this really provides the information in a form that is
> convenient enough for implementors. It is likely that people will miss
> elements and attributes, as I did when creating the tables initially.
>
>
> On the subject of SVG 1.2 elements not being yet in the list, I stopped at
> SVG 1.1 because that's what browser vendors told me they were planning on
> supporting at this time. I imagine that this will change as the more
> controversial issues in 1.2 are addressed (e.g. the<textArea>  vs CSS
> issue), but that's another thread for another time.
>
>
> On Mon, 23 Mar 2009, Doug Schepers wrote:
>>
>>  The SVG WG has followed the HTML Co-Chair's request and produced a
>>  modified version of some of the HTML5 proposal, with integrated changes
>>  called out via CSS styles, with links to the original wording [1].  The
>>  changes are not comprehensive, but do start to address some of our
>>  feedback.  We don't mind if the wording is changed to meet the needs of
>>  the HTML spec, but we would like the spirit of the changes to be
>>  honored.  If there is a particular problem, we'd like to discuss that in
>>  detail.  We hope that this wording helps clarify what we're looking for.
>
> As far as I can tell the two changes are the quotes issue and the issue
> regarding where the case fixup tables should be; please see the comments
> above for a further discussion on these issues.
>

Received on Wednesday, 25 March 2009 00:55:59 UTC