- From: Shelley Powers <shelley.just@gmail.com>
- Date: Mon, 2 Nov 2009 07:47:35 -0600
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Don Brutzman <brutzman@nps.edu>, public-html@w3.org, Johannes Behr <johannes.behr@igd.fraunhofer.de>
On Mon, Nov 2, 2009 at 7:29 AM, Henri Sivonen <hsivonen@iki.fi> wrote: > On Oct 30, 2009, at 19:40, Shelley Powers wrote: > >> Being able to use X3D in an HTML serialization, based on the >> _precedent_ set by inclusion of SVG and MathML would be a very >> interesting discussion item. > > I don't see SVG and MathML setting a precedent for X3D. > > When support for SVG and MathML was added to the HTML5 parsing algorithm, > rendering SVG DOMs was already supported by 3 out of the top 4 browser > engines and the fourth also had support for retained-mode markup-based 2D > graphics (VML). So at that point in time, there was vendor consensus by > implementation behavior showing that retained-mode markup-based 2D graphics > were worth implementing and enabling SVG parsing in text/html was the > shortest path of enabling retained-mode markup-based 2D graphics in > text/html in the largest number of browser engines *given* what was already > implemented. > > Likewise, given what was already implemented in Gecko and Opera for MathML > DOMs, adding support for MathML in the text/html parser was the shortest > path of adding inline math support to text/html. (Furthermore, there's a > stronger case for why math should be inline than why either 2D or 3D > graphics should be inline.) > > In the case of X3D, there's no pre-existing native support in any of the top > 4 browser engines, so even if there were consensus that HTML should support > inline markup-based retained-mode 3D graphics, it wouldn't follow that X3D > being the format would be the shortest path to having the concept > implemented. There were two precedents set with the inclusion of SVG and MathML in HTML5. The first precedent was to potentially allow other XML-based content, including markup-based retained-mode 3D graphics. That doesn't mean all have to be included, or any will be included: it just means the fact that the specification is XML-based is not an automatic barrier against inclusion, inline, in HTML. The other precedent was to formalize a relationship between HTML5 and SVG, and HTML5 and MathML. I believe this is more in line with what the X3D folks are hoping. From the web site that Don referenced: --- We hope to trigger a process similar to how the SVG in HTML5 integration evolved: * Provide a vision and runtime today to experiment with and furthermore develop an integration model for declarative 3D in HTML5 * Get the discussion in the HTML5 and X3D communites going and evolve the system and integration model * Finally it would be part of the HTML5 standard and supported by every major browser natively --- > > (This email shouldn't be read to be for or against X3D. I'm just pointing > out that SVG and MathML don't set an applicable precedent here.) > > Shelley
Received on Monday, 2 November 2009 13:48:11 UTC