Difference between revisions of "X3D/HTML Integration"
(→Summary) |
(→Summary) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 27: | Line 27: | ||
# Scripts and Prototypes | # Scripts and Prototypes | ||
# (any I have missed) | # (any I have missed) | ||
| − | + | ## DOM Extension | |
| + | ## Other event handlers | ||
| + | ## Closing tags | ||
| + | ## X3D tag attributes | ||
We should look at each, and understand the implications for both 19775-1 and the new specification. | We should look at each, and understand the implications for both 19775-1 and the new specification. | ||
| Line 50: | Line 53: | ||
* Templates - Is this useful for X3D prototypes? | * Templates - Is this useful for X3D prototypes? | ||
* Shadow DOM - This might solve the namespace problem | * Shadow DOM - This might solve the namespace problem | ||
| + | |||
| + | W3C Validator plugin would be a good idea to enable X3D validation in HTML | ||
Latest revision as of 17:05, 15 June 2016
Examples
X3DOM: OnOutputChange Example
X3DOM: Interactive 3D Transformations Example
Summary
So, specifying the integration of X3D into HTML requires a lot more than a simple encoding. Assuming we consider generating an ISO/IEC specification, should we be generating a 19776 series document. I believe the answer is no. We need a much more overarching document. I suggest a 19775-3 document, perhaps entitled "X3D Embedding in HTML" or "X3D Integration with HTML", or some such.
I see the following actions:
- Review all X3DOM code, and understand the implications for specification.
- Review all Cobweb code, and understand the implications for specification.
- Review other 3D implementations, to see what lessons can be learned.
As these are reviewed we should start generating interface definitions. There's nothing like putting pen to paper, or pressing keys, and generating some technical details as we go. These can be short interface definitions, as above.
Furthermore, we are already aware of a number of general issues:
- Fields - DOMStrings vs X3D types
- Event models
- DEF/USE vs ID/IDREF
- Capitalization
- Namespace
- Scripts and Prototypes
- (any I have missed)
- DOM Extension
- Other event handlers
- Closing tags
- X3D tag attributes
We should look at each, and understand the implications for both 19775-1 and the new specification.
So leaping ahead, we could specify every node.
The GitHub repository for X3DOM contains small js files, in a folder structure. For downloading these seem to be combined into a single file. So if it contained all the nodes, it would be a large file. This is undesirable, particularly for mobile devices. So, can it be broken down into subunits?
XML3D are taking the approach of breaking down using a vertical stratification. This means they define a small core, which also incorporates an API, and then can define other nodes in terms of that API. So, presumably you have a relatively small core, and need additional downloads to add to it.
What about X3D? We have been talking about an HTML profile. We already have components. So our stratification is more horizontal. We could foresee a relatively small main file, for the basic HTML profile. Then an author could specify additional components, which would require a small separate download for each component. Is this a practical solution? Can subsequent js files make reference to functionality downloaded in a primary js file? The answer is believed to be yes, but confirmation is required.
Assuming the answer to the last question is yes, then we have to:
- Define an HTML profile.
What about Web components? How do they fit into the picture?
There are:
- Custom Elements - Is this useful for X3D prototypes?
- HTML Imports - Is this useful for X3D Inlines?
- Templates - Is this useful for X3D prototypes?
- Shadow DOM - This might solve the namespace problem
W3C Validator plugin would be a good idea to enable X3D validation in HTML
