Stylehint support

[curiousdannii]

Issue for tracking progress.

Code: https://github.com/curiousdannii/glkote/tree/stylehints2

• Basic stylehint support
• Check how it works with autorestoring
• Support for garglk text formatting
• Window background colours
• Gargoyle style window padding?
• Paragraph stylehints
• Handle window clearing
• Update glkote.css
• Finalise stylehint protocol
• Style distinguish/measure
• Add glkote option to disable stylehints (useful for a terp to expose to the user)
• Documentation

[dfabulich]

I think this is the place we'd discuss stylehint support.

Here, I'd like to try to persuade @erkyrath to merge Dannii's stylehint changes.

On the forum, @erkyrath wrote:

https://intfiction.org/t/new-parchment-for-inform-7-template-now-with-quixe-and-stylehints/46160/25?u=dfabulich

The broader issue here, which I’ve been dancing around for years now, is that there’s no good compromise between (Z-machine) “here’s a tiny TTY device / fixed-width grid” and (Twine) “you got a damn web browser, everything is HTML and CSS, jQuery is installed, you’re on your own, pal.”

There may exist a sweet spot in between those extremes. I even have some notes on finding it[1]. What’s certain is that the stylehint API that I came up with in 1997 (for Glk/Glulx) is not that sweet spot. It’s terrible and almost completely useless, for a variety of reasons[2]. If there were a better option, it wouldn’t be compatible with stylehints as they exist today (to the extent that they exist today, which is not all that much). [3]

So, with apologies, no. Stylehints ain’t coming back. The answer to the question about Glulx Image Centering is that Glulx doesn’t support image centering.

Now, I realize this is a frustrating answer on at least two axes:

• Legacy Z-machine support is a real use case and Parchment wants to do it. Extending Quixe/GlkOte for Z-machine features (primarily color) is a reasonable thing to do. Those changes aren’t going to be absorbed back into the spec, but they can exist in Parchment and Lectrote as a separates set of files.
• Stylehints can’t do much but they can do centered text and inline images. As we see, people rely on this feature already, or want to. As a narrow use case, it’s pretty high return for a small amount of effort and complexity.[4] So there’s an argument for keeping that much of the old API un-deprecated.

Sorry about the long and inconclusive rant. :(

Footnotes, because I’ve been turning this over in my head since last night…

(1: Although that notes file has a last-touched timestamp of February 2012.)

(2: At a quick glance: Stylehints can only deal with integers. So no font names, no units on dimensions, no fractional numbers, for a start. Also, stylehints don’t encompass the difference between block (paragraph) and span (letter) styles. So no way to represent italics in a centered paragraph. Still less any fancier layout such as toolbars, menus, full-layout status windows, etc. More abstractly, stylehints are way too crude to balance the requirements of interpreter style control (app-wide font preferences, window size, etc) with the requirements of the author/designer. When I wrote down the initial ideas, I handwaved a lot and said “compromises are possible”, but there was never any plan for actually doing it.)

(3: The better way which exists today is Vorple, which I think demonstrates my point – it works by letting you get at the HTML/CSS directly.)

(4: To dig into this a bit: text centering does not clash with interpreter preferences/typography the way per-span color text does.)

Zarf raises two concerns with stylehints:

1. Preference Clash: Stylehints can clash with user preferences set in the interpreter
2. Inexpressive: Stylehints don't allow authors to express some desirable styles (italics in a centered paragraph)

The Preference Clash problem is a real problem, but that's an inherent problem with any system where authors are allowed to define their own text color. It's simply impossible to have the author define a text color and have the user define a text color (e.g. dark theme) at the same time.

Lectrote and Parchment should adopt the same solution for this as Spatterlight for macOS: a user-preference checkbox to override author colors. Spatterlight calls this "Games can set colors and styles," and the checkbox is checked by default. If you uncheck that box, Spatterlight disables stylehint support, ensuring that the user's color preferences can always rule over author-defined colors.

A user preference to override author colors is the best possible solution. I think Zarf incorrectly suspects that a better solution is possible if only he had more time to think about it. That's wrong; a checkbox to override author colors is fundamentally unimprovable.

I think the "Inexpressive" problem is unfortunate, but the limitations of stylehints are no reason not to provide excellent support for top-ranked legacy games like Blue Lacuna and Photopia, games that will almost certainly never be updated.

Someone might someday define a proposal for stylehints v2, integrate it into Glulxe Text Efforts for Inform, and then interpreters could be updated to support it. That sounds like a huge effort to me; I don't expect anybody will do it any time soon. Even if they did, that wouldn't fix Blue Lacuna and Photopia, and fixing Blue Lacuna and Photopia in no way interferes with that work.

[zarf]

Hey guys, You seem to have the wrong address for ***@***.***”. I’m receiving these emails as ***@***.*** ***@***.***> but they seem intended for another zarf ***@***.***>. Hope that can be put right.

…

On Dec 1, 2021, at 3:17 PM, Dan Fabulich ***@***.***> wrote: I think this is the place we'd discuss stylehint support. Here, I'd like to try to persuade @zarf <https://github.com/zarf> to merge Dannii's stylehint changes. On the forum, @zarf <https://github.com/zarf> wrote: https://intfiction.org/t/new-parchment-for-inform-7-template-now-with-quixe-and-stylehints/46160/25?u=dfabulich <https://intfiction.org/t/new-parchment-for-inform-7-template-now-with-quixe-and-stylehints/46160/25?u=dfabulich> The broader issue here, which I’ve been dancing around for years now, is that there’s no good compromise between (Z-machine) “here’s a tiny TTY device / fixed-width grid” and (Twine) “you got a damn web browser, everything is HTML and CSS, jQuery is installed, you’re on your own, pal.” There may exist a sweet spot in between those extremes. I even have some notes on finding it[1]. What’s certain is that the stylehint API that I came up with in 1997 (for Glk/Glulx) is not that sweet spot. It’s terrible and almost completely useless, for a variety of reasons[2]. If there were a better option, it wouldn’t be compatible with stylehints as they exist today (to the extent that they exist today, which is not all that much). [3] So, with apologies, no. Stylehints ain’t coming back. The answer to the question about Glulx Image Centering is that Glulx doesn’t support image centering. Now, I realize this is a frustrating answer on at least two axes: Legacy Z-machine support is a real use case and Parchment wants to do it. Extending Quixe/GlkOte for Z-machine features (primarily color) is a reasonable thing to do. Those changes aren’t going to be absorbed back into the spec, but they can exist in Parchment and Lectrote as a separates set of files. Stylehints can’t do much but they can do centered text and inline images. As we see, people rely on this feature already, or want to. As a narrow use case, it’s pretty high return for a small amount of effort and complexity.[4] So there’s an argument for keeping that much of the old API un-deprecated. Sorry about the long and inconclusive rant. :( Footnotes, because I’ve been turning this over in my head since last night… (1: Although that notes file has a last-touched timestamp of February 2012.) (2: At a quick glance: Stylehints can only deal with integers. So no font names, no units on dimensions, no fractional numbers, for a start. Also, stylehints don’t encompass the difference between block (paragraph) and span (letter) styles. So no way to represent italics in a centered paragraph. Still less any fancier layout such as toolbars, menus, full-layout status windows, etc. More abstractly, stylehints are way too crude to balance the requirements of interpreter style control (app-wide font preferences, window size, etc) with the requirements of the author/designer. When I wrote down the initial ideas, I handwaved a lot and said “compromises are possible”, but there was never any plan for actually doing it.) (3: The better way which exists today is Vorple, which I think demonstrates my point – it works by letting you get at the HTML/CSS directly.) (4: To dig into this a bit: text centering does not clash with interpreter preferences/typography the way per-span color text does.) Zarf raises two concerns with stylehints: Preference Clash: Stylehints can clash with user preferences set in the interpreter Inexpressive: Stylehints don't allow authors to express some desirable styles (italics in a centered paragraph) The Preference Clash problem is a real problem, but that's an inherent problem with any system where authors are allowed to define their own text color. It's simply impossible to have the author define a text color and have the user define a text color (e.g. dark theme) at the same time. Lectrote and Parchment should adopt the same solution for this as Spatterlight for macOS: a user-preference checkbox to override author colors. Spatterlight calls this "Games can set colors and styles," and the checkbox is checked by default. If you uncheck that box, Spatterlight disables stylehint support, ensuring that the user's color preferences can always rule over author-defined colors. A user preference to override author colors is the best possible solution. I think Zarf incorrectly suspects that a better solution is possible if only he had more time to think about it. That's wrong; a checkbox to override author colors is fundamentally unimprovable. I think the "Inexpressive" problem is unfortunate, but the limitations of stylehints are no reason not to provide excellent support for top-ranked legacy games like Blue Lacuna and Photopia, games that will almost certainly never be updated. Someone might someday define a proposal for stylehints v2, integrate it into Glulxe Text Efforts for Inform, and then interpreters could be updated to support it. That sounds like a huge effort to me; I don't expect anybody will do it any time soon. Even if they did, that wouldn't fix Blue Lacuna and Photopia, and fixing Blue Lacuna and Photopia in no way interferes with that work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACW6UMPODV5P2GCWWT6M4TUOZ7D3ANCNFSM4IQWPM7A>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dfabulich]

Forgive me! I should have written @erkyrath not @zarf.