[x3d-public] [x3dom-users] CSS bindings for <x3d> ...</x3d>
Joe D Williams
joedwil at earthlink.net
Wed Feb 22 16:49:38 PST 2017
----- Original Message -----
From: "Joe D Williams" <joedwil at earthlink.net>
To: "Leonard Daly" <Leonard.Daly at realism.com>
Sent: Wednesday, February 22, 2017 4:07 PM
Subject: Re: [x3dom-users] [x3d-public] CSS bindings for <x3d>
...</x3d>
>
> ----- Original Message -----
> From: "Leonard Daly" <Leonard.Daly at realism.com>
> To: "Joe D Williams" <joedwil at earthlink.net>
> Sent: Tuesday, February 21, 2017 3:40 PM
> Subject: Re: [x3dom-users] [x3d-public] CSS bindings for <x3d>
> ...</x3d>
>
>
>> Joe,
>>
>> I appreciate you putting your thoughts down so others can
>> understand
>> them.
>
> Thanks, I wish for understanding.
>
>> When you are going into technical matters, it is important to get
>> the details rights. CSS has very specific syntax when referring to
>> styles and selectors. Nodes (elements) do not have a prefix. ID
>> values
>> use '#', and classes use '.'. Refining the selector (parent -->
>> child)
>> uses a space. A comma is used to indicate 'OR'. A CSS selector to
>> identify an individual element without wildcards needs to use the
>> entire
>> element, ID, or class name.
>
> OK, I used some unusual syntax to think about it. I used the
> container name and the @name name to connect instead of the @class
> name.
>
>
>> Only when dealing with things in
>> programmatic manner (i.e., in jQuery or equivalent) can you use
>> wildcards or incomplete names.
>>
>
> I don't care about them, although they have pushed css to great
> capabilities.
>
>> Assuming you have a node tree something like:
>>
>> <Skeleton id='joe'>
>> <HAnimJoint DEF='joe_r_shoulder' class='r_shoulder'>
>> :
>> :
>> </HAnimJoint>
>> </Skeleton>
>>
Leonard, please look at the existing x3d abstract and xml for this
construction.
humanoid includes a skeleton field that contains the skeletal strucure
(except tendons and such are not yet included in the skeleton) the
hanim xml does not use the 'skeleton' wrapper tags - uses optional
containerfield
> The idea has to do with initializing hanim nodes. So, to make some
> sense, please take a look at an hanim skeleton.
>
> skeleton is the container where the joint sturcture is declared.
> One important parameter is the joint center. The joint center balues
> can be set by the user and as long as the joint hierarchy is right,
> the user can define custom dimentsions. To initialize theese to the
> user preference using a css file to initialize these values would
> probably be easier than changing the actual user code.
>
>
>>
>> skeleton#joe .r_shoulder { center: -0.2 1.44 -0.04; }
>>
>
> OK, that looks better and also says what needs to be done. Since
> there are nearly 100 of these in a complete LOA4 skeleton, I hope we
> can see that documenting these dimensions in a css 'table' would be
> easier than directly changing the user code.
>
>>
>> Note that if this were allowed, then you would need to consider
>> what
>> happens when you animation the CSS style definition, either
>> directly or
>> by using the style attribute and overriding the initial value.
>
> For css, if you change the css, then the dom also changes. If you
> change the dom, the css does not change directly, I have seen.
>
> It is not a 'standard' technique to animate the hanim joint center
> value directly. You apply a rotation to a joint and the child
> joint(s) move as expected. Animating the joint center directly will
> cause the skeleton to come apart and not work right (unless that is
> what you want to happen).
>
> Joint center is not an initializeOnly field but the user will not
> normally animate Joint center values. For any x3d initializeOnly
> field, the browser should not let you change it.
>
>>
>> BTW, I don't think you have three right thumbs.
>>
>
> Those thumb1, 2, 3 like the index1, 2, 3 are the joints, This is
> just a partial arm with only the thumb and index finger joints
> listed.
>
>>
>> Leonard Daly
>
> Thanks, Leonard.
> What do you think about pressing css for at least scene
> initialization? Every web author expects to be able to define at
> least the opening page (scene) style. I think this would also be
> useful for X3D. Please note that the dom interfaces are now complete
> enough to handle most any css operations including this type of
> initialization, 'live' updates to the dom by changing css values,
> and even including animations defined by css.
>
> All Best,
> Joe
>
>
>>
>>
>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> X3dom-users mailing list
>>> X3dom-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>>
>>
>>
>> --
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>>
>
More information about the x3d-public
mailing list