<div dir="ltr">Leonard,<div><br></div><div>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.</div><div><br></div><div>Another example of a long-standing but never recommended standard is web-animations: <a href="https://w3c.github.io/web-animations/" target="_blank">https://w3c.github.io/web-anim<wbr>ations/</a> . It is actually more widely implemented than I thought: <a href="http://caniuse.com/#feat=web-animation" target="_blank">http://caniuse.com/#feat=web-a<wbr>nimation</a> , 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.</div><div><br></div><div>An additional complication is the split between WHATWG and W3C , and the adoption of the 'Living Standards' idea:</div><div><a href="https://wiki.whatwg.org/wiki/FAQ#WHATWG_and_the_W3C_HTML_WG" target="_blank">https://wiki.whatwg.org/wiki/F<wbr>AQ#WHATWG_and_the_W3C_HTML_WG</a></div><div>The adoption of Living Standards often makes the <a href="http://caniuse.com" target="_blank">caniuse.com</a> type of per feature/per browser support matrix the more relevant level of standardization.</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fortunately, polyfills are available for all these technologies, making it possible to explore their implications. However, polyfills are rarely used in actual production.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But in a sense it is more productive to try to wrestle with a four year time frame which is more difficult. </div><div class="gmail_extra"><br></div><div class="gmail_extra">But here we go, open for speculation:</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Roadmaps do not go far into the future:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://wiki.mozilla.org/Platform/Roadmap" target="_blank">https://wiki.mozilla.org/<wbr>Platform/Roadmap</a> : mentions web components work<br></div><div class="gmail_extra">Could not find high level roadmap for chrome: <a href="https://www.polymer-project.org/blog/" target="_blank">https://www.polymer-<wbr>project.org/blog/</a> well established web components. So a well iterated polymer 4.0</div><div class="gmail_extra"><a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/status/?q=edge%3A%27Under%20Consideration%27%20edge%3A%27Not%20currently%20planned%27" target="_blank">https://developer.microsoft.<wbr>com/en-us/microsoft-edge/<wbr>platform/status/?q=edge%3A%<wbr>27Under%20Consideration%27%<wbr>20edge%3A%27Not%20currently%<wbr>20planned%27</a> : Web components under consideration, available<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-Andreas</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 11:20 AM, Leonard Daly <span dir="ltr"><<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578moz-cite-prefix">Andreas,<br>
<br>
I like this kind of solution. It does bring up a procedural
question. It may be better answered by Dick (CCed)<br>
<br>
Shadow DOM is a working draft (2017-02-13)
<a class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578moz-txt-link-freetext" href="https://www.w3.org/TR/shadow-dom/" target="_blank">https://www.w3.org/TR/shadow-d<wbr>om/</a>. It is also being moved to other
standards (DOM, HTML, CSS, etc. -- see pink box in above link)<br>
<br>
Web Components are browser implementations necessary to support
Shadow DOM and other features. This is also a standard in
development at <a class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578moz-txt-link-freetext" href="https://github.com/w3c/webcomponents" target="_blank">https://github.com/w3c/webcomp<wbr>onents</a>.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><a href="https://glitch.com/edit/#%21/juniper-wool?path=index.html:40:7" target="_blank">https://glitch.com/edit/#!/jun<wbr>iper-wool?path=index.html:40:7</a><br>
</div>
<div><br>
</div>
<div>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: <a href="https://www.webcomponents.org/community/articles/introduction-to-html-imports" target="_blank">https://www.webcomponents.org/<wbr>community/articles/introductio<wbr>n-to-html-imports</a>. And
the stated purpose of ShadowDOM is encapsulation. </div>
<div><br>
</div>
<div>Here are some observations:</div>
<div><br>
</div>
<div>HTML imports work as intended with x3dom.</div>
<div>It is likely one could use a generic 'include'
webcomponent.</div>
<div>DEF nodes in the imported x3d are exported/imported, so
they can be USEd. There is no separate namescope.</div>
<div>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.</div>
<div>Attached shadow tree content cannot be selected/found with
regular DOM methods. However, shadow trees still can be
selected with the host.shadowroot property. </div>
<div><br>
</div>
<div>It is likely that one could use en existing webcomponent
such as</div>
<div><a href="https://www.webcomponents.org/element/github/include-fragment-element" target="_blank">https://www.webcomponents.org/<wbr>element/github/include-fragmen<wbr>t-element</a></div>
<div>for inline purposes as well.</div>
<div><br>
</div>
<div>Overall, it looks like that Inline would duplicate native
webcomponent capability.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Andreas</div>
<div><br>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578gmail_signature">Andreas Plesch<br>
39 Barbara Rd.<br>
Waltham, MA 02453</div>
</div>
<br>
<fieldset class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
x3d-public mailing list
<a class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>
<a class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><span class="m_818534544423568434gmail-m_-2000527498326031565gmail-HOEnZb"><font color="#888888">
</font></span></pre><span class="m_818534544423568434gmail-m_-2000527498326031565gmail-HOEnZb"><font color="#888888">
</font></span></blockquote><span class="m_818534544423568434gmail-m_-2000527498326031565gmail-HOEnZb"><font color="#888888">
<p><br>
</p>
<div class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578moz-signature">-- <br>
<font class="m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578tahoma,arial,helvetica m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578san m_818534544423568434gmail-m_-2000527498326031565gmail-m_-3547897803370629578serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_818534544423568434gmail-m_-2000527498326031565gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div></div>