[x3d-public] HTML Imports and ShadowDOM experiments
Leonard Daly
Leonard.Daly at realism.com
Fri Jul 21 08:20:17 PDT 2017
Andreas,
I like this kind of solution. It does bring up a procedural question. It
may be better answered by Dick (CCed)
Shadow DOM is a working draft (2017-02-13)
https://www.w3.org/TR/shadow-dom/. It is also being moved to other
standards (DOM, HTML, CSS, etc. -- see pink box in above link)
Web Components are browser implementations necessary to support Shadow
DOM and other features. This is also a standard in development at
https://github.com/w3c/webcomponents.
I know that an ISO standard cannot normatively reference a working draft
standard. Is the purpose of a standard to make explicit standard
practices and procedures throughout an industry? Is it possible to
codify standard practices and procedures when they don't exist because
the underlying technology is too new?
The danger I see here is that something is standardized before it is
really ready to be standardized. The penalty for waiting is that
everything will pass you by and there will always be something new
coming down the line.
Leonard Daly
> https://glitch.com/edit/#!/juniper-wool?path=index.html:40:7
> <https://glitch.com/edit/#%21/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/introduction-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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170721/3b285cc8/attachment-0001.html>
More information about the x3d-public
mailing list