[x3d-public] HTML Imports and ShadowDOM experiments

[Andreas Plesch]

Leonard,

unfortunately, as you explain, the main browser makers and w3c players
cannot agree on web components becoming a Recommended Standard. HTML
Imports especially is seen by Mozilla as overlapping too much with ES6
modules (export and import for JS) . Modules will be widely available, eg.
with each browser.

Another example of a long-standing but never recommended standard is
web-animations: https://w3c.github.io/web-animations/ . It is actually more
widely implemented than I thought: http://caniuse.com/#feat=web-animation ,
and worth more experiments with x3dom. The element.animate() method should
be able to animate any property, and is intended to replace SVG builtin
animation.

An additional complication is the split between WHATWG and W3C , and the
adoption of the 'Living Standards' idea:
https://wiki.whatwg.org/wiki/FAQ#WHATWG_and_the_W3C_HTML_WG
The adoption of Living Standards often makes the caniuse.com type of per
feature/per browser support matrix the more relevant level of
standardization.

So there is a complicated landscape and unfortunately it cannot be ignored
tempting as it may be. It becomes necessary to try to extrapolate how the
WWW environment will look like in one, two and perhaps four years, in order
to best allocate limited resources.

Fortunately, polyfills are available for all these technologies, making it
possible to explore their implications. However, polyfills are rarely used
in actual production.

Due to the uncertainty, it seems necessary, at first, to just keep all X3D
functionality internal to X3D. This also provides backwards compatibility
and is what A-Frame and SVG do as well. There is a lot of overlap, and it
will become necessary to just leave some resulting interaction as undefined
behavior in a specification.

But in a sense it is more productive to try to wrestle with a four year
time frame which is more difficult.

But here we go, open for speculation:

Web developers like JS frameworks, so JS, especially with ES6, and DOM will
remain the dominant method to fill the web. WebGL2 will still be
fundamental to render 3d, threejs will still be the main interface to
WebGL. I think A-Frame is starting to see some adoption for productive web
sites, so it could be still around. x3dom will need overhaul to stay
functional. web components' custom elements, and shadow dom, will be on
their final steps to ratification. html imports are supported. WebVR 2.0
supported in all browsers.

Roadmaps do not go far into the future:

https://wiki.mozilla.org/Platform/Roadmap : mentions web components work
Could not find high level roadmap for chrome: https://www.polymer-
project.org/blog/ well established web components. So a well iterated
polymer 4.0
https://developer.microsoft.com/en-us/microsoft-edge/
platform/status/?q=edge%3A%27Under%20Consideration%27%
20edge%3A%27Not%20currently%20planned%27 : Web components under
consideration, available

-Andreas


On Fri, Jul 21, 2017 at 11:20 AM, Leonard Daly <Leonard.Daly at realism.com>
wrote:

> 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-d
> om/. 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
>
> 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
>
>
> _______________________________________________
> x3d-public mailing listx3d-public at web3d.orghttp://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - *Creating the Future*
>



-- 
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/5eadbe87/attachment.html>