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

[Joe D Williams]

Hi Leonard,

----- Original Message ----- 
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: <x3d-public at web3d.org>; <x3dom-users at lists.sourceforge.net>
Sent: Sunday, February 05, 2017 8:26 AM
Subject: Re: [x3d-public] CSS bindings for <x3d> ...</x3d>


> Joe,
>
> I do not quite follow your message.

OK, let's start with the idea that in html, there can be an individual 
style sheet .css for each html execution context.

> I am confused and not sure if you
> are expressing a desire for a future release of X3D or X3DOM or are
> reporting an issue where X3DOM fails to meet a specification or X3D 
> is
> deficient.

Yes, X3D is deficient in the current V3.3 in a potential V3.4 and in 
any proposed V4.0 if it does not implement an extensible idea of 
<style>.

>
> Looking at these one at a time:
> 1) X3D is deficient: X3D V3.3 (latest release) was not designed with 
> DOM
> integration.

True, V3.3 is designed to able to document and run as an independent 
execution context, that can contain a hierecchy of indepedent 
execution contexts. So, V3.3 XML is not designed for dom integrationn, 
but rather that X3D can be implemented as a child execution context in 
a dom environment, and can include a dom child exectuion context.

> While it does allow the class attribute, it defines no
> specific behavior for any values or even that an X3D browser shall 
> do
> certain things if  certain styles are present.

Yes, I think the basic behaviour is that the css uses some kind of 
hierarchal structure of style attributes most of which are identifed 
with elements and attributes of the dom. It turns out that the style 
attributes can be inherited thruogh the various hierarchal structures 
of the content. It seems like it works as if you can change the dom 
using a dom script on a dom element or attribute and it doesn't 
necessarily change the style value, but if you change the style, then 
it propagates through the dom to change the presentation as expected. 
However, you get a set of style infaces with the dom, and if you 
change the style by script, then the dom gets updated automagically.

> In this case you are
> making a recommendation for a future version of X3D.

I can only say the following:
>>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>.

So, there is little question that html is not html without style.
Since the idea of a cascading style works so well is, well dfor one 
thing it directly exposes inheritance of attributes though a tree, or 
even a dag.

>
> 2) X3DOM fails to meet a specification: Mostly see (1). There is no
> specification that covers the X3DOM operational environment. In this
> respect, X3DOM is a prototype and meant to explore future 
> possibilities.
>

x3dom has some examples. Of course the height and width should be 
styleable, but just check out that css alternative to direct dom 
scripting for when you want to increment some values. Just amazing, 
and it looks enough like .<x3d> timers and interp to be transcoded, ad 
so much less complex than a conventional dom script. But, still needs 
some work for 3d transforms, I think?

> 3) Future release of X3DOM: This is a reasonable request (*), though 
> I
> am not sure why it was sent to x3d-public as it deals with X3DOM
> development.

Sent both, I thought. Do anyone have a spec?

>
> 4) Future release of X3D: This goes back to (1) and is a reasonable
> request (*), though I am not sure why it was sent to x3dom-users as 
> it
> deals with X3D specification development.

OK, so, X3DV3.4 is a defined target. See, css is like the corner that 
was turned when a thing like hanim decided to actually openly encode 
the skeleton. Before that, you just sent in a list of values, really 
sort of like 'style' sheet, and the thing got simulated. For current 
hanim it was decided to eliminate the 'style' sheet except for the 
remanent lists of uses of joints segments sites fields, and just 
depend upon manipulating the user code.

Now we need style sheets (again, but these things were always an 
alternatively way of defining the skeleton of a document 
presentation - even basic olest html used default 'style' properties . 
Do I think i would like to have a humanoid specified using a style 
sheet that lists the joint centers, sites, and geometries?

For <x3d version='4.0' or however that comes out, then of course css 
has to be defined, just like other true standards-track components of 
current html browsers.

At his point, with extensions of css believes that w3c <html> 
standard-track <x3d> without <style> is possible to advance?

Are we going to see the day when of course an html page can be 
included as a part of <x3d> context, and vice-versa. Well the x3d 
inline is at as good as an html <iframe> or <object>  so ... of 
course.

>
>
> (*) Reasonable request means that it is not so far out of scope of 
> X3D,

Please, no unreasonalbe requests intended. Just recognition of the 
target space. Please look again and see if there are any points that 
seem agreeable.

> X3DOM, or the general environment of displayed 3D content in web
> browsers.

Yes, I am sure.

I am not commenting one way or another on whether the request
> is a good or bad idea.
>

Well, at this point it would be good to have an open mind, but it may 
help to try some of the new css stuff. x3dxnl showed it using some 
shader-style, i think, so mainly ths just needs some thought and work.

Thanks, that reminds that I need a good web3d.org spec comment 
submission.

>
> Please let me know if your message address one (or more) of the four
> items listed above or something else entirely.
>

Yes, I hope all four.

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

?

css starts looking like some version of json at some pont, so how to 
set some consistent and understandable rules about what are the 
<style> interfaces.

>> 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.
>>

Do those basic needs seem realistic? I mean modern css as a means to 
control presentation is so poworful that it cannot be ignored.

>
> Thanks,
>
> Leonard Daly
>

Thanks and Best, Leonard,
Joe


>
>
>
> 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
>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>
>
> -- 
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>


--------------------------------------------------------------------------------


> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>