[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meetingdiscussions:Declarative 3D interest group at W3C

[Joe D Williams]

> CSS does have interpolators in CSS Animations. It includes 
> customizable easing functions. Probably the only practical CSS 
> properties to interpolate are transform and color, but that gets you 
> a lot of the interpolators in X3D. So the question becomes what do 
> you do about the rest?
>
>    a) Don't support them and use JS when need be?

too slow - scalar interps must be fairly simple once you decide what 
to interpolate against. Got TIme? Ooh well, if you have some litle 
engine under there doing 3D raytraces touches and selects anyway, and 
maybe access to its own script engine anyway, then maybe not so bad. 
Just tap in and what the heck just reach down to get host time 
directly. or use js settimeout(); or by frame count, who knows.

I am ready to start building the next frame.
Please tell me what time it is.

>    b) Add new properties to CSS to support them?

I think that you just go down the list of attributes you can safely 
call 'presentation' and go from there. I can easily see how CSS can be 
used here and from what I saw on the 3DCSS, very respectful and 
thought out, Thank You.

For setup, i don't see how it makes much difference whether you read 
layouts and geometry from a style sheet or directly in the user code, 
so I am very sympathetic to CSS in 3D and note that the class 
attribute remains on X3D XML elements. I do not see the need for a 
style attribute in X3D ...

and please don't forget about the 'cascading' part of this CSS stuff 
either - some think lots of style attributes might cascade from the 
parent DOM which may be the document DOM or some stylable parent. . .

So, anything you put in the style sheet available live to the CSSDOM 
of the 3D context) then I think should also be available to the 3D 
context DOM. I mean I hope to be able to set/change/create either by 
diddling the style sheet DOM or the actual DOM.
Ask how to make a interpolator declarative? Please see X3D 
interpolator objects.:) Maybe if the language is truely declarative, 
style attribute stuff just drops right out.
Size shouldn't matter about whether it is an attribute value or 
element content.

All there really is to ask is:
what can be done to produce the automation needed by the author to 
produce meaningful transactions? OK, too far, but procedure becomes 
style. All should be subject to control of author and user. But the 
list goes on. Automation is help on simple stuff that should be simple 
like interpolators, sequencers, timers, sensors, and ect. stuff like 
simple utilities that help to eliminate the need for those pesky 
scripts - that is automation. .

>    c) Represent them as elements?

that would be a declarative way. with important data as attributes of 
the element.
a great patten is shown in the world standard for this stuff, the X3D 
ISO spec..

What is style? please note that in X3D, most everything (data field) 
just happens to be an attribute. so just bury the actual functionality 
in a wrapper that names the procedure. That still impresses me about 
X3D is the range of authoring automation features that are available.

>
> There are different answers for different types and usage patterns. 
> That's what I mean by separating the issues. It's not "how do we 
> support inrpolators?", but rather "how do we support these useful 
> usage patterns, while still staying within the web model?"

I think the web model is clear.
* CSS for style (visibility/behavior/xflow?/whatever) attributes of 
any element;
* put it its own file;
* allow programatic access to the CSSDOM.
* Change to the CSSDOM are reflected where appropriate and when 
appropriate in the live context DOM and maybe even in decendants of 
the current DOM; and may be altered by CSS of a parent DOM.. .

>
> As much as you might like to warp the current web HTML/DOM model to 
> match what you perceive as the "right" way to do 3D, I don't see 
> that happening any time soon. I tried swimming up that stream for 
> many years with little success but with a lot of experience about 
> what NOT to do.

Yes, TIme is a longstanding issue with our html.
that is fine, just look how much apple has improved lately with this 
kind of stuff, you know the hyperlinked multiple media kind of shows. 
At this time I don't think there is a major X3D browser that ignores 
apple platforms (well never really ignored, just couldn't run there or 
something silly) so everyone has really stepped up.

> When my fellow team members and I here at Apple added CSS 
> Transforms, Transitions and Animations, we were able to get 3D into 
> the browser, not as a scene graph of 3D models but as "planes in 
> space". No monkeys or globes, but 3D that could be applied to many 
> web design scenarios.

OK, now I see why everything is getting better.

>
> That was step 1. Step 2 was making it possible to represent 3D 
> models in the simplest way possible - WebGL. Declarative 3D is step 
> 3.

OK, I can see that WebGL (what about Angle?) is here and primed to be 
great for delivery of 3D models. I would say OK figure out how you 
want to process events in this system of 3D models, then figure out 
what models to support. Or is it the other way around?

> This is all my personal model of world domination, of course. But I 
> believe that the step to declarative 3D has to be another baby step 
> or it will fail.

Hey Chris, thanks much to you 3D will not fail and is here to stay. 
3DCSS is a great idea. Please show this at the next web3D.org show.

First thoughts are that I think CSS is built for control of attribute 
values. Since all X3D important data is writable as attribute name 
value pairs, then, CSS should work fine.
Just how to associate changes to the CSSDOM with changes made to the 
actual DOM may be a question.

Or, maybe this is really dividing it up to who gets access to what 
data. Are you willing to hide data in a separate file from the main 
user code?
anyway all may be aimed at deciding what features of an element are 
available by what means.

Things that are obviously 'style' need to be updated in different 
patterns than other stuff, like actual content. So, by default and 
historical precedence some stuff you change through
object.element.style.name.value
and some writing a block of content directly as
object.element.innerhtml.value

Ideally this would be clean divide. Like X3D attributes that are 
initializeOnly, you can play with 'style' without messing up the 
graph, mostly, but some stuff, when you change it, you may as well 
start some big processes from scratch.
So changing the scale of a sphere is easy but changing its number of 
vertices is a much bigger process. So some of what is style and what 
is content depends upon the encoding techniques you choose and some 
may be influenced by the way the platform runtime uses and allows 
updates to the data structures.

I just hope me being impressed by the 3DCSS is not its kiss of death.

Good Luck and Best Regards,
Joe