Difference between revisions of "X3D V4 HTML Integration Requirements"

From Web3D.org
Jump to: navigation, search
Line 16: Line 16:
 
## X3D V4 at http://www.web3d.org/x3d4
 
## X3D V4 at http://www.web3d.org/x3d4
 
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development
 
## X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development
 +
 +
== Candidate Requirements ==
 +
 +
=== Looks "like" HTML ===
 +
: Elements (nodes in X3D-speak) shall be case independent
 +
: Attributes (fields in X3D-speak) shall be case independent
 +
: X3D nodes shall not have name conflicts with any HTML-defined elements
 +
:: I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names ?
 +
:: In that case, each node would be aliased with a HTML5 Custom Element compatible name.
 +
: All X3D nodes shall support all HTML Global Attributes [https://www.w3schools.com/tags/ref_standardattributes.asp]
 +
:: Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM ?
 +
: All X3D fields with the same name as HTML attributes shall behave as the HTML element
 +
: TBD: Not all style attributes apply to X3D nodes & fields
 +
  
 
===Scripting===
 
===Scripting===

Revision as of 10:44, 5 April 2017

Web3D Strategy

"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." Web3D Standards Strategy

Boundary conditions

  1. This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.
  2. Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.
  3. Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile

Notes

  1. Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.
  2. For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.
  3. Cross-check with the following pages:
    1. X3D V4 at http://www.web3d.org/x3d4
    2. X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development

Candidate Requirements

Looks "like" HTML

Elements (nodes in X3D-speak) shall be case independent
Attributes (fields in X3D-speak) shall be case independent
X3D nodes shall not have name conflicts with any HTML-defined elements
I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names ?
In that case, each node would be aliased with a HTML5 Custom Element compatible name.
All X3D nodes shall support all HTML Global Attributes [1]
Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM ?
All X3D fields with the same name as HTML attributes shall behave as the HTML element
TBD: Not all style attributes apply to X3D nodes & fields


Scripting

For example, SVG also has a script node that seems to operate just fine in combination with HTML.

  • See [2]
  • See the example in 18.2 The 'script' element at [3]
  • See the DOM interface definition for SVGScriptElement at [4]