<div dir="auto">SVG does have styles and there are good examples how styling can be useful there.<div dir="auto"><br></div><div dir="auto">So X3D also would probably benefit from accepting a layer of field value reassignment from style sheets to enable reuse.</div><div dir="auto"><br></div><div dir="auto">An example would be a flower group where petal shape appearance colors could be styled.</div><div dir="auto"><br></div><div dir="auto">A second flower could have a different id or class and could be styled differently.</div><div dir="auto"><br></div><div dir="auto">This brings up that there is overlap between reuse by styling and reuse by protos.</div><div dir="auto"><br></div><div dir="auto">There are probably nodes and fields which shouldn't be subject to styling.</div><div dir="auto"><br></div><div dir="auto">X3dom has some css support.</div><div dir="auto"><br></div><div dir="auto">Andreas</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 5, 2017 10:05 AM, "Joe D Williams" <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>From what I can see <x3d> continues to ignore use of css selectors as<br>
an optional author tool with <x3d> user code. We have a connection<br>
with the document <script> but not with document <style>.<br>
<br>
As for css, I trust that every html author will expect to be able to<br>
define an opening scene that is easily changed using css style api.<br>
<br>
Since the <x3d> elements are available in the dom, and are accesible<br>
by dom api, then of course I ought to be able to realtime style basic<br>
elements of a scene using css, and control some or all features of the<br>
scene by changing live css user code, or by changing the node @class<br>
attribute.<br>
<br>
Yes, the above is now for a long time 'native' to css for html5. To<br>
me, coverage of css is basic because it is NOW the actual minimum<br>
requirement for a conforming html/css/svg/mathml/dom w3c browser.<br>
To add x3d to that list, <x3d> gotta have <style>.<br>
<br>
Yes, live, cascading style is so fundamental to operation of the dom,<br>
that css even provides script-free animation techniques. Some of these<br>
expose some <x3d> features, like keyframe interpolation. Just like<br>
X3D, implementation of style animation "in" the browser makes<br>
performance of this "built-in" stuff kill conventional html dom<br>
scripting for similar effects<br>
<br>
So, style by class in html hosted content is so basic because its case<br>
is so true -<br>
Authors can use it to distinguish style from content.<br>
<br>
This remains true and to the extent that lines between content and<br>
style cross. Most of the crossover is actually under control of the<br>
author because the dom and css properties of the elements overlap.<br>
This gives some suthor flexibility, allowing style to convy content<br>
and vice-versa.<br>
<br>
Perhaps the greatest contribution of this melding of html and x3d is<br>
that Finally, yes FFinally, X3D gets some "Style" which thus far<br>
mostly forbidden territory even considering the fact that X3D since<br>
inception has included the heretofore unused class attribute. Up to<br>
now there has been no great press for css in .x3d - let's face it, css<br>
didn't have much back then except fataastic potential to offer our<br>
DAG, but .x3d is now facing up to <x3d> in <html> so a New Higher<br>
level of X3D htmlization and domification is near.<br>
<br>
The only problem is, whatever the x3d elements chosen, the community<br>
must define what @class attributes can be controlled by css. For<br>
example can you apply the css @hover on a shape or a geometry or does<br>
it matter?<br>
<br>
Of course I want css for my list of initializeOnly fields!<br>
Why, because it very easy to author using 'style' sheets instead of<br>
building the opening scene in a script that reads a list to generate<br>
the opening scene.<br>
In <x3d> is there any such thing as the 'initializeOnly' field?<br>
Of course I want css control of any node attribute I can reach with<br>
html dom script.<br>
Actually, for simple stuff I don't want get into scripting the html<br>
dom; I'd rather script the css dom.<br>
<br>
It is easy to see how a player that does <x3d> can implement a<br>
reasonable set of css properties for the x3d nodes and fields that<br>
need them. I mean look, html dom and html allowed the css to be<br>
domified and cacadiatied thus allowing intimate relationships, deeply<br>
changing realtime yet carefully sequenced, directly with some exposed<br>
and some internal dom events using very stimulating cascading<br>
interfaces.<br>
<br>
Is it a complication or an advantage that fields of X3D XML nodes are<br>
attributes and so are candidates for <style> treatment?<br>
<br>
So, certainly this will get some thought and work, but I stand with<br>
the idea of looking at it from the standpoint of what the experienced<br>
html/dom/css designer/author/user is going to expect.<br>
<br>
For the most part, these authors and their authoring aids depend on<br>
DOM and CSS.<br>
<br>
<x3d> without total dom and total css integratable with html5 is not<br>
really a complete standards-track package.<br>
<br>
Thanks and Best,<br>
Joe<br>
<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, SlashDot.org! <a href="http://sdm.link/slashdot" rel="noreferrer" target="_blank">http://sdm.link/slashdot</a><br>
______________________________<wbr>_________________<br>
X3dom-users mailing list<br>
<a href="mailto:X3dom-users@lists.sourceforge.net">X3dom-users@lists.sourceforge.<wbr>net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/x3dom-users" rel="noreferrer" target="_blank">https://lists.sourceforge.net/<wbr>lists/listinfo/x3dom-users</a><br>
</blockquote></div></div>