Diagrams in HTML

Please put ideas for what it should look like here.

Each example should have a green circle, with an embedded HTML table, and should say how to handle tokeniser errors and tree construction errors.

Hardcoded element names

 <p>
   Hello world.
   <svg viewbox="0 0 10 10">
     <circle x=5 y=5 r=5 stroke=green>
     <foreignObject> <table><tr><td>1<td>2<tr><td>3<td>4</table> </foreignObject>
   </svg>
 </p>

Tokeniser recovers from errors by ignoring them and moving on.

Tree construction recovers from errors by closing the <svg> element.

Extensibility Element (<ext>)

This is a possible generic extensibility point, for SVG and possibly MathML or other XML content. Naturally, any content placed in an <ext> element would have to be understood by the UA in order to render correctly, and more complex rules may need to be developed for specific kinds of interaction between the root document and the inline content, such as with script, CSS, etc. For some discussion, see the IRC logs.

(The <ext> element would have a name that doesn't clash with existing content. Inside you can use XML or another format.)

 <p>Hello world. 
    <ext>
       <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10">
          <circle x="5" y="5 r="5" stroke="green"/>
       </svg>
    </ext> 
 </p>

Unfortunately, whatever syntax we end up using, people will copy and paste it from documents that were written by competent authors that tested it against the new UAs, into documents written by authors who don't know about this, and who don't have the new UA, thus creating new "legacy documents" that use whatever syntax we come up with. -Hixie

I think this risk is minimal, since it clearly wouldn't work in the legacy UAs, and so the mistake will have less reason to propagate. -Shepazu

We should define a content model for where the <ext> element can occur, and if there are implications for different locations (such as inside a table, a paragraph, the head, etc). The simplest thing, at least for SVG (and probably MathML), would be that it would have the same restrictions as an <img> element. Also, there should be a default block model for <ext> in CSS.

Note that this is similar to IE's "XML islands" with the <xml> element. It's believed that there are some conflicts with the <xml> element itself, since it creates a separate document that is tied to the <xml> element in the DOM, but more research is needed.

The <ext> element could potentially be an implicit element, generated by the HTML5 parser on encountering a start tag of e.g. "<svg " or "<math ". That would save authors of having to type this extra element, but has a drawback in that it doesn't provide fallback content for legacy UA:s. -Ed

What's the error handling intended to be for this idea? How is embedded HTML handled?

Error Handling

The main options seem to be:

1. strict XML parsing (not favored by many)
2. very permissive error handling (as in HTML5); this idea is controversial and has many open issues, which should be detailed below
3. moderate error handling, as detailed in SVG Tiny 1.2
4. other ideas?

The chief risk with permissive error handling is that it would create content that is not compatible across different UAs, including mobile devices and authoring tools.

Tentative proposals:

• Tokenizer recovers from errors by ignoring them and moving on; for SVG, any element with errors is not rendered.
• Tree construction recovers from errors by closing the <svg> element, and not rendering any content after the error.
• Case folding is not supported within the main body of the <ext> element, though it would be within the <fallback> element.
• The tree builder would assign the appropriate namespace URI to the element nodes it creates.
• If the "/>" is not found at the end of an element, all subsequent element will be placed as child elements of the element (and thus not rendered) until a matching closing tag is found, or until the a matching root tag is found, or until the "</ext>" element is found.
• Unknown content is ignored
• Unquoted attribute values will be ignored (should the element also not be rendered?)

See a email by Henri Sivonen for comparison and contrast.

Embedded HTML

The case of content inside a <foreignObject> element could be subject to the parsing model of the root document. (Note that this is only a partial solution, and more thought and details are needed.)

For content outside <foreignObject>, it should follow the XML processing rules.

Fallback Behavior

This is an opportunity to get nice fallback behavior, as well.

Here's a possible suggestion, where the raster image would show in UAs that didn't support the <ext> syntax, and the SVG would show in those that did (and which support SVG). In UAs which support <ext> and not SVG, the fallback would also be the raster. The fallback content should be inside a wrapper element (<fallback>), so that you can have rich fallback options, such as an image map, a table, or whatever; in this case, I also include fallback CSS to hide textual content in title, desc, and text elements, but it may be desirable to leave this content as alternate text to the image, even including styling.

For MathML content, a conditional CSS override could allow for CSS styling of MathML elements for those that don't render MathML natively.

<html lang="en">
<head>
	<title>HTML Extensibility Test</title>

</head>
<body>
	<h1 id="test_of_extensibility">Test of Extensibility</h1>
	<p>This is a test of an extensibility point in text/html, with a fallback mechanism.</p>
	
	<ext>
		<fallback>
			<img src="anIsland.png"/>
			<style type='text/css'>
			   svg > * 
			   {
			       display: none;
			   }
		        </style>
		</fallback>
		<svg xmlns="http://www.w3.org/2000/svg"
		     xmlns:xlink="http://www.w3.org/1999/xlink"
		     width="100%" height="100%"
		     version="1.1">

			<title>My Title</title>
			<desc>schepers, 01-04-2008</desc>

			<circle id="circle_1" cx="75" cy="25" r="20" fill="lime" />
      			<text id='text_1' x='10' y='25' font-size='18' fill='crimson'>This is some text.</text>
		</svg>		
	</ext>

</body>
</html>

Make sure to test your proposals... :-)

<svg> as document element

This is not a syntax proposal but I'd like to able to have SVG graphics in text/html without the need to wrap it inside HTML and without having implied <html>, <body>, etc. (I being Anne.)

Rationale:

• It's often easier to generate text/html documents than other types of documents (Live DOM Viewer, PHP)
• It allows you to use text/html-style syntax for SVG graphics which makes authoring easy.
• It makes creating graphics that use features from HTML and MathML easier.

<svg viewbox="0 0 10 10">
  <circle x=5 y=5 r=5 fill=lime>
  <foreignObject> <table><tr><td>1<td>2<tr><td>3<td>4</table> </foreignOBJECT>
</svG>

It's not clear that authoring would be easier with looser error handling, and introduces the incompatibilities mentioned above. A safer approach would be to first introduce the more conservative syntax, then observe how it is used and specify from real-world use cases incrementally. It's also not clear how this is to be distinguished from SVG content with embedded HTML (MIME Type?). -Shepazu