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

[Don Brutzman]

Thanks for continued review, much appreciated.  Dick and I reviewed these today.

On 12/15/2020 1:29 AM, Andreas Plesch 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.

agreed and accepted.

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

Agreed and accepted with slight modification, avoiding possible ambiguity regarding which script node...

"the HTML/DOM id attribute can be used for selecting X3D model elements using HTML-page Script nodes (as can any other HTML selector)."

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

thanks for helpful scrutiny, this is a bit tricky to express.  agreed that goal is generic expressiveness of the concept, not detailed precision...

we got a bit convoluted when parsing your prose... here are latest versions of the two sentences:

========================
(L.3.1 Content definition and page presentation)
[...]
X3D Background /transparency/ field allows HTML layer(s) beneath an X3D model to be visible (whether floating or fixed). This capability can support special layouts for page composition.

(L.4.3 User focus considerations)
[...]
Of interest is that X3D scenes can include Background /transparency/ field that may reveal underlying HTML content unobscured by geometry. X3D browsers may optionally pass user-driven events back to the underlying page layers for further HTML/DOM processing.
========================

Changes checked in and pushed.  Thanks for continued scrutiny.

> 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