[x3d-public] HTML Imports and ShadowDOM experiments

[Andreas Plesch]

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/X3dSpecifications/
> 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/#!/
> tiny-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/#!/
> tiny-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170726/135d9b02/attachment.html>