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

Mon Feb 6 17:29:28 PST 2017

Joe, thanks for laying out a very thoughtful look at CSS.  Really great!

CSS is very powerful and has the potential for authors to modify any shared aspect within a scene consistently/coherently.

CSS is also used for HTML and SVG animations; changing a style might not be 30fps but it is an animation of sorts.

CSS can also be used for alternate presentation styles that assist with accessibility, applications of which will continue to grow in importance for X3D.

Perhaps since CSS can be used for HTML print styles, it might even be useful for X3D and 3D printing... something to ponder!

In several respects, CSS reminds me of classic X3D animation: since essentially any field of any node in a scene graph can be modified (via events or Scripts), any aspect of X3D can be modified. My preferred definition of X3D animation is "modifying one or more fields in nodes in a scene graph."  Since CSS has complete expressive power at the DOM level for HTML5/SVG, and since so many people can use it (often brilliantly), it is a worthy and consistent objective for inclusion in our X3Dv4 efforts.

Recommendation: we should keep grasping toward this goal with gusto.  If we can fully align X3D with DOM, we will get the majority of CSS capabilities immediately since that is what HTML browsers (with contained CSS engines) do.

Alternate future if we align inside HTML5 without CSS:  Web authors ask ad infinitum "whaddaya mean, no CSS?!" followed by unhappy faces, hand gestures etc.  :0

So it appears that we know how all this will end... with success.  Looking forward to "doing the right things" and building continued progress together.

v/r Don

On 2/5/2017 7:05 AM, Joe D Williams wrote:
> 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

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