[x3d-public] HTML Imports and ShadowDOM experiments

[Andreas Plesch]

It turned out that the previous experiment only worked in chrome since it
has the most complete native web components support. Here is an adjusted
version which also works with firefox and IE11(!), and exercises
web-animation.

https://glitch.com/edit/#!/maddening-agenda?path=index.html:54:30

Some more observations:

The required polyfill changes the sequencing of script execution. As a
consequence, the imported DEF node is not available when x3dom is looking
for it when it encounters the USE node. It uses defaults instead. It
possible to insert the USE node explicitly after inserting the imported DEF
node which then does allow x3dom to reference the expected node.

The polyfill also does not prevent selection of nodes in an attached shadow
tree. Probably, this level of encapsulation is only available with a native
implementation.

web-animation is for css properties, eg. styling. x3dom has some support
for animation via the css transform property and web-animation works with
it. But at this point, styling capability for all x3d fields and then
having animation support is not feasible. It would be a longer term target.

-Andreas

On Fri, Jul 21, 2017 at 10:24 AM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> https://glitch.com/edit/#!/juniper-wool?path=index.html:40:7
>
> is an investigation of how HTML Imports and ShadowDOM may be used to
> substitute for X3D Inline nodes. HTML Imports makes it straightforward to
> load an external fragment of HTML into a document:
> https://www.webcomponents.org/community/articles/introductio
> n-to-html-imports. And the stated purpose of ShadowDOM is encapsulation.
>
> Here are some observations:
>
> HTML imports work as intended with x3dom.
> It is likely one could use a generic 'include' webcomponent.
> DEF nodes in the imported x3d are exported/imported, so they can be USEd.
> There is no separate namescope.
> HTML imports can also be attached as shadow tree to a host node. But x3dom
> does not recognize the shadow tree and it is not rendered. Native X3D in
> HTML or an improved x3dom would likely render those.
> Attached shadow tree content cannot be selected/found with regular DOM
> methods. However, shadow trees still can be selected with the
> host.shadowroot property.
>
> It is likely that one could use en existing webcomponent such as
> https://www.webcomponents.org/element/github/include-fragment-element
> for inline purposes as well.
>
> Overall, it looks like that Inline would duplicate native webcomponent
> capability.
>
> It could also be fruitful to investigate how custom elements with
> templates compare with protos in detail. There seems to be match in purpose
> and ability.
>
> -Andreas
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170721/4ccb45c3/attachment.html>