HTML5 Recommendation Additions for Integrating X3D Graphics

Overview | Motivation | References | Suggested Additions | Open Issues | Related X3D Issues | Contact

Overview

This document presents suggested changes for integrating XML-based Extensible 3D (X3D) Graphics support in HTML5.

Our goal for HTML5 authors is to make the native addition and use of declarative X3D scenes as well-supported as that provided for Scalable Vector Graphics (SVG) and Mathematical Markup Language (MathML).

This document provides detailed technical rationales and specification recommendations for inclusion of X3D capabilities in HTML5.

This work is prepared and coordinated by the X3D Working Group with public discussion on the x3d-public@web3d.org and public-html@w3.org mailing lists.

Motivation

X3D has numerous benefits that make it a natural addition for documents written using HTML5, SVG and MathML.

• X3D is a royalty-free open standard for real-time 3D graphics communication on the Web.
• X3D is an interchange format for many 3D graphics technologies with well-defined run-time behavior.
• Many aspects of X3D design closely match the architecture of HTML and other XML languages.
• X3D scenes can be linked via Anchor elements or grown via embedded Inline elements.
• X3D scene authoring does not require programming expertise and can be accomplished by Web authors.
• X3D is designed for performance, device independence, user interactivity and internationalization (I18N).
• Web3D working groups are responsive, continuing to produce X3D Specification updates every 2-3 years.
• X3D has a long and stable evolution that originated with the Virtual Reality Modeling Language (VRML97).
• X3D maintains backwards compatibility while steadily adding new cutting-edge industry capabilities.
• X3D is well supported by many browser plugins, players, authoring tools and conversion tools.
• X3D implementations are widely available as either commercial products or open source.
• Quality assurance (QA) for X3D scenes includes DTD, XML Schema and Schematron validation.
• Conformance suites and numerous example scenes are available to test proper software compliance.

The provenance of X3D has many similarities to other World Wide Web Consortium (W3C) efforts. The royalty-free X3D Specifications are produced by working groups in the non-profit Web3D Consortium and approved by International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC).

References

• HTML5 working draft is a vocabulary and associated APIs for HTML and XHTML.
• X3D and HTML5 wiki page examines how to best integrate X3D with HTML5.
• X3D Specifications page provides the full set of of approved specification documents.
• X3D DTDs and Schemas formally define X3D syntax for use by any XML tool.
• X3D Resources provides numerous links to related and supporting material.
• Mailing list discussion archives: x3d-public@web3d.org and public-html@w3.org

Suggested Additions to HTML5 Recommendation for Integrating X3D

This section lists change suggestions to the HTML5 Recommendation that together add support for X3D graphics.

Editorially each change entry is structured to provide:

• A link to the appropriate section of the HTML5 draft
• A pertinent excerpt from the HTML5 draft, indented as a <blockquote>
• A specific change suggestion, again indented as a <blockquote>
• Each change is recorded as html source suitable for copying and pasting (or replacing) in the HTML5 draft document
• When an existing HTML5 section has been copied and adapted for X3D, irrelevant prior prose may be included in strikeout form for review comparison
• Open specification issues or discussion items (if any) and eventual resolution

Specific change suggestions to the HTML5 Recommendation follow.

a. Change to HTML5 section 3.1.4 DOM tree accessors

Change

HTML, SVG, and MathML elements define which classes they are in by having an attribute with no namespace with the name class containing a space-separated list of classes to which the element belongs. Other specifications may also allow elements in their namespaces to be labeled as being in specific classes.

to

HTML, SVG, MathML and X3D elements define which classes they are in [etc.]

b. Change to HTML5 section 3.2.1 Semantics

Note that HTML5 ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call. Discussion of relevant issues follows.

The proposed changes for HTML5 outlined in this document appear to show that centralized extensibility (i.e. formal inclusion of an external language as an addition to HTML5) is feasible for X3D. No showstopper issues have been found.

The submitters of this proposal recommend the formal inclusion of X3D in HTML5.

Note that the related HTML5 section 2.2.2 Extensibility states

"Vendor-specific proprietary extensions to this specification are strongly discouraged. Documents must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question."

and

When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognise the requirements of such an extension specification, it becomes an applicable specification for the purposes of conformance requirements in this specification.

If X3D is not approved as a vendor-neutral extension within HTML5, then

• Decentralized extensibility mechanisms for HTML5 documents will remain of interest as an alternative way to add XML-based 3D graphics authoring to HTML pages.
• Embedded X3D objects can still be used within HTML5 pages, albeit without the possiblity of creating single mixed-source documents.

The potential text/html serialization of X3D within HTML5 documents is seen as a mechanism for unambiguously mapping the resulting DOM5 tree to a correctly capitalized X3D tree that can be handed off to an X3D player. The following table shows the correspondence between XML capitalization and lower-case form of all X3D v3.2 elements and attributes: X3dElementsAttributesLowerCaseTable.txt

There is no desire by the Web3D Consortium to formalize or otherwise adopt the relaxed-case text/html encoding for X3D outside of the scope of HTML5 documents.

c. Change to HTML5 section 3.2.3.3 The lang and xml:lang attributes

This section contains the illustrative note:

(in particular, MathML and SVG allow lang attributes in the XML namespace to be specified on their elements)

Edit to include the X3D approach. For clarity have changed a long parenthetical section into separate sentences.

In particular, MathML and SVG allow lang attributes in the XML namespace to be specified on their elements. X3D uses the FontStyle element's language attribute for displayed Text element string values.

d. Change to HTML5 section 3.2.3.5 The dir attribute

This section describes an HTML5 element's text directionality.

No mention is made of SVG or MathML text directionality. It that is added (see bug 8594), then similar prose can be added for X3D such as

X3D uses the FontStyle element's horizontal, topToBottom, leftToRight and justify attributes to control the directionality of displayed Text element string values.

e. Change to HTML5 section 3.2.5.1.2 Flow content

Add a new link x3d to the list of links.

• x3d

f. Change to HTML5 section 3.2.5.1.5 Phrasing content

Add a new link x3d to the list of links.

• x3d

g. Change to HTML5 section 3.2.5.1.6 Embedded content

Add a new link x3d to the list of links.

• x3d

h. Change to HTML5 section 3.2.5.1.7 Interactive content

Wondering why svg and math elements are not listed under interactive content. Perhaps they should be? Perhaps X3D should be? If they are added (see bug 8595), add a link to the list of relevant elements as shown in preceding changes.

i. Change to HTML5 section 3.2.5.3 Paragraphs

This section includes the statement

Conformance checkers may warn authors of cases where they have paragraphs that overlap each other (this can happen with object, video, audio, and canvas elements).

Wondering why embed, svg and math elements are not also listed? If they are added (see bug 8597), then add a link to x3d as well.

j. Change to HTML5 section 3.3 APIs in HTML documents

Of relevant note is the following section:

Element.getElementsByTagName()
HTML elements match by lower-casing the argument before comparison, elements from other namespaces are treated as in XML (case-sensitively).

Specifically, these methods (but not their namespaced counterparts) must compare the given argument in a case-sensitive manner, but when looking at HTML elements, the argument must first be converted to ASCII lowercase.

Thus, in an HTML document with nodes in multiple namespaces, these methods will effectively be both case-sensitive and case-insensitive at the same time.

This approach appears to work fine for X3D.

k. Change to HTML5 section 4.8.16 SVG

Insert new X3D section after SVG section, renumber section 4.8.17 Dimension attributes as 4.8.18 Dimension attributes

4.8.17 X3D

The x3d element from the X3D namespace falls into the embedded content, phrasing content, and flow content categories for the purposes of the content models in this specification.

To enable authors to use X3D tools that only accept X3D in its XML form, interactive HTML user agents are encouraged to provide a way to export any X3D fragment as an XML namespace-well-formed XML fragment.

When the SVG foreignObject element contains elements from the HTML namespace, such elements must all be flow content. [SVG]

The content model for title elements in the SVG namespace inside HTML documents is phrasing content. (This further constrains the requirements given in the SVG specification.)

The semantics of X3D elements are defined by the X3D specification and other relevant specifications. [X3D]

The SVG specification includes requirements regarding the handling of elements in the DOM that are not in the SVG namespace, that are in SVG fragments, and that are not included in a foreignObject element. This specification does not define any processing for elements in X3D fragments that are not in the HTML namespace; they are considered neither conforming nor non-conforming from the perspective of this specification.

Of relevant note is that HTML bug 8238 examines element/attribute capitalization issues for X3D.

The following table shows the correspondence between XML capitalization and lower-case form of all X3D v3.2 elements and attributes: X3dElementsAttributesLowerCaseTable.txt.

The only noted ambiguity is the existence of a camel-case Color element and a lower-case color attribute. Since processing of elements and attributes gets handled by separate conversion tables, this special case does not appear to be a problem.

l. Change to HTML5 section 6.5.1 (Scripting) Introduction

Change

• Processing of technologies like XBL or SVG that have their own scripting features.

to

• Processing of technologies like XBL, SVG or X3D that have their own scripting features.

m. Change to HTML5 section 9.2.5.10 The "in body" insertion mode

Following the subsection which begins

A start tag whose tag name is "svg"

Add a new subsection which begins

A start tag whose tag name is "x3d"

Reconstruct the active formatting elements, if any.

Adjust X3D attributes for the token. (This fixes the case of X3D attributes that are not all lowercase.)

Adjust foreign attributes for the token. (This fixes the use of namespaced attributes, in particular XLink in X3D.)

Insert a foreign element for the token, in the X3D namespace.

If the token has its self-closing flag set, pop the current node off the stack of open elements and acknowledge the token's self-closing flag.

Otherwise, if the insertion mode is not already "in foreign content", let the secondary insertion mode be the current insertion mode, and then switch the insertion mode to "in foreign content".

n. Change to HTML5 section 9.1.2 Elements

Definition list includes

Foreign elements

Elements from the MathML namespace and the SVG namespace.

change to

Foreign elements

Elements from the MathML namespace, the SVG namespace and the X3D namespace.

o. Change to HTML5 section 9.2.5.1 Creating and inserting elements

Following the paragraph and table beginning:

When the steps below require the user agent to adjust SVG attributes for a token, [...]
[... Attribute name on token / element table ...]

Append prose as follows:

When the steps below require the user agent to adjust X3D attributes for a token, then, for each attribute on the token whose attribute name is one of the ones in the first column of the following table, change the attribute's name to the name given in the corresponding cell in the second column. (This fixes the case of X3D attributes that are not in mixed-case XML encoding.)

Also append table as found at X3dAttributesLowerCaseTable.html

p. Change to HTML5 section 9.2.5.21 The "in foreign content" insertion mode

Similarly, following the paragraphs and table beginning:

Any other start tag
If the current node is an element in the MathML namespace, [...]

If the current node is an element in the SVG namespace, and the token [...]
[... Tag name / Element name table ...]
If the current node is an element in the SVG namespace, adjust SVG attributes [...]

Append prose as follows:

If the current node is an element in the X3D namespace, and the token's tag name is one of the ones in the first column of the following table, change the tag name to the name given in the corresponding cell in the second column. (This fixes the case of X3D elements that are not in mixed-case XML encoding.)

[Insert table as found at X3dElementsLowerCaseTable.html]

If the current node is an element in the X3D namespace, adjust X3D attributes for the token. (This fixes the case of X3D attributes that are not in mixed-case XML encoding.)

q. Change to HTML5 section 9.3 Namespaces

Following the line which begins

The SVG namespace is: http://www.w3.org/2000/svg

Add a new line as follows:

The X3D namespace is: http://www.web3d.org/specifications/x3d

X3D action item: current X3D namespaces use versioned schema URIs (such as http://www.web3d.org/specifications/x3d-3.2.xsd). An X3D specification change will be needed to match any agreed-upon change in this namespace-identification convention. Further discussion of a proposed X3D namespace change is ongoing.

r. Change to HTML5 section References

The X3D Abstract Specification defines scene rendering and user interaction in a manner that can be implemented equivalently using various document encodings (XML, ClassicVRML, Compressed Binary) or programming-language bindings (ECMAScript, Java).

Add the following reference:

[X3D]

X3D Architecture and base components Edition 2, ISO/IEC 19775-1.2:2008. Web3D Consortium and International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), July 2008.

Note that multiple documents make up the X3D Specification. HTML5 use of embedded X3D utilizes the XML encoding and ECMAScript event passing. Therefore additional related references may also be appropriate:

[X3D-XML]

X3D encodings: XML encoding Edition 2, ISO/IEC 19776-1.2:2009. Web3D Consortium and International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), October 2009.

[X3D-SAI]

X3D Scene access interface Edition 1, ISO/IEC 19775-2:2006. Web3D Consortium and International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), July 2008.

[X3D-ECMASCRIPT]

X3D language bindings: ECMAScript, ISO/IEC 19777-1:2006. Web3D Consortium and International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), May 2006.

Open Issues

• Event passing. Need to document event-passing mechanisms between HTML5 scripts and X3D Scene Access Interface (SAI). This will primarily consist of documenting the X3D SAI correspondences and example communications between X3D nodes/fields and HTML elements/attributes.
• ID attributes. X3D attributes DEF, USE explicitly correspond to types id, idref. Does this need to be mentioned somewhere, perhaps in 3.2.3.1 The id attribute section?
• Titles. Section 3.1.4 DOM tree accessors. Whether to add prose regarding document title (for X3D WorldInfo element title attribute), similar to entry provided for SVG title attribute.
• Overlays. Typically an X3D scene occupies a rectangle of screen space via an HTML embed or object element. What about how to handle X3D (or SVG, or MathML) that may include background transparency and is overlaid as a layer above the HTML page? (Note that this form of transparency is different than that discussed in 3.2.5.2 Transparent content models and the corresponding HTML5 bug 8596: terminology name collision: "Transparent" content models.)
• Security. Are there any new or unique security considerations introduced by including X3D in HTML5? None are yet identified.

Related X3D Issues

• Ecmascript. We want to continue to ensure that specified versions of Javascript match. X3D refers to the ISO/IEC 16262:2002 version of ECMAScript, which apparently matches the ECMA-262 specification from December 1999 which is specified by HTML5.
  • HTML5 reference: [ECMA262] ECMAScript Language Specification. ECMA, December 1999.
  • X3D reference: [I16262] ISO/IEC 16262:2002, Information technology — ECMAScript language specification.
• X3D and DOM. The X3D specifications do not refer to DOM manipulation of an X3D document which is also a separate live rendered X3D scene graph.
  • Defining how to pass HTML5 DOM structure (i.e. the parsed text/html or xml version of the embedded X3D source) to an X3D player.
  • Likely a corresponding section will be needed in the X3D specifications to match agreed-upon HTML5 DOM semantics.
• Overlays. How to handle HTML (or SVG, or MathML) that is overlaid as a layer above an X3D scene? Note that HTML5 background can be fully transparent, and also that an individual HTML canvas can have alpha value transparency compositing). Are partially transparent backgrounds needed for full HTML pages, so that they might serve as annotation overlays?
• New textures. Similarly, shall we add SvgTexture and HtmlTexture to the X3D specifications for draping the 2D imagery on 3D geometry?

Contact

Questions, suggestions and comments about these issues are welcome. Public discussion occurs on the x3d-public@web3d.org and public-html@w3.org mailing lists.

Individual comments on this document can be sent to Don Brutzman (brutzman at nps.edu).

Available online at http://www.web3d.org/x3d/content/html5/HTML5RecommendationAdditionsForX3D.html (also in version control)

Revised: 7 January 2010