Internally, the compiler now keeps track of two separate values for each style class: “style” is which styles it should set, and “unstyle” is which styles it should unset. Anything that’s not in either of those values is inherited. This follows usual CSS practice: a bold span inside an italic span should print in bold italics, unless the bold span explicitly specifies font-style: normal;.
Reverse-video is now set with text-decoration: reverse; which is not standard CSS, but an unrecognized property value isn’t an error in CSS, so it should be fine.
Status bars also no longer need to be in reverse-video style; they will be by default, but if you have reverse-video in the “unstyle” field of the style class (by setting text-decoration: none;), the foreground and background will not be reversed.
As you can see, other styles are now supported in the status line too, though the Z-machine standard specifies that it must always be monospaced (and Glk enforces this with how text grid windows work).
Finally, this means that inline style predicates are no longer needed, and can be deprecated without any loss of functionality!
I’ll make a new pull request for this, and bump the version number to “1a02”—1 because it’s not Linus’s work, a because no changes have been made to the language, 02 since it’s the second pull request.
Oooh, that’s clever, almost wish I’d thought of that for GlkOte/Parchment. But my way (setting a distinct reverse property) is probably slightly simpler to parse, as someone could want to use both reverse and underline. Not that you can do that in Parchment currently, but in the future…
Oh, how does Parchment do it? It could be useful to make them compatible.
Currently, it looks for reverse anywhere in the declaration, so you can do text-decoration: underline reverse; to combine them. I’m not sure how browsers feel about that, though.
Cool. I always get a bit confused when the term status line is used for post-V3 games. I realize that’s what the upper window tends to be used for, but it throws me off nevertheless.
And rounding out this Z-machine style support spree, display:none has been added, for text that should go to the transcript but not to the screen. For example, if you print a fancy quote box using the status bar, you can also send it to a display:none div in the main window, which will ensure it’s properly recorded in the transcript without the player seeing anything unusual.
If you want to be really fancy, you can even do something like this…
Now all italicized text in the game will be wrapped in <i> </i> tags in the transcript—something I’ve long wished for while doing let’s-plays! (And of course, as a bonus, nested (emph $) calls will toggle italics on and off for each one—the proper typographical way to handle nested emphases.)
My styles expansion to the GlkOte protocol has two non-standard CSS properties: reverse and monospace. In this case I don’t think there’d be any advantage to using the same properties as Dialog and GlkOte really don’t have anything in common here, and I think it would complicate matters too much on the Glk side (for example, eventually I’ll release a Glk extension letting you set your own styles, and someone might not realise setting underlining styles could erase their reverse style). I just thought your approach was clever and elegant.
Thanks Linus! Sorry to drag you away from your other projects and into a 100+ post forum thread… but I think this puts us on a really good footing, and I’m glad it sounds like we’re on the right track so far.
Fixing this required me to set monospaced text to display: inline-block; and so that that worked across lines, then required each word to be broken up into its own <span>.
And then to get background colours working in our high-DPI era, I had to learn about font ascents/descents and leading, and then calibrate my styles to the fonts that I wanted to use. Including using the @font-face ascent-override/descent-override properties to make some fonts act like other fonts, in case Georgia isn’t installed in the browser. (Though I’m just now wondering if maybe this would be a better approach than the display: inline-block I mentioned above…)
I also needed to support the rare but legal option of switching the preformatted Glk style to using a proportional font.
All to say that AsyncGlk is doing a lot to make all the various formatting possibilities play nicely together, and to work across browsers and OSes, and I thought it would be better to use a custom CSS property to indicate that you’re switching the whole system on.
In the future when I add glk_css_inline_set to let you arbitrarily set CSS properties you could just set the font-family manually, but you wouldn’t get the rest of it.
Adding a wish to the wishlist: Hyperlinks in choice-style output, in particular to make it more ergonomic to play the aastories exported to HTML on a mobile browser.
Or maybe that is already supported and I just did something wrong?
After re-reading the section on hyperlinks I think some modification would be required. The links only insert the text from the link at the prompt? So tapping the “2” in front of one of the choices would put “2” at the prompt, but then the user still has to press enter?
If that is the case, then I guess my wishlist is to modify the aamachine with some setting to make links instantly submit, so pressing the “2” causes input “2 (ENTER)”. (EDIT: In addition to modifying the library to inserting hyperlinks for each choice, but I guess that is the easy part? Not that I tried to find the code for that.)
There was a lot of fiddling with the on-screen keyboard when I tried to play the example choice-based game in a mobile browser.
Nope, links submit the text, not just inserting it. This means you need to do some parser modifications if you want the user to choose both verb and noun with hyperlinks.
Speaking of this bug, I think I’ve now fixed it. Time to feel unreasonably proud of this for a while. (Addresses were being compared to object numbers with the @jg opcode, which does signed comparison, so addresses above $8000 were not considered to be greater than the maximum object number, and thus treated as objects instead of memory locations. This would then crash the interpreter.)
Same! I’ve steamed ahead with a new project in Inform 7, but it’s tempting to at least start a re-implementation in Dialog…
That does make me think of something I’d put on my Dialog wishlist though!
The first thing I’ll do if I make a Dialog version of my WIP is start stripping non-system verbs out of stdlib.dg. None of them are relevant to what I’m doing! Could or should Dialog either: (a) ship with an extra, minimal version of stdlib.dg without any in-world verbs or: (b) define these verbs in a separate file that authors can choose to exclude?
(a) presumably would add more complexity to maintaining and updating the standard library. (b) would make the command to compile a default project lengthier and perhaps more intimidating to newbies…
Speaking as someone who’s done that stripping (for Familiar Problems, which uses none of the default verbs)—I think it’s not too difficult to do yourself (the verbs are mostly grouped into a single part of the file), and the process of doing it yourself will often be helpful, since if you have any verbs in your game with similar effects, you can see which parts of the library’s version you might want to keep around. It’ll also let you see which parts of the standard library’s world model you might want to get rid of if you’re not using the standard verbs.
So my recommendation would be that it doesn’t have to be part of the standard distribution, but if you wanted to provide the end results of the stripping, others might find that useful too!
