[x3d-public] L.3.1 Re: Annex L HTML authoring guidelines for X3D4; naming Script versus X3DScript

[Andreas Plesch]

https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/htmlGuidelines.html

Section L.3.3 Cascading Style Sheets (CSS) considerations

The content refers to the 3d model elements' styling. I think adding
guidelines for styling capabilities of the rectangle of X3D graphics
on the page would be expected as well.

This includes outline details, z-order in layering, positioning on the
page, size, background style, post processing effects and other
capabilities.

Consider adding a sentence like

"The CSS styling of X3D models on the HTML page follows the styling of
an HTML canvas."

would encompass all existing styling options. All web browser
implementations allow this styling since they are using a Canvas
element in the first place.

continued ...

-Andreas

On Wed, Dec 30, 2020 at 12:30 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Hello Don,
>
> between the years a few continued comments on Appendix L:
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/htmlGuidelines.html
> :
>
> Section L.3.2
>
> "L.3.2 Syntax, capitalization and validation
>
> HTML has two encodings: HTML encoding (lower case, no self-closing
> tags) and XHTML encoding (CamelCase capitalization, well-formed XML
> elements).
>
> The naming of X3D elements and attributes match the allowed syntax of
> HTML where they appear, i.e. matching case conventions for a given
> HTML or XHTML encoding.
>
> X3D validation according to schema, DOCTYPE or other mechanisms
> requires strict compliance to upper/lower case name definitions in
> this specification."
>
> Strictly speaking, HTML encoding is case insensitive and allows lower
> case, upper case or CamelCase. All browsers are case insensitive for
> HTML tags, eg "<cAnVaS>" is allowed. All lower case tags are
> informally recommended and widely used since their use avoids
> complications. XHTML is XML and case sensitive.
>
> X3D validation in HTML should therefore also allow case insensitivity.
> eg. "<tRaNsFoRm>" would be valid. The appendix would recommend lower
> case X3D tags in HTML as a convention.
> If case insensitivity in HTML is not possible for validation purposes,
> lower case would need to be explicitly required in the wording.
> Currently, the intention of the last sentence is unclear. I think it
> means that X3D validation is only possible in XHTML ?
>
> .. continued, -Andreas
>
>
> On Tue, Dec 15, 2020 at 4:29 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > Hello Don,
> >
> > comments for section
> >
> > L.3.1 Content definition and page presentation
> >
> > It is helpful to define the two basic approaches to load X3D on a HTML
> > page initially.
> >
> > "Loading an external X3D model into a canvas portion of the HTML page."
> >
> > In reality, both approaches need to use a canvas portion/element of
> > the HTML page since this is the only way to render 3d graphics. So
> > this sentence is a bit misleading. The emphasis here should be on
> > "external". I suggest
> >
> > "Referencing an external X3D model in a HTML page media element."
> >
> > to avoid canvas, and point to similar HTML media elements such as img or video.
> >
> > "the HTML/DOM id attribute can be used for performing HTML event
> > callbacks using JavaScript."
> >
> > While being able to use the id attribute for selecting DOM nodes is
> > important, modern HTML can select nodes based on any CSS selector,
> > such as other attributes, classes, or node names. It would be expected
> > that such identification of nodes is also possible with X3D elements.
> >
> > "the HTML/DOM id attribute can be used for selecting X3D model
> > elements using JavaScript, as well as any other HTML selector."
> >
> > Selectors are defined in the HTML5 spec. (by referencing a css spec.).
> >
> > "Float above/below other layers of content on the HTML page."
> >
> > I am actually not sure what to make of this option. This option of
> > representation would be considered a style of the canvas element
> > mentioned in the first option. Any element on an HTML page can be
> > styled to float above or below other layers. Consider:
> >
> > "The visual representation of X3D models on the HTML page conforms to
> > an HTML canvas, including:
> >
> > Reserve a dedicated rectangular area (similar to historic EMBED
> > element), or else
> > Float above/below other layers of content.
> > "
> >
> > Given this, the background of an X3D model can also be defined by the
> > background of a canvas style. The expected layering from bottom to top
> > would be:
> >
> > - canvas style background (default transparent)
> > - X3D background (if not null)
> >
> > It may not be necessary to fully define this layering here since it is
> > automatic given that a canvas is used for X3D rendering. It will be
> > necessary if x3d becomes independent of canvas.
> >
> > ..continued, -Andreas
> >
> > On Mon, Dec 14, 2020 at 7:02 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> > >
> > > Hello Don,
> > >
> > > that looks great. If I may, I will go through the Annex section by
> > > section, starting with L.2.
> > >
> > > "Harmonize event models so that user interaction within the HTML page
> > > can also affect the X3D model, and vice versa."
> > >
> > > Although UI events such as a mouse click are most illustrative, I
> > > think that event harmonization design goals should also include non-UI
> > > events. For example, x_ite_dom forwards all X3D output events as DOM
> > > events (which can be received by DOM script API methods). Similarly,
> > > x3dom has an onoutputchange attribute for all x3d nodes. As a result,
> > > it is possible to monitor the position of a X3D scene object, for
> > > example, from the HTML/DOM page.
> > >
> > > So I would suggest to broaden the design goal to:
> > >
> > > "Harmonize event models so that DOM events such as user interaction
> > > within the HTML page can also affect the X3D model, and X3D events the
> > > DOM."
> > >
> > > ...continued, -Andreas
> > > -
> > >
> > > On Mon, Dec 14, 2020 at 5:11 PM Don Brutzman <brutzman at nps.edu> wrote:
> > > >
> > > > Thanks for discussion today John.  Clean copy ready for review:
> > > >
> > > > * Annex L HTML authoring guidelines for X3D4
> > > >    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/htmlGuidelines.html
> > > >
> > > > Prior issue of discussion was naming Script versus X3DScript.  I put 2 options in the guidelines:
> > > >
> > > > * L.4.1 HTML and X3D synchronization
> > > >
> > > > "Of note is that both HTML and X3D languages include definitions for a Script node, so disambiguation is necessary. One possible approach is to require that only X3D Script nodes can appear between X3D elements within an HTML page. An alternative approach is that any X3D Script node located within HTML page might be renamed X3DScript to avoid any name collisions."
> > > >
> > > > all the best, Don
> > > > --
> > > > Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> > > > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> > > > X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> > >
> > >
> > >
> > > --
> > > Andreas Plesch
> > > Waltham, MA 02453
> >
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453