[x3d-public] CSS bindings for <x3d> ...</x3d>

Sun Feb 5 07:05:10 PST 2017

>From what I can see <x3d> continues to ignore use of css selectors as 
an optional author tool with <x3d> user code. We have a connection 
with the document <script> but not with document <style>.

As for css, I trust that every html author will expect to be able to 
define an opening scene that is easily changed using css style api.

Since the <x3d> elements are available in the dom, and are accesible 
by dom api, then of course I ought to be able to realtime style basic 
elements of a scene using css, and control some or all features of the 
scene by changing live css user code, or by changing the node @class 
attribute.

Yes, the above is now for a long time 'native' to css for html5. To 
me, coverage of css is basic because it is NOW the actual minimum 
requirement for a conforming html/css/svg/mathml/dom w3c browser.
To add x3d to that list, <x3d> gotta have <style>.

Yes, live, cascading style is so fundamental to operation of the dom, 
that css even provides script-free animation techniques. Some of these 
expose some  <x3d> features, like keyframe interpolation. Just like 
X3D, implementation of style animation "in" the browser makes 
performance of this "built-in" stuff kill conventional html dom 
scripting for similar effects

So, style by class in html hosted content is so basic because its case 
is so true -
Authors can use it to distinguish style from content.

This remains true and to the extent that lines between content and 
style cross. Most of the crossover is actually under control of the 
author because the dom and css properties of the elements overlap. 
This gives some suthor flexibility, allowing style to convy content 
and vice-versa.

Perhaps the greatest contribution of this melding of html and x3d is 
that Finally, yes FFinally, X3D gets some "Style" which thus far 
mostly forbidden territory even considering the fact that X3D since 
inception has included the heretofore unused class attribute. Up to 
now there has been no great press for css in .x3d - let's face it, css 
didn't have much back then except fataastic potential to offer our 
DAG, but .x3d is now facing up to <x3d> in <html> so a New Higher 
level of X3D htmlization and domification is near.

The only problem is, whatever the x3d elements chosen, the community 
must define what @class attributes can be controlled by css. For 
example can you apply the css @hover on a shape or a geometry or does 
it matter?

Of course I want css for my list of initializeOnly fields!
Why, because it very easy to author using 'style' sheets instead of 
building the opening scene in a script that reads a list to generate 
the opening scene.
In <x3d> is there any such thing as the 'initializeOnly' field?
Of course I want css control of any node attribute I can reach with 
html dom script.
Actually, for simple stuff I don't want get into scripting the html 
dom; I'd rather script the css dom.

It is easy to see how a player that does <x3d> can implement a 
reasonable set of css properties for the x3d nodes and fields that 
need them. I mean look, html dom and html allowed the css to be 
domified and cacadiatied thus allowing intimate relationships, deeply 
changing realtime yet carefully sequenced, directly with some exposed 
and some internal dom events using very stimulating cascading 
interfaces.

Is it a complication or an advantage that fields of X3D XML nodes are 
attributes and so are candidates for <style> treatment?

So, certainly this will get some thought and work, but I stand with 
the idea of looking at it from the standpoint of what the experienced 
html/dom/css designer/author/user is going to expect.

For the most part, these authors and their authoring aids depend on 
DOM and CSS.

<x3d> without total dom and total css integratable with html5 is not 
really a complete standards-track package.

Thanks and Best,
Joe