<div dir="ltr"><div>Hi Leonard,<br><br></div>thank you for this excellent summary of the inline situation in X3D and x3dom, and the implications in terms of DOM integration which provides an good basis for a discussion.<div class="gmail_extra"><div class="gmail_quote"><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="gmail-m_8236270521763696797moz-cite-prefix">
<br>
Some background first. Not that you need this, but others
following the discussion might. The X3D Standard
(<a class="gmail-m_8236270521763696797moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/<wbr>components/networking.html#<wbr>Inline</a>)
indicates that all nodes loaded via an Inline occupy a separate
namescope (sort-of like a name-space, but without a lot of the
structure) from the parent scene. This prevents direct
communication between the parent and the children of an Inline.
The Import/Export statements allow certain information to be
passed between the parent/child. The namescope applies only to
information passing. Rendering is all rolled-up.<br></div></div></blockquote><div><br></div><div>I think it is useful to think about the motivation for requiring a separate namescope and the default of no direct communication between the scene and inline content. One big reason must be that an author should not need to worry about DEF naming collisions when using an inline. But is there a fundamental reason to not EXPORT all inlined nodes by default, eg. allow IMPORTing them ? The IMPORT statement still enforces the definition of a unique name for the imported node.<br> </div><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="gmail-m_8236270521763696797moz-cite-prefix">
X3DOM implements this requirement with the following. If only the
X3D-defined fields are used, then the Inlined nodes are not loaded
into the (HTML) DOM. They are maintained in the list of rendered
nodes so content can be visible. Since they are not in the DOM,
those nodes cannot be accessed with DOM-oriented calls (e.g.,
jQuery). At this time X3DOM does not support Import/Export.<br>
<br></div></div></blockquote><div><br></div><div>Yes. There is a slight complication I believe. When x3dom uses xmlhttprequest to load an inline file, I think the xml file gets loaded into a separate dom tree which is then parsed to produce x3dom nodes for the x3d scene graph which are in turn rendered. So I believe the inline does have its dom nodes, they are just not part of the main dom.<br></div><div> </div><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="gmail-m_8236270521763696797moz-cite-prefix">
If the X3DOM field 'namespacename' is present and a value is
provided, the value appended with a double underscore is prepended
to all DEFs. If the field 'mapdeftoid' is TRUE, then the
prepending is also done to IDs (it's actually a little more
complicated than that, but this will do for now). The Inlined
nodes are still maintained in a separate X3-DOM namescope. This is
necessary because Inline's 'url' field can change and those nodes
would need to be removed. The separate namescope allows those
nodes to be identified.<br></div></div></blockquote><div> <br></div>Just to give an example:<br></div><div class="gmail_quote"><Inline url='arrow.x3d' namespacename='arrow1' /><br></div><div class="gmail_quote">arrow.x3d:<br></div><div class="gmail_quote">.. <Material DEF='headcolor' .. /> ..<br><br></div><div class="gmail_quote">external x3dom access: document.getElementById('arrow1__headcolor').setAttribute('diffuseColor','1 0 0')<br><br></div><div class="gmail_quote">How would nodes in inlines within inlines be identified ? Double prefixes ? Imagine an inline of an bow with arrow: bow1__arrow1__headcolor ?<br></div><div class="gmail_quote"><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="gmail-m_8236270521763696797moz-cite-prefix">
<br>
[Switching back to regular HTML] Elements added to an HTML
document through the DOM become full elements in the page's DOM.
There is no separate namescope. It is the responsibility of the
adding code to ensure that there are no 'id' value conflicts (ids
are unique throughout the document). <br></div></div></blockquote><div><br></div><div>Yes, ids are the responsibility of the author or dom manipulation code. However, using .querySelector and CSS selector it is often possible to have a selector specific enough to identify a unique element without using an id attribute.<br> </div><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="gmail-m_8236270521763696797moz-cite-prefix">
This is similar to X3D in that DEF names need to be unique
throughout the namescope. This slight variant allows the author to
use an Inline multiple times because each instance is in its own
namescope.<br></div></div></blockquote><div><br></div><div> In fact, document.querySelector([DEF='uniqueName']) allows uniquely identifying a x3d node in a DOM environment without having to introduce id attributes at all.<br><br></div><div>multiple instances of inlines:<br><br></div><div><Inline DEF='a1' namespacename='arrow1' url='arrow.x3d' /><br><Inline DEF='a2' namespacename='arrow2' url='arrow.x3d' /><br><br></div><div>This only would make sense if there is a plan to modify each arrow individually (otherwise, the second arrow would be a USE instance).<br>document.getElementById('arrow1__headcolor').setAttribute('diffuseColor','1 0 0')<br>document.getElementById('arrow2__headcolor').setAttribute('diffuseColor','0 1 0')<br><br></div><div>There is an equivalent EXPORT/IMPORT path for SAI access.<br></div><div><br></div><div>The cobweb dom bridge allows similarly:<br><br>document.querySelector('Inline[DEF="a1"] Material[DEF="headcolor"]').setAttribute('diffuseColor','1 0 0')<br></div><div>or shorter since the DEFs are unique within their subtrees:<br>document.querySelector('[DEF="a1"] [DEF="headcolor"]').setAttribute('diffuseColor','1 0 0')<br>document.querySelector('[DEF="a2"] [DEF="headcolor"]').setAttribute('diffuseColor','0 1 0')<br><br></div><div>As you can see this looks quite similar to namespacename prefixes but does not require the additional field, and instead just can use the DEF field. This kind of brings up the question why x3dom does not simply use the DEF name as namescope prefix ? Is there a case where you would want to use different DEF names but the same namespacename ? <br></div><div><br></div><div><Inline DEF='a1' namespacename='arrow1' url='arrow.x3d' /><br><Inline DEF='a2' namespacename='arrow1' url='arrow.x3d' /><br></div><div><br></div><div>I cannot see immediately how this could be of use ?<br></div><div><br></div><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="gmail-m_8236270521763696797moz-cite-prefix">
A 3D environment in a web page should be able to Inline the same
file multiple times (e.g., a row of trees) without causing a
problem with the DOM. It should also be possible to group and
individually animate those objects. For example, a number of trees
of the same kind would all sway in the wind. Trees of the same
height would behave similarly. One tree might be special and need
to sway differently. It should be possible to apply an animation
to the entire class of trees and a special animation to the
special tree. If all of the trees had the same class, then (at
least theoretically) the animation could be applied to the class.
The special tree would have a unique ID so that could be animated
separately.<br></div></div></blockquote><div><br></div><div>There is class attribute for HTML elements for convenient selection of all elements belonging to the same class. I tend to think it is more of a convenience feature. <br><br></div><div>Let's think through the scenarios:<br><br></div><div>1) multiple instances: DEF/USE for cloning, multiple DEFs with the same url for individual instances<br></div><div>2) swaying trees: DEF='swayingTree' / USE ; animate swayingTree internally<br></div><div>3) swaying trees, but each a bit differently: more of a case for prototypes, could include script for sway behaviour depending on height<br></div><div>4) special tree: DEF='special Tree', access and animate specially<br></div><div><br></div><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="gmail-m_8236270521763696797moz-cite-prefix">
<br>
What Andreas has written below is an element-attribute-value
selector that goes down to the final leaf to set a value. If the
Inline's parent (the file that contains the node <Inline
url='InlineParent.x3d'>) uses this node multiple times, then
Andreas' querySelector statement would change all of the
arrowheads that fit the criteria. This is not necessarily bad, but
just needs to be considered.</div></div></blockquote><div><br></div><div>.querySelector always only selects a single element. If they are multiple elements which fit the selector, the 'best' fit is chosen or all things being equal the first one. .querySelectorAll gives you all the fitting elements.<br><br></div><div>I think it is true to say that it is always possible to construct a path from an Inline node down to the targeted node inside which is unique. DEFs inside the inline need to be unique within their scene and DEFs in the parent also need to be unique. So it is always possible to construct [DEF='parentName'] [DEF='nodeName'] or in prefix notation parentName__nodeName .<br><br></div><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="gmail-m_8236270521763696797moz-cite-prefix"> Anything not starting with an ID
reference or a unique tag in the scene (e.g., <body>) may
not refer to a unique node.<br></div></div></blockquote><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="gmail-m_8236270521763696797moz-cite-prefix">
=== InlineParent.x3d ===<br>
:<br>
<Inline DEF='arrow' url='arrow.x3d'></Inline><br>
:<br>
<br>
<br>
=== arrow.x3d ===<br>
:<br>
:<br>
<Appearance><br>
<Material DEF='arrowheadmat' diffuseColor='0 0
1'></Material><br>
:<br>
</Appearance><br>
<br>
<br></div></div></blockquote><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="gmail-m_8236270521763696797moz-cite-prefix">
<br>
So I think rather than ask what would it take to adopt the
selector approach, a more fundamental question needs to be
answered - how should files be imported into a scene and inserted
into the (HTML) DOM? I think once that question is answered the
rest will be easy.<br></div></div></blockquote><div><br></div><div>This is certainly a good question to ask. I thought about not exposing Inlined content at all for DOM access for cobweb, and instead rely on html templating or the newish HTML Imports functionality which deals with similar issues. With HTML Imports an HTML file is imported as a separate DOM first and then can be cloned and appended into the main document. It feel like this could replace a lot of the Inline functionality. I should put together an example page using HTML Imports (which is rejected by Mozilla).<br><br></div><div>The question how files should be imported also implies if there should be a change in how EXPORT/IMPORT works now for X3D/SAI ? Both x3dom and cobweb_dom implicitly export all nodes in an inline. Should EXPORT/IMPORT be streamlined similarly ?<br></div><div> </div><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="gmail-m_8236270521763696797moz-cite-prefix">
I created a new public Wiki page on Web3D.org
(<a class="gmail-m_8236270521763696797moz-txt-link-freetext" href="http://www.web3d.org/wiki/index.php/Importing_and_adding_nodes_in_HTML" target="_blank">http://www.web3d.org/wiki/<wbr>index.php/Importing_and_<wbr>adding_nodes_in_HTML</a>)
where results of this discussion are recorded.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Leonard,
<div><br>
</div>
<div>I guess I am looking for guidance and a discussion on how
ideally content internal to Inlines should be identified. I do
like the CSS selector approach because if does not involve
adding an additional namespacename field to Inline. But there
may be other approaches.</div>
<div><br>
</div>
<div>What would it take to adopt the selector approach in x3dom
? So you can do this:</div>
<div><br>
</div>
<div>SceneElement.querySelector("<wbr>Inline[DEF='arrow']
Material[DEF='arrowheadmat']).<wbr>setAttribute("diffuseColor","1 0
0")</div>
<div><br>
</div>
<div>-Andreas</div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Oct 1, 2016 at 11:54 PM,
Leonard Daly <span dir="ltr"><<a href="mailto:web3d@realism.com" target="_blank">web3d@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="gmail-m_8236270521763696797m_4485260413489110371moz-cite-prefix">Andreas,<br>
<br>
I am not sure if you are looking for comments,
advice, discussion, or just posting a notice. I
don't want to go off on a tangent here. I am rather
familiar with how and almost why X3DOM does it.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
</div>
<blockquote type="cite">
<p dir="ltr">I am working on adding DOM access to
inline scenes for my Cobweb DOM bridge:</p>
<p dir="ltr"><a href="https://andreasplesch.github.io/cobweb_dom/tests/inline_in_inline.xhtml" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/tests/inline_in_i<wbr>nline.xhtml</a></p>
<p dir="ltr">The idea is to add the external inline
scene DOMs to the main scene DOM as children of
the Inline elements. Once added, the mutation
observer picks up modifications of these children
and does not need to do anything other than it
already does for the main scene.</p>
<p dir="ltr">It works well although I do not know
how web browsers deal with large combined DOMs.
Also, a small addition to Cobweb.js is currently
needed.</p>
<p dir="ltr">One effect is that one can use CSS
selectors with querySelector to drill down to
specific elements in inline scenes, even through
hierarchies of inlined inlines. See example. This
way the DEF names can be used even if they are
identical across scenes. X3D semantics and
functioning is not affected.</p>
<p dir="ltr">X3dom uses a different approach of
prefixes to id/DEF attributes to enable access to
elements in inlines. Not sure if x3dom could use
instead or in addition Selectors ? This would
require adding the Inline DOMs to the main DOM but
perhaps this is already almost done ?</p>
<p dir="ltr">So I am considering also adding the
same option of a namespacename prefix to element
IDs but the effort would be really for
compatibility. Thinking about it, while possible
probably not a priority unless there is a
compelling use case.</p>
<p dir="ltr">X3D has EXPORT/IMPORT to deal with
accessing nodes in inlines. I think the SAI
equivalent is roughly that all nodes are EXPORTed
by default and that in addition to a DEF name it
becomes possible to address a node by its path in
the scene hierarchy. Perhaps something to consider
for the standard: X3D selectors.</p>
<p dir="ltr">Andreas</p>
<br>
<fieldset class="gmail-m_8236270521763696797m_4485260413489110371mimeAttachmentHeader"></fieldset>
<br>
<pre>------------------------------<wbr>------------------------------<wbr>------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! <a class="gmail-m_8236270521763696797m_4485260413489110371moz-txt-link-freetext" href="http://sdm.link/slashdot" target="_blank">http://sdm.link/slashdot</a></pre>
<fieldset class="gmail-m_8236270521763696797m_4485260413489110371mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
X3dom-users mailing list
<a class="gmail-m_8236270521763696797m_4485260413489110371moz-txt-link-abbreviated" href="mailto:X3dom-users@lists.sourceforge.net" target="_blank">X3dom-users@lists.sourceforge.<wbr>net</a>
<a class="gmail-m_8236270521763696797m_4485260413489110371moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/x3dom-users" target="_blank">https://lists.sourceforge.net/<wbr>lists/listinfo/x3dom-users</a><span class="gmail-m_8236270521763696797HOEnZb"><font color="#888888">
</font></span></pre><span class="gmail-m_8236270521763696797HOEnZb"><font color="#888888">
</font></span></blockquote><span class="gmail-m_8236270521763696797HOEnZb"><font color="#888888">
<p>
</p>
<div class="gmail-m_8236270521763696797m_4485260413489110371moz-signature">--
<font class="gmail-m_8236270521763696797m_4485260413489110371tahoma,arial,helvetica gmail-m_8236270521763696797m_4485260413489110371san gmail-m_8236270521763696797m_4485260413489110371serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font>
3D Systems Architect & Cloud Consultant
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</font></span></div>
</blockquote></div>
<div>
</div>--
<div class="gmail-m_8236270521763696797gmail_signature">Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453</div>
</div></div></div>
</blockquote>
<p>
</p><div class="gmail-m_8236270521763696797moz-signature">--
<font class="gmail-m_8236270521763696797tahoma,arial,helvetica gmail-m_8236270521763696797san gmail-m_8236270521763696797serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font>
3D Systems Architect & Cloud Consultant
President, Daly Realism - <i>Creating the Future</i>
</font></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>