SVG in text/html

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'