[x3d-public] HTML Imports and ShadowDOM experiments

Mon Aug 28 13:51:00 PDT 2017

Following up, here are equivalent web components which use now a shared
base class:

https://x3dom-webprotos-3.glitch.me/
https://glitch.com/edit/#!/x3dom-webprotos-3?path=x3dProtoClass.js:1:0

It would be nice to be able to route to fields of these web components, so
I am thinking about that.

Andreas

On Mon, Aug 28, 2017 at 12:07 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Ok, I could adapt the Rotor prototype example as a x3dom web component
> here:
>
> https://glitch.com/edit/#!/x3dom-webprotos-2?path=index.html:26:4
>
> https://x3dom-webprotos-2.glitch.me
>
> Since the rotor prototype internally uses DEF node names for routing, I
> had to add name scoping per proto instance. Ideally, if x3d would work in a
> shadowdom, the shadowdom would provide the encapsulation of name scopes but
> since x3dom does not 'see' a shadowdom I needed to add unique suffixes to
> all occurrences of node names in a proto (template) instance.
>
> But this was the only necessary addition to template processing.
>
> The example also exercises DEF/USE of nodes used as field values and
> nesting of proto instances which both seem to work.
>
> To take further advantage of web components, it may be possible to use a
> x3dproto base class for shared methods  which extended custom proto
> elements would use.
>
> There are severe limitations such as no MFNode type fields or only
> indirect routing. x3d scripting needs to be substituted by component
> methods.
>
> But overall using web components could be a HTML integrated, standards
> based approach to prototyping and instancing.
>
> Andreas
>
> On Mon, Aug 28, 2017 at 1:38 AM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Trying to realize a x3d prototype style instancing for x3dom, I added use
>> of html5 custom elements in addition to html5 templates and shadowdom here:
>>
>> https://x3dom-webprotos.glitch.me/
>> https://glitch.com/edit/#!/x3dom-webprotos?path=index.html:24:7
>>
>> The main work happens in processTemplate() which takes the template,
>> populates it with instance values and brings the instance out of the
>> shadowdom into the lightdom so x3dom can 'see' it.
>>
>> https://glitch.com/edit/#!/x3dom-webprotos?path=table_proto.html:81:2
>>
>> processTemplate() is fairly generic and may work for other templates
>> (proto declarations) such as the rotor proto:
>>
>> http://www.web3d.org/x3d/content/examples/Basic/X3dSpecifica
>> tions/RotorIndex.html
>>
>> I may try this next.
>>
>> -Andreas
>>
>> On Wed, Jul 26, 2017 at 12:27 PM, Andreas Plesch <andreasplesch at gmail.com
>> > wrote:
>>
>>> On Sun, Jul 23, 2017 at 12:32 PM, Andreas Plesch <
>>> andreasplesch at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Jul 22, 2017 at 4:01 PM, Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 21, 2017 at 10:24 AM, Andreas Plesch <
>>>>> andreasplesch at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> ...
>>>>>> 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.
>>>>>>
>>>>>
>>>>> ...
>>>>> It may be possible to process the attached and populated template to
>>>>> replace slot elements with their corresponding assigned nodes. This leaves
>>>>> the first problem or parenting (a universal one !). One solution may be to
>>>>> move the shadow root nodes out and into the light dom under the shadow
>>>>> host. ..
>>>>>
>>>>
>>>> After writing this, I went ahead and tested this idea. It turns out
>>>> that it actually works (only for chrome):
>>>>
>>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:70:5 and Show
>>>> Live.
>>>>
>>>> I added a slotted template using this web3d example:
>>>> http://www.web3d.org/x3d/content/examples/Basic/X3dSpecifica
>>>> tions/PrototypeIndex.html
>>>>
>>>> The template has slots for a color field(attribute) and a material
>>>> field(element):
>>>> https://glitch.com/edit/#!/tiny-fact?path=table_template.html:12:7
>>>> https://glitch.com/edit/#!/tiny-fact?path=table_template.html:27:15
>>>>
>>>> Cloning the template then into the root of shadow dom (attached to a
>>>> group node) causes assignment of values to the named slots now in the
>>>> shadow dom. One can then process these values to become actual x3dom field
>>>> values. This does not require a lot of processing:
>>>>
>>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:70:14
>>>>
>>>> But it took a while to pin down the details.
>>>>
>>>> It is interesting that it was natural to keep Prototype's nodeField and
>>>> fieldValue semantics.
>>>>
>>>> For the instance: https://glitch.com/edit/#!/tin
>>>> y-fact?path=index.html:30:1
>>>>
>>>> <x3d-Group id="tablehost">
>>>>       <fieldValue slot="tableTopMaterialColor" value="1 1
>>>> 1"></fieldValue>
>>>>  </x3d-Group>
>>>>
>>>> and for the template (prototype): https://glitch.com/edit/#!/tin
>>>> y-fact?path=table_template.html:12:0
>>>>
>>>> <Material DEF='TableTopMaterial' diffuseColor='.6 .6 .1'>
>>>>   <slot name='tableTopMaterialColor' nodeField='diffuseColor'>
>>>>      <fieldValue value='.6 .6 .1'></fieldValue> <!-- default -->
>>>>    </slot>
>>>>
>>>> Since x3dom does not know how to deal with shadow dom, it is necessary
>>>> to move the processed shadow dom into the light dom. But this requires only
>>>> one line:
>>>>
>>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:81:1
>>>>
>>>> The example is just for testing the process and does not make an
>>>> attempt to generalize or wrap the process to be applied easily to any
>>>> template. I do think wrapping this into a general ProtoInstance like web
>>>> component/custom element is quite doable.
>>>>
>>>> So perhaps I was too pessimistic and in fact it may be possible to rely
>>>> on web components for prototype like functionality.
>>>>
>>>> First, I want to check if modifying the slot value in a template
>>>> instance gets picked up by x3dom. Probably not for attribute fields. hm.
>>>>
>>>>
>>> Obliterating the line number references above, I updated
>>>
>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:94:1 and show Live
>>>
>>> to enable updates to the fieldValues in template instances. It was only
>>> necessary to observe the mutations of the values and then update the field
>>> in the actual node accordingly.
>>>
>>> The change color button sets the value attribute of the fieldValue
>>> element which is linked to the template by a named slot. The nodeField
>>> attribute (here 'diffuseColor') of the slot links the slot to a field of
>>> the parent of the slot. Using these relations it does not take much to
>>> transmit a changed fieldValue value of the instance to the actual node in
>>> the template clone.
>>>
>>> To enable updates to SFNode type fields of a template instance, no
>>> additional code was necessary since the instance's node (linked by a slot)
>>> is directly used in the template clone by moving it into the template
>>> clone. This is what the change material button tests. It changes both the
>>> color and the shininess of the material node in the instance.
>>> What was interesting is that it is possible to use a USE material node
>>> in the instance and put the corresponding DEF material outside somewhere
>>> else. Since the DEF node does not get moved, it can be more easily
>>> selected. However, direct selection by id or other attributes of the moved
>>> node should also be very straightforward. It should also be possible x3d
>>> route to it directly.
>>>
>>> Routing to nodeField defined 'fields' of a cloned, slotted template is
>>> currently not possible. Hm, it may perhaps be possible to define an actual
>>> fieldValue x3dom node with a 'value' field (of flexible type) which can
>>> receive routed values and does nothing but update the value attribute of
>>> its dom node.
>>>
>>> The next step would be to see how to include scripts in templates.
>>>> Script tags can be part of templates. They get executed when the template
>>>> is instanced by cloning. Another place for scripting is in a custom
>>>> element. Templates are often used with custom elements. A custom element
>>>> would be the way to wrap the js in the example.
>>>>
>>>> -Andreas
>>>>
>>>> --
>>>> Andreas Plesch
>>>> 39 Barbara Rd.
>>>> Waltham, MA 02453
>>>>
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> 39 Barbara Rd.
>>> Waltham, MA 02453
>>>
>>
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>

-- 
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/20170828/f9d2ac23/attachment.html>