[x3d-public] Requirement for v4. Different ids for X3D or scene element

[Leonard Daly]

I just realized I forgot to define shadow DOM.

A shadow DOM is a standard DOM tree that is not connected to the 
document. It exists in the document space by it is anchored by a node 
that is not in the document. You can create a shadow DOM with 
JavaScript, but not in declarative HTML. The shadow DOM can be attached 
to the document at any time and at any point in the DOM. When that is 
done, it stops being a shadow DOM and is a branch in the document DOM. 
It is also possible to attach one shadow DOM to another shadow DOM. It 
is not possible to have an HTML element (tag) in both a shadow DOM and 
any other DOM.

Leonard Daly


> On 1/31/2019 3:49 PM, John Carlson wrote:
>> As a web3d member, how much weight do I personally have to impact the 
>> standard?  I would like to see the requirement for different ids in 
>> the scene or X3D element in case I load a file into the page in more 
>> than one place.
>
>
> John,
>
> Each file and PROTO define their own namescope. That means you can 
> Inline a file many times and not have an ID conflict (in 
> spec-compliant X3D). If X3D is brought into a browser with the same 
> functionality (using Inline as an example), then the newly added nodes 
> would have the same ID. While this is not fatal in an HTML sense, it 
> does lead to an ambiguity when using a standard DOM call such as 
> document.getElementById (<id-string>).
>
> There is no mechanism in X3D to rename IDs (or DEFs) to avoid that 
> name conflict *AND* have all nodes loaded into the DOM. If you create 
> a shadow DOM(*) for each external reference (Inline, PROTO (however, 
> that is handled), EXTERNPROTO, etc.) then there is no problem because 
> elements in shadow DOMs are not available through calls like 
> document.getElementById (<id-string>). In those cases it would be 
> necessary to provide the appropriate shadow DOM root reference to 
> replace 'document'.
>
> The X3D engine would need to intercept all references to those objects 
> and make the appropriate change in reference. It's all software, so it 
> is doable; but this does break the conceptual model of HTML where all 
> visible elements are part of the document.
>
> Note that there is also a similar conceptual breaking for DEF/USE. 
> HTML elements only have a single parent. That means something that is 
> USEd from someplace else, must be a full copy of the source. It is 
> possible to create a 'redirect' element that in the DOM references the 
> DEF element so the scene graph (which is typically separate from the 
> DOM data structure) is done in the X3D manner.
>
>
> Leonard Daly
>
>
>
>
>>
>> The main requirement for this comes from scripting...how to access 
>> the right field if it’s loaded more than once.
>>
>> Which may be a good reason not to support fields in Scripts or 
>> Scripts at all.
>>
>> John
>>
>> _______________________________________________
>> 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 Past Chair
> President, Daly Realism - /Creating the Future/
>
> _______________________________________________
> 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 Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190131/44233372/attachment.html>