Diagrams in HTML - Revision history

GPHemsley: +spec

2012-11-10T16:07:35Z

+spec

← Older revision		Revision as of 16:07, 10 November 2012
Line 1:		Line 1:
	{{obsolete}}		{{obsolete\|spec=[http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#svg-0 HTML Standard: SVG]}}

	Please put ideas for what it should look like here.		Please put ideas for what it should look like here.

Annevk: html has svg now

2012-11-10T15:42:19Z

html has svg now

← Older revision		Revision as of 15:42, 10 November 2012
Line 1:		Line 1:
			{{obsolete}}

	Please put ideas for what it should look like here.		Please put ideas for what it should look like here.

Line 43:		Line 45:

	<font color="red">''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''</font>		<font color="red">''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''</font>

	~~[[Category:Proposals]]~~

Annevk at 10:05, 31 May 2012

2012-05-31T10:05:44Z

← Older revision		Revision as of 10:05, 31 May 2012
Line 43:		Line 43:

	<font color="red">''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''</font>		<font color="red">''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''</font>

			[[Category:Proposals]]

Shepazu: /* Extensibility Element () */

2008-04-02T03:58:47Z

Extensibility Element (<ext>)

@@ Line 21: / Line 21: @@
 == 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 [http://krijnhoetmer.nl/irc-logs/whatwg/20080401#l-441 IRC logs].
+Moved to [[Extensions#Proposal_2:_Extensibility_Element_.28.3Cext.3E.29|Extensions]], since this is a potentially generic mechanism.
 ''Make sure to [http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Chtml%20lang%3D%22en%22%3E%0A%3Chead%3E%0A%09%3Ctitle%3EHTML%20Extensibility%20Test%3C%2Ftitle%3E%0A%0A%3C%2Fhead%3E%0A%3Cbody%3E%0A%09%3Ch1%20id%3D%22test_of_extensibility%22%3ETest%20of%20Extensibility%3C%2Fh1%3E%0A%09%3Cp%3EThis%20is%20a%20test%20of%20an%20extensibility%20point%20in%20text%2Fhtml%2C%20with%20a%20fallback%20mechanism.%3C%2Fp%3E%0A%09%0A%09%3Cext%3E%0A%09%09%3Cfallback%3E%0A%09%09%09%3Cimg%20src%3D%22image%22%2F%3E%0A%09%09%3C%2Ffallback%3E%0A%09%09%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%0A%09%09%20%20%20%20%20xmlns%3Axlink%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxlink%22%0A%09%09%20%20%20%20%20width%3D%22100%25%22%20height%3D%22100%25%22%0A%09%09%20%20%20%20%20version%3D%221.1%22%3E%0A%0A%09%09%09%3Ctitle%3EMy%20Title%3C%2Ftitle%3E%0A%09%09%09%3Cdesc%3Eschepers%2C%2001-04-2008%3C%2Fdesc%3E%0A%09%09%09%3Ccircle%20id%3D%22circle_1%22%20cx%3D%2275%22%20cy%3D%2225%22%20r%3D%2220%22%20fill%3D%22lime%22%20%2F%3E%0A%09%09%3C%2Fsvg%3E%09%09%0A%09%3C%2Fext%3E%0A%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E test your proposals]... :-)''

Shepazu: /* Error Handling */

2008-04-01T18:13:06Z

Error Handling

← Older revision		Revision as of 18:13, 1 April 2008
Line 68:		Line 68:
	* Unquoted attribute values will be ignored (should the element also not be rendered?)		* Unquoted attribute values will be ignored (should the element also not be rendered?)

	See a [http://lists.w3.org/Archives/Public/public-html/2007Oct/0158.html email by Henri Sivonen] for comparison and contrast.		See an [http://lists.w3.org/Archives/Public/public-html/2007Oct/0158.html email by Henri Sivonen] for comparison and contrast.

	=== Embedded HTML ===		=== Embedded HTML ===

Shepazu: /* Extensibility Element () */

2008-04-01T18:12:28Z

Extensibility Element (<ext>)

← Older revision		Revision as of 18:12, 1 April 2008
Line 44:		Line 44:

	<font color="red">''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''</font>		<font color="red">''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''</font>

			Note that we could specify exactly what flavors of markup must be supported by a UA, and which may be supported by a UA. This would be rather restrictive, but could improve interoperability of UA features, and would ensure that the proper DOM interfaces are available. For example, SVG and MathML must be supported, and FooML may be supported (or something).

	'''What's the error handling intended to be for this idea? How is embedded HTML handled?'''		'''What's the error handling intended to be for this idea? How is embedded HTML handled?'''
Line 78:		Line 80:
	This is an opportunity to get nice fallback behavior, as well.		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.		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, <canvas> and an accompanying <script> element, 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.		For MathML content, a conditional CSS override could allow for CSS styling of MathML elements for those that don't render MathML natively.

Shepazu: /* Fallback Behavior */

2008-04-01T18:06:00Z

Fallback Behavior

← Older revision		Revision as of 18:06, 1 April 2008
Line 81:		Line 81:

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

			''Note: as stated before, the names of the <ext> and <fallback> elements are subject to change based on existing element names in the wild.''

	<pre>		<pre>

Shepazu at 17:59, 1 April 2008

2008-04-01T17:59:24Z

← Older revision		Revision as of 17:59, 1 April 2008
Line 35:		Line 35:
	</pre>		</pre>

	''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''		<font color="red">''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''</font>

	''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''		<font color="red">''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''</font>

	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.		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.
Line 43:		Line 43:
	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.		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''		<font color="red">''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''</font>

	'''What's the error handling intended to be for this idea? How is embedded HTML handled?'''		'''What's the error handling intended to be for this idea? How is embedded HTML handled?'''
Line 138:		Line 138:
	</pre>		</pre>

	''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''		<font color="red">''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''</font>

Shepazu: /* Fallback Behavior */

2008-04-01T14:31:20Z

Fallback Behavior

← Older revision		Revision as of 14:31, 1 April 2008
Line 109:		Line 109:
	<title>My Title</title>		<title>My Title</title>
	<desc>schepers, 01-04-2008</desc>		<desc>schepers, 01-04-2008</desc>

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

Shepazu: /* Extensibility Element () */

2008-04-01T14:26:58Z

Extensibility Element (<ext>)

← Older revision		Revision as of 14:26, 1 April 2008
Line 22:		Line 22:

	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 [http://krijnhoetmer.nl/irc-logs/whatwg/20080401#l-441 IRC logs].		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 [http://krijnhoetmer.nl/irc-logs/whatwg/20080401#l-441 IRC logs].


	(The <ext> element would have a name that doesn't clash with existing content. Inside you can use XML or another format.)		(The <ext> element would have a name that doesn't clash with existing content. Inside you can use XML or another format.)
Line 61:		Line 60:
	* Tokenizer recovers from errors by ignoring them and moving on; for SVG, any element with errors is not rendered.		* 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.		* 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 [http://lists.w3.org/Archives/Public/public-html/2007Oct/0158.html email by Henri Sivonen] for comparison and contrast.

	=== Embedded HTML ===		=== Embedded HTML ===
Line 73:		Line 79:

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

	<pre>		<pre>