Difference between revisions of "X3D V4 HTML Integration Requirements"
From Web3D.org
(→Requirements) |
(→Boundary conditions) |
||
| Line 5: | Line 5: | ||
== Boundary conditions == | == Boundary conditions == | ||
| − | # This is just for X3D running in a web browser and integrated with HTML. If there is X3D outside of this limitation, these requirements may or may not apply. | + | # 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. |
# 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. | # 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. | ||
# Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile | # Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile | ||
Revision as of 14:12, 29 March 2017
Web3D Strategy
"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." http://www.web3d.org/strategy
Boundary conditions
- 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.
- 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.
- Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile
Notes
- 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.
- 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.
- Cross-check with the following pages:
- X3D V4 at http://www.web3d.org/x3d4
- X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development
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
- All X3D nodes shall support all HTML Global Attributes (https://www.w3schools.com/tags/ref_standardattributes.asp)
- 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
- HTML encodings
- HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.
- HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax
- HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax
- 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. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.
- Functions "like" HTML
- All nodes shall be fully integrated with the DOM [This may need to change if certain nodes need to remain hidden from the DOM. For example, the manner which X3DOM implements Inline.]
- The scene graph does not need to be DOM (or a portion of it).
- Changes to the DOM shall be reflected in the scene graph
- Changes to the scene graph shall be reflected in the DOM
- Events are handled as HTML events
- DOM is the external (i.e., from the web page) API to the scene graph
- Other HTML related
- X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.
- HTML elements, SVG elements and css blocks can be interspersed with X3D elements.
- HTML Script, SVG Script and X3D Script elements are unique and distinguishable.
- I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.
- String-based DOM events correlate with strongly typed X3D events by defined correspondences, i.e.: _____
- The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).
- X3D shall support the evolving web standards for flat-3D (WebGL), VR WebVR) and AR
- Existing features & functionality
- Perform the following tasks with the requirements that is be conflict with the above
- Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4
- Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4
- Include all features and functionality that passes the above reviews
- Additional features shall be added
- Deformable-skin joint based animation
- Support for multiple geometry formats, including OBJ, glTF
- Increased Material support with a standard library of pre-defined shaders
- Mechanism to navigate a scene without a pointing device
- Mechanism to touch or select objects without a pointing device
- Review other 3D/VR display technologies (XML3D, A-Frame, GLAM, etc.) to determine if there are features that should be included
