[x3d-public] dual use of script tag in HTML environment
Yves Piguet
yves.piguet at gmail.com
Fri Nov 11 10:27:57 PST 2016
Sorry if this has already been discussed. Couldn't you define a namespace-like prefix for all elements, such as "x3d:"? Maybe optional for elements which don't cause a compatibility problem with element tag names already defined for other purposes.
In HTML5, namespaces don't exist (see e.g. <https://dev.w3.org/html5/spec-LC/syntax.html#elements-0>): the actual tag name of X3D script elements would be "x3d:script". Script source code should be put in cdata fragments <https://dev.w3.org/html5/spec-LC/syntax.html#cdata-sections>.
In XHTML, a valid xml namespace would be declared and used.
Yves
> On 11 Nov 2016, at 18:38, Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> I am trying to make cobweb and cobweb_dom html5 compatible, so there is no requirement to use xhtml. xhtml is not used much at all and may face extinction,
>
> While I got cobweb to recognize the html5 DOM uppercased .nodeName (Box becomes BOX) and the lowercased attribute names (diffuseColor becomes diffusecolor) as equivalents to their realcased xml names, it turns out that there are deeper problems with the script node.
>
> The type='application/vrmlscript' work-around to avoid execution of the script by the web browser still applies.
>
> In html5 the script element's content is always CDATA and there is no need to use a CDATA tag. In fact, I am not sure if it is even recognized.
>
> https://wiki.whatwg.org/wiki/HTML_vs._XHTML#Element-specific_parsing
>
> While this is usually convenient, it also means that the <field></field> tags inside the script node are not recognized/parsed as child nodes as they are for xml/xhtml parsing but as character content.
>
> So script becomes a special case for x3d parsing since now the <field> tags are either already delivered as DOM child nodes or - in the case of html5 documents - they are delivered as .innerHTML or .textContent character data.
>
> The implication for x3d spec. is that it would be better to have the field definitions in an attribute rather as in child nodes. Something like
> <script ... fields=' "inputOnly SFBool isOver" "outputOnly SFColor diffuseColor_changed" '>
> That would be also more concise.
> Perhaps both field attribute and field child nodes could be allowed with child nodes taking precedence, for compatibility.
> I think this would affect only the XML encoding spec.
>
> I may try to come up with a little preprocessor script which finds all the field tags inside script nodes, converts them into actual DOM child nodes, appends those the script node, and removes them (or comments them out) from the textContent of the script node.
>
> Andreas
>
>
> On Mon, Sep 26, 2016 at 2:35 AM, Don Brutzman <brutzman at nps.edu> wrote:
> Andreas, I hope that everyone's relative silence over the weekend isn't interpreted as lack of interest!
>
> This is a really important step forward: HTML5 scripts coexisting with X3D scripts, both using javascript.
>
> Looking forward to a future X3D Working Group meeting to explore and begin documenting necessary approaches for this work in detail. No doubt it will help us achieve important capabilities in X3D version 4.
>
> Once again, thanks for your many efforts.
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list