Re: My agenda: allow X3D <field> for <script> nodes

To enable all of this, using something like type=“text/x3dscript” or
type=“text/x3dscript+module” similar to type=“module” in a HTML script node
can insure that the script node with the new type is parsed correctly, with
possibly nested <field>s with other X3D content below that, and insures
backwards compatibility for all other script nodes.

I credit  Andreas Plesch for this idea.

The remaining hurdle is CDATA section within HTML.  This could be
restricted to x3dscript nodes, but X3D uses CDATA sections in other areas.

John

On Mon, Jan 13, 2025 at 11:57 PM John Carlson <yottzumm@gmail.com> wrote:

> Another advantage of using <field> over HTML5 data-* attributes is <field>
> can contain other elements.
>
> I had just thought of data-* attributes in my previous email, so I had not
> thought of all the implications.
>
> John
>
> On Mon, Jan 13, 2025 at 11:38 PM John Carlson <yottzumm@gmail.com> wrote:
>
>> The story:
>>
>> Web3D members use two main web-based 3D engines, X3DOM and X_ITE.  These
>> take two approaches to scripting.  X3DOM uses HTML script, and X_ITE uses
>> something called X3D Script, which is essentially the browser’s ECMAScript
>> by using “new Function()” and eval(), which we would like to avoid!
>>
>> There seems to be two approaches to avoid “eval”, adding X3D <field>s to
>> <script> which might seem a lot like HTML5’s data-* attributes, but also
>> include type, access type (in, out, initialize) and a default value.  If we
>> have fields, we can parse already existing <ROUTE> nodes already in both
>> X_ITE and X3DOM and process events to and from scripts.  It might be
>> possible to use data-* attributes with ROUTEs,  but we have pretty strict
>> validation on attributes, so I’m guessing X3D <Script>  nodes would no
>> longer validate.  We can work on relaxing that, but we are pretty happy
>> that we have a typesafe XML system.
>>
>> The other approach seems to be converting <field>s to JavaScript
>> server-side.  One could still have a static website, but the HTML Script
>> would likely be vastly different.
>>
>> Ideally, we could continue our HTML-independent scripting while also
>> using an HTML-dependent scripting without massive rewrites.  We do have a
>> HTML Scripting solution for X_ITE, it’s just X3DOM that lags behind—we’d
>> like to enable X3D scripting in X3DOM, without resorting to eval or “new
>> Function()”
>>
>> So it seems like not rejecting <field> in <script> would be a great
>> start.  I realize that data-* attributes are another approach.
>>
>>
>>
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/scripting.html
>>
>>
>>
>>
>>
>>