[x3d-public] FontStyle/ScreenFontStyle 'style' field naming collisions with CSS style, issue resolution
John Carlson
yottzumm at gmail.com
Mon Dec 21 11:06:09 PST 2020
+1 for Nicholas’ idea. We will still need to rename the “class” getter,
setter, etc in x3dpsail I think.
John
On Mon, Dec 21, 2020 at 12:35 PM Don Brutzman <brutzman at nps.edu> wrote:
> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201221/d85a08f4/attachment-0001.html>
More information about the x3d-public
mailing list