[x3d-public] CSS bindings for <x3d> ...</x3d>
Joe D Williams
joedwil at earthlink.net
Tue Feb 21 04:30:29 PST 2017
Hi All, thanks for all your comments on this.
CSS provides a simple, highly structured syntax providing default and
author-defined values for style and presentation of certain element
and attribute content.
* any x3d initializeOnly fields.
(part of scene initialzation; like a script initialize function)
* any inputOutput and inputOnly fields including url.
(inital settings at scene initialization;
live update via <style> like script directOut=true)
Here is an example using part of an .x3d HAnim model of the 'standard'
skeleton. This is the shoulder, thumb and index finger skeletal
structure.
...
<HAnimJoint DEF='joe_r_shoulder' center='-0.2 1.44 -0.04'
name='r_shoulder'>
<HAnimJoint DEF='joe_r_elbow' center='-0.2 1.1388 -0.04'
name='r_elbow'>
<HAnimJoint DEF='joe_r_wrist' center='-0.2 0.89 -0.04'
name='r_wrist'>
<HAnimJoint DEF='joe_r_thumb1' center='-0.2 0.85 0'
name='r_thumb1'>
<HAnimJoint DEF='joe_r_thumb2' center='-0.2 0.82 0.03'
name='r_thumb2'>
<HAnimJoint DEF='joe_r_thumb3' center='-0.2 0.8 0.05'
name='r_thumb3'>
</HAnimJoint>
</HAnimJoint>
</HAnimJoint>
<HAnimJoint DEF='joe_r_index0' center='-0.2 0.84 -0.015'
name='r_index0'>
<HAnimJoint DEF='joe_r_index1' center='-0.2 0.793 -0.015'
name='r_index1'>
<HAnimJoint DEF='joe_r_index2' center='-0.2 0.745 -0.015'
name='r_index2'>
<HAnimJoint DEF='joe_r_index3' center='-0.2 0.72 -0.015'
name='r_index3'>
</HAnimJoint>
</HAnimJoint>
</HAnimJoint>
</HAnimJoint>
...
</HAnimJoint>
...
It may look complicated, but is really just a strict hierarchy of
Joint nodes with 'standard' names for a set of features defined by the
spec. The most important names in HAnim are the Joint DEFs which are
the basic animation interfaces.
The objective in this example is allowing easy changes to a basic
skeleton model for personalized customization of the character. For
instance the user may wish to document personal dimensions and
characteristics.
With HAnim, the dimensions of the 'standard' skeleton, the x y z
coordinates of each Joint or other feature Site locations, are defined
in 'human' space and determined in a 'standard' initial pose. The
HAnim specification gives a 'nominal' value based on a wide range of
measured data and those figures are used in this example.
The following example x3d hanim css for this example may also look
complex, but actually only scratches the surface. First, this is just
part of a list of all 'standard' joint nodes in a fully articulated,
realistically animated humanoid skeleton. Second, this is only a small
subset of attachments and enhancements that could be part of <style>
for scene initialization.
In this HAnim case to simplify, I am just using the combination of the
containerfield name and the @name field as the selector. In this
example, the listed values would be applied to the nodes at time of
scene initialization.
<style ... >
...
#x3dinitialize:
skeleton.r_shoulder { center: -0.2 1.44 -0.04; }
skeleton.r_elbow { center: -0.2 1.1388 -0.04; }
skeleton.r_wrist { center: -0.2 0.89 -0.04; }
skeleton.r_thumb1 { center: -0.2 0.85 0; }
skeleton.r_thumb2 { center: -0.2 0.82 0; }
skeleton.r_thumb3 { center: -0.2 0.8 0.05; }
skeleton.r_index0 { center='-0.2 0.84 -0.015; }
skeleton.r_index1 { center='-0.2 0.793 -0.015; }
skeleton.r_index2 { center='-0.2 0.745 -0.015; }
skeleton.r_index3 { center='-0.2 0.72 -0.015; }
...
</style>
This could leave the user code as:
...
<HAnimJoint DEF='joe_r_shoulder' name='r_shoulder'>
<HAnimJoint DEF='joe_r_elbow' name='r_elbow'>
<HAnimJoint DEF='joe_r_wrist' name='r_wrist'>
<HAnimJoint DEF='joe_r_thumb1' name='r_thumb1'>
<HAnimJoint DEF=joe_r_thumb2' name='r_thumb2'>
<HAnimJoint DEF='joe_r_thumb3' name='r_thumb3'>
</HAnimJoint>
</HAnimJoint>
</HAnimJoint>
<HAnimJoint DEF=joe_r_index0' name='r_index0'>
<HAnimJoint DEF='joe_r_index1' name='r_index1'>
<HAnimJoint DEF='joe_r_index2' name='r_index2'>
<HAnimJoint DEF='joe_r_index3' name='r_index3'>
</HAnimJoint>
</HAnimJoint>
</HAnimJoint>
</HAnimJoint>
...
</HAnimJoint>
...
So when the scene is loaded and the style sheet data applied as an
orderly part of scene initialization (basically same as a script node
initialize () function)
then the skeleton would be constructed with the <style> dimensions.
Well, that is just a simple first cut at why I want to be able to use
<style> to initialize a complex scene.
More later,
Joe
----- Original Message -----
From: "Joe D Williams" <joedwil at earthlink.net>
To: <x3d-public at web3d.org>; <x3dom-users at lists.sourceforge.net>
Sent: Sunday, February 05, 2017 7:05 AM
Subject: [x3d-public] CSS bindings for <x3d> ...</x3d>
> 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
>
>
>
> _______________________________________________
> 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