[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