<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Joe,<br>
      <br>
      I do not quite follow your message. 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. <br>
      <br>
      Looking at these one at a time:<br>
      1) X3D is deficient: X3D V3.3 (latest release) was not designed
      with DOM integration. 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. In
      this case you are making a recommendation for a future version of
      X3D.<br>
      <br>
      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.<br>
      <br>
      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. <br>
      <br>
      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.<br>
      <br>
      <br>
      (*) Reasonable request means that it is not so far out of scope of
      X3D, X3DOM, or the general environment of displayed 3D content in
      web browsers. I am not commenting one way or another on whether
      the request is a good or bad idea.<br>
      <br>
      <br>
      Please let me know if your message address one (or more) of the
      four items listed above or something else entirely.<br>
      <br>
      <br>
      Thanks,<br>
      <br>
      Leonard Daly<br>
      <br>
      <br>
      <br>
      <br>
      On 2/5/2017 7:05 AM, Joe D Williams wrote:<br>
    </div>
    <blockquote
      cite="mid:9A868DDC0726451AB49DA67F973ABD9E@joe1446a4150a8"
      type="cite">
      <blockquote type="cite">From what I can see <x3d> continues
        to ignore use of css selectors as </blockquote>
      an optional author tool with <x3d> user code. We have a
      connection 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 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 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.
      <br>
      <br>
      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.
      <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, 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
      <br>
      <br>
      So, style by class in html hosted content is so basic because its
      case 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
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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?
      <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 building the opening scene in a script that reads a list to
      generate 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 html dom script.
      <br>
      Actually, for simple stuff I don't want get into scripting the
      html dom; I'd rather script the css dom.
      <br>
      <br>
      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.
      <br>
      <br>
      Is it a complication or an advantage that fields of X3D XML nodes
      are attributes and so are candidates for <style> treatment?
      <br>
      <br>
      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.
      <br>
      <br>
      For the most part, these authors and their authoring aids depend
      on DOM and CSS.
      <br>
      <br>
      <x3d> without total dom and total css integratable with
      html5 is not really a complete standards-track package.
      <br>
      <br>
      Thanks and Best,
      <br>
      Joe
      <br>
      <br>
      <br>
      <br>
      _______________________________________________
      <br>
      x3d-public mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
      <br>
      <br>
    </blockquote>
    <br>
    <p><br>
    </p>
    <div class="moz-signature">-- <br>
      <font class="tahoma,arial,helvetica san serif" color="#333366">
        <font size="+1"><b>Leonard Daly</b></font><br>
        3D Systems & Cloud Consultant<br>
        LA ACM SIGGRAPH Chair<br>
        President, Daly Realism - <i>Creating the Future</i>
      </font></div>
  </body>
</html>