X3D and HTML5
Goals: X3D and HTML5
Our goal is to make the native authoring and use of declarative XML-based X3D scenes as natural and well-supported for HTML5 authors as the support provided for Scalable Vector Graphics (SVG) and Mathematical Markup Language (MathML).
This effort has strategic importance for Web3D and indeed for all 3D graphics, since X3D is an interchange format for a wide variety of models. We intend to establish a solid foundation for X3D to properly support 3D graphics in HTML5.
Our technical proposal HTML5 Recommendation Additions for X3D is now online and available for comment.
We are also considering three basic approaches to display an X3D scene inside an HTML page.
- (External reference) HTML page includes an object element tag that refers to an .x3d scene, implemented via an X3D plugin. Data might be passed within the page using DOM events.
- (X3D as XML in HTML) HTML page directly includes X3D source, likely with an XML namespace prefix, presumably implemented via an X3D plugin or the browser itself. Again data might be exchanged within the page using DOM events.
- (API access) HTML page includes some form of canvas (or maybe
Canvas3D) element that allows programmatic access to the page, so that X3D Scene Access Interface (SAI) might draw a bitmap
Variations on these approaches are considered as part of X3D and HTML5 examples.
Important new work includes the X3DOM suite by Fraunhofer, which shows native X3D within an HTML page, runnable in nightly builds for Chrome, Firefox and Safari. A second implementation is in progress, and similar solutions are being pursued for Internet Explorer and Opera.
Our X3D and HTML5 Summary slideset was presented at the HTML5 Working Group sessions Friday 6 November 2009 in Mountain View during the W3C Technical Plenary and Advisory Committee (TPAC) meeting. As a result we are now actively working on showing X3D as XML in HTML.
The HTML working group page states:
What is HTML? HTML is the publishing language of the World Wide Web.
The latest editor's draft Hypertext Markup Language (HTML) recommendation states:
HTML 5 W3C Working Draft A vocabulary and associated APIs for HTML and XHTML
13.2 Declarative 3D scenes Embedding 3D imagery into XHTML documents is the domain of X3D, or technologies based on X3D that are namespace-aware.
4.8.5 The object element The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin.
4.8.6 The param element The param element defines parameters for plugins invoked by object elements.
We are working on the following tasks.
- Ensure that all HTML5 questions and issues relative to X3D are properly considered and answered.
- Document how native X3D in .xml encoding can be best be embedded inside an HTML5 document, typically in a namespace-aware fashion
- Demonstrate X3D+HTML5 examples on the Web3D Consortium website
- Examine how X3D pertains to related HTML5 tags (such as object and canvas) that are used for plugin-type content
- Track MIME type issues
- Examine overall interoperability issues: combined X3D and HTML content with one floating over the other
- X3D scene with transparent background floating over HTML document or desktop
- HTML text overlay laid out over an X3D scene as help
- Identify API issues of mutual interest (such as DOM, Ajax and XHR) for further developmental work
- Consider direct integration of Scalable Vector Graphics (SVG) images as a supported format for X3D ImageTexture node
- Maintain this X3D and HTML5 wiki page to track issues and progress
- Identify people in HTML5 working group who want to collaborate with us on these issues
- Report on efforts regularly to firstname.lastname@example.org mailing list and in our every-other-week X3D working group teleconferences
- Discussions to occur on the email@example.com mailing list and firstname.lastname@example.org mailing list
- Other tasks and efforts as needed
Relevant HTML5 and W3C information:
- HTML Working Group especially Membership and Participation
- World Wide Web Consortium (W3C)
- W3C Process Document
The following individuals have volunteered to serve as X3D Working Group representatives in the HTML5 Working Group.
- Johannes Behr, Instant Reality, Fraunhofer Research, Darmstadt Germany
- Don Brutzman, Naval Postgraduate School (Web3D-W3C liaison and W3C Advisory Committee representative), Monterey California USA
- John Stewart, FreeWrl, Communications Research Center (CRC) Canada
- Joe Williams, HyperMultiMedia, Santa Rosa California USA
Any other Web3D Consortium members who are interested in serving as one of our X3D Working Group representatives is asked to review the HTML working group membership materials, notify the X3D working group that you are interested, and describe what your goals will be.
Our weekly X3D and HTML5 teleconference is usually 0800-0900 (pacific time) each Tuesday.
Designated members can participate Web3D HTML5 teleconference call.
Minutes are saved on the X3D server, and are now distributed on the X3D-Public mailing list:
X3D and HTML4
- HTML Object Tag for X3D shows how to place X3D objects within an HTML page
- newHtmlPageWithX3dObject.html is an example HTML scene with X3D object tag to copy, edit and reuse.
- X3D Abstract Specification
- X3D Scene Access Interface (SAI) Edition 2
- 6.3.13 importDocument service is a utility request to import a W3C DOM document or document fragment and convert it to an X3D scene.
HTML4 and XHTML
- HTML Design Principles
- 4.8 Embedded content
- 4.8.1 The figure element represents some flow content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning.
- 4.8.2 The img element represents an image.
- 4.8.3 The iframe element represents a nested browsing context.
- 4.8.4 The embed element represents an integration point for an external (typically non-HTML) application or interactive content. (See HTML issue embed element should be deprecated)
- 4.8.5 The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin.
- 4.8.6 The param element defines parameters for plugins invoked by object elements. It does not represent anything on its own.
- 4.8.7 The video element represents a video or movie.
- 4.8.8 The audio element is a media element whose media data is ostensibly audio data.
- 4.8.9 The source element allows authors to specify multiple media resources for media elements. It does not represent anything on its own.
- 4.8.10 Media elements are used to present audio data, or video and audio data, to the user.
- 4.8.11 The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.
- 4.8.12 The map element, in conjunction with any area element descendants, defines an image map. The element represents its children.
- 4.8.13 The area element represents either a hyperlink with some text and a corresponding area on an image map, or a dead area on an image map.
- 4.8.14 Image maps allows geometric areas on an image to be associated with hyperlinks.
- 4.8.15 MathML from the MathML namespace falls into the embedded content category for the purposes of the content models in this specification.
- 4.8.16 SVG from the SVG namespace falls into the embedded content category for the purposes of the content models in this specification.
- 4.8.17 Dimension attributes
Canvas for 2D and 3D
- Canvas 2D API 1.0 Specification W3C Editor's Draft highlights SVG goals and approach
- Mozilla Canvas:3D proposal
- Firefox Canvas3D is a prominent possible approach
- Canvas 3D Rendering Demo appears to show another way to do things
- Java3D Canvas3D is an established API, though not directly related to HTML
- Sam Ruby's blog discusses HTML5 Distributed Extensibility and X3D
X3D and HTML5 Examples
The X3D and HTML5 examples page shows a set of examples ranging from simple to sophisticated.
API details under discussion
We have discussed Johannes' message of 25 March 2009 + responses (Subject: Re: Khronos Press Releases etc.) that included an X3DOM-connector.pdf diagram regarding how X3D might work with DOM, HTML etc. Also discussed the thread on Khronos' presumed upcoming work on Canvas3D element, and past work on Ajax3D.
These and other API topics are all technically related, and of interest, but have varying degrees of maturity.
The primary objective of the current effort is to support X3D and HTML5. Further work on DOM and other APIs is likely to evolve and spin off from this central effort.
The object element represents external resources like pdf-documents, movies or x3d-worlds. This plugin model works nicely for isolated content and applications which are unrelated to the surrounding xhtml-document. If the web-application developer would like to access and manipulate the object content he or she has to deal with object or plugin specific interfaces. e.g. X3D browser should provide a Scene Access Interface (SAI).
The X3DOM model tries to ease the development of applications by not providing a special interface but following and respecting some basic xhtml rules:
1) Declarative XML content is part of the DOM tree; Embedded with a separate xml namespace
<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <body> <x3d:x3d xmlns:x3d="http://www.web3d.org/specifications/x3d-3.0.xsd"> <x3d:Scene> <x3d:Shape><x3d:Box x3d:size="4 4 4" /></x3d:Shape> </x3d:Scene> </x3d:x3d> </body> </html>
2) The DOM elements can be used to read and manipulate the content
3) Events can be used to interact with the content
4) The position of the content in the document defines the position of the visible elements
The X3D element should also define the position where the content will be integrated into the html page. Simular how e.g. SVG or canvas works. A decoupled mechanisms will confuse application developer
The X3DOM model should be implemented as native browser feature, simular to SVG, in the future. Current test-implementation utilize the object/SAI model internally. In addition test-versions based on the Canvas3D layer exist. Both need a browser-extension right now to synchronize and update the DOM changes
Fallback model (how an HTML browser can choose an X3D implementation) is available here: x3dom-fallback-model.pdf
Some topics might become relevant once HTML5 is established as a formal W3C Recommendation. These are not part of our current planned work.
- Publishing X3D Specifications in HTML5
- Other topics as needed