[x3d-public] FontStyle/ScreenFontStyle 'style' field naming collisions with CSS style, issue resolution

[Don Brutzman]

Interesting progress following last Friday's detection and discussion about FontStyle/ScreenFontStyle 'style' field.

[1] X3D minutes 18 DEC 2020: X3D4 review, ballot in progress, CSS class/style naming collisions, issue resolution continues
     http://web3d.org/pipermail/x3d-public_web3d.org/2020-December/014295.html

On 12/18/2020 10:20 AM, Don Brutzman wrote:
> a. FontStyle and ScreenFontStyle have style attribute, which is a name collision for CSS style attribute.

> Meanwhile

[2] X3D4 Architecture, Annex L HTML Authoring Guidelines
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/htmlGuidelines.html#CSS
> 
> How to handle?
> 
> Of note is that X3DJSAIL dealt with a similar issue before, a Java-API problem with CSS 'class' colliding with Java reserved word 'class' and renamed it cssClass.  Similar approach was likely necessary in Python; such collisions are to be expected for common terms.
> 
> X3D4 general goals and priorities:
> a. Retain information in legacy X3D/VRML models.
> b. Retain as much existing common practice as possible.
> c. Minimize field name changes when possible/advisable.
> d. Allow consistent portability of content across all X3D file encodings and language bindings (even if something like a CSS-related value is not expected to be used).
> e. Permit interoperation with HTML and CSS without conflict.

so far so good.  getting specific:

=====================================================================
[3] X3D4 Architecture, Text component, 15.2.2.2 Font family and style
     https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/text.html#Fontfamilyandstyle

Font attributes are defined with the family and style fields. The browser shall map the specified font attributes to an appropriate available font as described below.
[...]
The style field specifies a case-sensitive SFString value that may be "PLAIN" (the default) for default plain type; "BOLD" for boldface type; "ITALIC" for italic type; or "BOLDITALIC" for bold and italic type. An empty style value ("") is identical to "PLAIN". In the case where the requested style is not available, the available style that is closest to the requested style shall be used. For example, some font families specify a Demibold style rather than Bold. In this case, specifying "BOLD" will result in the browser using Demibold as the nearest substitute.

=====================================================================
[4] X3D4 Architecture, Text component, 15.4.1 FontStyle
     https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/text.html#FontStyle

15.4.1 FontStyle
FontStyle : X3DFontStyleNode {
   SFNode   [in,out] metadata    NULL    [X3DMetadataObject]
   MFString []       family      "SERIF"
   SFBool   []       horizontal  TRUE
   MFString []       justify     "BEGIN" ["BEGIN","END","FIRST","MIDDLE",""]
   SFString []       language    ""
   SFBool   []       leftToRight TRUE
   SFFloat  []       size        1.0     (0,∞)
   SFFloat  []       spacing     1.0     [0,∞)
   SFString []       style       "PLAIN" ["PLAIN"|"BOLD"|"ITALIC"|"BOLDITALIC"|""]
   SFBool   []       topToBottom TRUE
}
=====================================================================

> It would seem we have three approaches possible here:
> =====================================================
> i.   Specialized CSS-field names peculiar to FontStyle and ScreenFontStyle,

pro: avoids name collision,
con: irregular, makes applying CSS styles harder, seeming showstopper since FontStyle is primary candidate for styling.

> ii.  Change X3D FontStyle and ScreenFontStyle /style/ fields, renaming as /x3dStyle/ or /presentationStyle/ or somesuch, avoiding future naming collisions altogether.  This would obviously be part of our differences between X3D3 and X3D4.
pro: avoids name collision,
con: requires translation of field values when converting or loading between X3D3 and X3D4.

Discussed this with Dick.  Viable, but naming remains tricky.  Least-worst name that we came up with: 'glyphStyle' might work.

> iii. Rename reserved words in X3D to cssClass and cssStyle for consistency throughout all of our file encodings and programming-language bindings.  Also avoids collision with HTML DOM CSS 'class' and 'style' attributes within the DOM.

still somewhat problematic.  not a bad approach for X3DJSAIL and X3DJSAIL methods (consistently avoiding potential naming collisions with reserved words in Java, Python languages).

pro: separation of fields,
con: any X3D embedded in HTML no longer has same 'style' attribute, and so seeming showstopper since combined HTML/X3D styling (an expected use case) becomes impractical.

---

iv. Simpler representation: booleans.

The exact same information might be represented as follows.  No loss of generality since other values are not permitted.

SFBool [] bold    FALSE
SFBool [] italics FALSE

pro: simple, identical functionality, no name collisions.
con: requires conversion X3D3-X3D4, possible contrary values if CSS style is also provided.

---

Discussion and great idea by Nicholas:

v. Keep the same field name.  Define functionality that FontStyle can parse either classic or new 'style' values compatibly.

pro: "embracing the collision" for best of both worlds, no X3D3/X3D4 conversion or import problems.
con: none yet seen...

Here are the classic allowed values for the 'style' field, with CSS equivalents:

PLAIN      	font-weight: normal; font-style: normal;
BOLD       	font-weight: bold;   font-style: normal;
ITALICS    	font-weight: normal; font-style: italic;
BOLDITALICS	font-weight: bold;   font-style: italic;

[5] W3C, CSS Fonts Module Level 4, Editor’s Draft, 15 December 2020
     https://drafts.csswg.org/css-fonts

     2.2. Font weight: the font-weight property
     https://drafts.csswg.org/css-fonts/#font-weight-prop

     2.4. Font style: the font-style property
     https://drafts.csswg.org/css-fonts/#font-style-prop

> =====================================================
> 
> Of related note is that X3DOM already uses WebFonts to control font and style.
> 
> [2.2] X3DOM Text Example
> https://x3dom.org/x3dom/example/x3dom_text.html
> 
> [2.3] Webfonts: W3C Fonts on the Web
> https://www.w3.org/Fonts

So implementability seems to be well established.  All of the X3D Example Archives scenes converted to X3DOM HTML include this css.

[6] X3D Resource, X3D Examples Archives
     https://www.web3d.org/x3d/content/examples/X3dResources.html#Examples

Other browsers are in good shape with this approach.  Might wait to add such functionality at whatever time they want without loss of backwards compatibility with X3D3.

Something I like: zero barrier to long-term adoption of CSS in X3D, if people want.

> All insights welcome.
> 
> Next steps:
> - document in Mantis,

[7] Mantis 1335: FontStyle/ScreenFontStyle 'style' field naming collisions with CSS style
     https://www.web3d.org/member-only/mantis/view.php?id=1335

> - continue implementation testing, report back.  Temporary testing of option (iii) seems possible now, option (ii) is promising.

Option v (allow either functionality in FontStyle 'style' field) is most elegant and expressive with least complication.  Now available in current validation tools.

Option ii (rename as classic 'style' as 'glyphStyle') has some interest, and so is implemented in current validation tools, so that for comparison, we can also see corresponding auto-implementation methods in X3DJSAIL Java, X3DPSAIL Python, and X3D Ontology Turtle.  However this is temporary and, following review, expect to remove it before the end of the month.  All feedback welcome.

> - Broader discussion is certainly appropriate.

Thanks + bravo to Dick and Nicholas for close scrutiny. Feedback and improvement always welcome.

I think we have opened the door to a "best of both worlds" approach.  Having fun with X3D4.  8)

[8] Van Halen - Best of Both Worlds (OFFICIAL VIDEO)
     (don't forget to select Loop and Full Screen!)
     https://www.youtube.com/watch?v=yZ7ywrl5oMo
     RIP Eddie.

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