This discussion has been running for several months on the RAIF newsgroup (or sputtering, since I tend to reply in occasional short bursts). But I know the newsgroup contains only a small slice of the world’s Inform users. So I want to offer this here.
A perennial complaint about Glulx is that the text style system is too restrictive. You have a handful of predefined styles plus two “user” styles; you can adjust their appearance but the results aren’t really reliable across interpreters. It’s not very good. I’ve been putting off thinking about this for a decade (I said “perennial complaint” and I meant it!) but it’s time to pick it up.
I have a sketch of a New Plan for Glulx styles. Only a sketch so far, because I need to know whether people will buy into the principles before I flesh out all the details. (My first attempt at details got thoroughly derailed by subsequent discussion.)
The principles:
This is a plan for reforming Glulx’s text-style system, not the entire display layer. You will still open Glk windows and display text, same as you used to.
(An example of a total-reform proposal is “Give the game access to Javascript and full control of an HTML window.” That’s come up on the newsgroup, and it’s a possible plan, but it’s not where I’m going. Somebody else can work on that.)
While I’m not throwing the entire problem into HTML, I do like CSS as a style specification language. It’s familiar and it does everything we need.
CSS also does a lot of things we don’t need. I don’t expect a Glulx interpreter to implement the CSS box model, relative/absolute/fixed positioning, or any of that stuff. (As I said, layout will continue to be done with Glk windows.)
Therefore, this plan uses a subset of CSS, not the entire thing. Roughly: text font/style/color attributes, indentation, alignment, line spacing, padding. The appearance of Glk windows can be controlled with background and border attributes.
I expect there to be two kinds of Glulx interpreters going forward: native interpreters (like Glulxe, Git, Zoom), and Javascript interpreters (like Parchment) which run in a web browser. The latter will have access to an actual HTML/CSS display engine; the former may or may not. This plan will have to use a simple enough subset of CSS that either kind of terp can implement it.
Interpreters could accept CSS declarations outside the subset, but this would be optional and not guaranteed. (This could permit fancier options like :first-letter, background-image, drop-shadow…)
For simplicity, all style information will be defined in a stylesheet file rather than in your Inform code. (This is the real point of contention, but I am defending it for the moment.) There will not be an Inform declaration for “green text is color #05FF20”. Rather, you will define the style’s appearance in a CSS file in your Materials folder. This stylesheet will get wrapped up in your Blorb file when you build, same as image or sound files.
Your Inform code can then say “[style mygreen]some text[style normal]”, and the output will pick up whatever appearance the stylesheet defines for “mygreen”. (The exact syntax depends on what Graham decides, of course.) Inform-6 users would have a similar form, although they would probably have to do some manual coordination between the stylesheet and a list of I6 style values.
This may seem way overcomplicated. There are, however, advantages:
We will not have to define a complete I7 representation of the CSS language. That would be a very large headache. CSS will go straight from the stylesheet to the interpreter.
(Future versions of I7 might go in this direction, but I’m not expecting it right away.)
By encouraging the game author to think in terms of defining semantic styles, rather than text appearance, we will offer a great deal of flexibility to the player. To wit:
Glulx interpreters would be able to load in user stylesheets – written in the same CSS as game stylesheets – to customize or override the game appearance. If you want to play all your IF in green Optima on black, with Copperplate for the room headings and a white input line, you can do this. Players would be able to upload and pass around favored stylesheets. An author could drop a popular stylesheet into his own game, for that matter.
If the styles of a given game are defined sensibly, a user could customize them just by looking at the interpreter’s style list and adding some lines to a user stylesheet.
User stylesheets override game stylesheets. (In CSS terms, user stylesheets are “!important”.) An interpreter could also provide more specific preference options, like “ignore color” or “make everything three sizes larger”.
It might be possible to define a “do everything for everybody” stylesheet – say, one that defines hundreds of pre-built colors for a naive author – but I would like to discourage that if possible. It puts a great burden on the interpreter without actually giving the author any new capability. It also makes it much harder for players to sensibly customize the game display.
That said, I have some ideas about CSS style inheritance which should minimally cover that case.
I also have a notion of “interpolated styles” that offers a certain amount of runtime style adjustment. I’m sure I will be explaining it soon but this post has already gotten really long.
Comments so far? My primary goal here is to design a system that interpreter writers can use (not insanely complicated for them) and that authors are willing to use. If everyone’s first reaction to this is to look for ways to bypass the system, then the system is a failure. Which is possible, I know. That’s why I’m asking about it here: so I don’t spend a lot of time implementing something that nobody takes advantage of.
That all sounds pretty good to me. If the creator thinks color is important, he can have a flexible implementation of color; if the user thinks color is important (for example, I play everything except z-files on Gargoyle to take advantage of color customization options) then the user can have it their way as well. I don’t know much about CSS style sheets, but presumably they’re something one can fairly easily learn to use in simple ways.
I was thinking on similar lines, Zarf. Having much more experience with html and CSS than I have with IF, I was delighted to discover that Parchment allowed me to tinker with styles, though only in a limited way.
It seems to me that the easiest way to implement stylesheets in IF would be for I7 to allow class names to be embedded in the output file, and for a new zmachine to create html as output. The game file would have to be distributed along with its associated CSS file.
CSS is very powerful, and it would be a shame to ignore it for the sake of backward compatibility.
I think it’s most sensible not to define style within the Inform code. This isn’t much different than html/css with the exception of inline styles, but for a game I don’t think inline styles are so critical.
Regarding old games or games with different styles, since the point of CSS is to degrade gracefully when not supported, it seems like that should be a design goal of this system as well (I’m guessing that’s the plan anyway).
The current thread on rec.arts.int-fiction can also be considered to be badly derailed… I think one reason for the quick derailment of the thread related to this higher-level proposal (higher-level in comparison to the original, more detailed proposal) is that, despite some kvetching that seemed more or less ancillary to the proposal, there is substantial buy-in. It’s an excellent proposal.
I think that someone else will indeed work up some extension/modification of Glk (YceVM, anyone?) that substitutes JS+HTML for the output, but later–this won’t happen until after Quixe and this new style system are implemented. And regardless of whether someone does this, the new style system and Quixe both will open up new avenues for presentation of IF.
There are a couple of things that I’m wondering about. Apologies if they have been referred to in one of the proposals:
Hyperlinks. How will textual hyperlinks be styled? In the present version of Glk, hyperlinks are styled by the interpreter. I don’t think this is good enough anymore. There’s a new extension for I7, for example, that extends Aaron Reed’s colored keyword system, allowing for hyperlinks. Without author control over hyperlink styles, though, all of the hyperlinked keywords must be the same color; in other words, semantic information is lost. An easy fix: make the author/game library fully responsible for styling hyperlinks, with a change to the spec to indicate that interpreters should do no styling. At the I7 level, this would look something like “[style BlueHyperlink][set link 1]Hypertext[end link 1][style Normal].” A bit awkward for authors to type, but easily made shorter by a new phrase (e.g., “to say set blue link (N - a number):”).
Multiple classes. In HTML/CSS, multiple classes can be assigned to the same element, e.g.
. Will the new style system support this kind of thing, or will styles need to be atomic? This could allow for shorter stylesheets in some cases, particularly if the author is making much use of linear interpolation of styles.
Dynamic stylesheet hints It would be worth considering whether to allow a glk call that would allow for specific attributes of any style to be changed dynamically from within the game. This is already being done, to one degree or another, with linear interpolation of styles to a new (presumably unnamed and dynamically created) style. (Note: I’m not talking about dynamically changing the appearance of text already printed to the screen, just the stylesheet that has been loaded for the game.) This might be a good compromise between the folks that want to be able to set attributes in-line (equivalent to
) and the semantic approach. It would allow for an author to provide her own color-picker (via a graphics window, for instance), as some want to do, without defining a mountain of styles.
Interpreter identification. Given that there are, as you say, likely to be two types of interpreter going forward, it would be nice if a game had a means of identifying the interpreter it was running on, whether by name, or perhaps more robustly, by type. Are there plans for something like this? (I can see it being too difficult too implement, since native interpreters would likely make their own modifications to deal with their particular platform. Worth asking about, though.)
Here are some use cases that would still be impossible or impractical:
Display a character’s name using three channels of color to display stats: red 0-255 indicates HP, blue 0-255 indicates MP, green 0-255 indicates luck.
Display a word in a random color chosen from a set of thousands (or the full spectrum of available colors).
Load an arbitrary small bitmap image and display it as full color ASCII art.
My complaints about the proposed changes boil down to a disagreement over the value of putting aesthetic choices into authors’ hands. This proposal – like the current Glk – makes the system responsible for ensuring that players can customize every aspect of a game’s stylistic appearance, and in order to do that, it denies authors the ability to control the appearance in certain ways (such as computing a color at runtime).
I would much rather give the game full control over styles, even if in some cases that means the author has to be responsible for letting players customize the game’s appearance.
I don’t see how allowing an author to create his own idiosyncratic color picker is a good thing. Most platforms have a standard color-picking dialog box, and bucking that standard cannot be wise. Especially if it’s only used for preference-setting. Let the interpreter call the platform’s standard dialog.
This isn’t to say your feature request that enables color-pickers is a bad request, just that a color-picker is a bad example for promoting the feature’s inclusion in the spec.
Well, I brought the color-picker up as an example only because it’s been expressed as a desideratum a number of times in the various raif threads around the proposal. Perhaps one rationale for people wanting something like this: There will be a lot of potential latitude in what interpreters can offer in terms of customization–anything from an über-bare “Click here to select the text file containing your favored custom style sheet” to a fully-featured GUI CSS editor that would allow the player to use the color picker and other tools to customize each and every style provided by the game. An author’s ability to provide an in-game color picker for the classes they deem important would mean that the average player need not monkey around with interpreter-specific-- and possibly quite fussy–tools, or have to wade into a morass of style names. (On the other hand, is the average player likely to want to change your selected colors either?).
(Personally, I look forward to presenting games on the web, where I expect most players will choose to accept the styles I work so hard to put together… I see the many concessions to what the player wants in the spec as more about the current audience for IF, accustomed to playing in terminals and the like, than to the audience we all hope is out there, and which web terps and better aesthetics may help us reach…)
Another example that would be enabled by that feature request would be vaporware’s second example:
…and I guess even the third, if you were willing to accept a lot of inefficiency (i.e., a glk call for every change in color as you print characters one by one in the ASCII art image). I doubt anyone would accept this, though it might make a very small image doable.
Okay, that’s a reasonably encouraging set of replies. Thanks all.
My notions for old games:
Some interpreters will support both the old system and the new system. In such an interpreter, old games will default to the old system and new games will default to the new system. (Because new games will have a call compiled in to request the new system.) On those interpreters, everything would work fine.
However, I expect (going forward) that some interpreters will only support the new system. For example, Quixe. (That’s the Javascript Glulx interpreter that I’ve been working on slowly. It’s going to be enough work to get one system looking good on it; two is over my horizon.)
In the new system, the old styles would be understood by default. So an old game that simply used those styles (without setting stylehints) would still work sensibly on all interpreters.
The problem case is when you run an old game which sets stylehints (customized style appearance, particularly for the two “user” styles) on Quixe (or some other interpreter which only handles the new system). The stylehints would be ignored and the user styles would appear as plain text. The games would ultimately have to be updated to look right.
Hyperlinks: I honestly haven’t thought them through. I guess the game stylesheet will be able to set properties for hyperlinks just as for styles – it would be a CSS class, distinct from any of the Glulx style classes.
Multiple classes: You can only assign one style to a given bit of text. They don’t stack. I think this is unavoidable; the way I’m dealing with style inheritance (and hyperlinks) means that each style adds several CSS classes. Paragraph style attributes (attributes like paragraph-indent, right-align, etc) also get handled in a somewhat icky way with CSS classes. The interpreter has to be able to handle all this consistently, and allowing multiple styles on a piece of text would become exponentially painful.
Interpreter identification: As I noted above, you will be able to request either the old style system or the new system, although a given interpreter might only support one or the other. You will also be able to query which system you’ve got.
I’m not planning to have a way to identify which interpreter you’re on, because doing anything useful with that information is kind of a nightmare. (Interpreters change more often than games do, in the long term.)
Dynamic hints: As vaporware notes, there are things you can’t do without runtime style changes. Linear interpolation of styles gives you some of those options back; other things remain impossible.
This model is a tradeoff, and I am sufficiently convinced of the value gained to make sacrifices. (The value gained, in this case, is not having to pass CSS – or CSS-equivalent data – into and out of the virtual machine. Also, being able to define the full spread of appearance data at startup time. Mutating an HTML document’s stylesheet at runtime – which is what Quixe would do – is not an efficient activity.)
As I said on RAIF, coming up with a flexible system for displaying IF is hard enough without also designing a flexible system for displaying IF customization widgets. I appreciate that interpreters will have different ways of doing this – but I think they will, on the whole, be better than letting each game ad-hoc a solution. And one of the points of the stylesheet system is to give interpreters a consistent way to customize styles: “download a stylesheet file and install it”. Supporting that is a low burden on interpreter-maintainers, so it should be reasonably portable.
So, I will go forward with this. I will write up the plan in more detail (enough detail that you can notionally write CSS and know what it will do), and also start talking directly to the I7 team and interpreter maintainers.
I’ve proposed my own set of extensions on RAIF, with the more modest goal of making Glk’s style capabilities a superset of the Z-machine’s (to allow Z-code style extensions to be ported, and to allow fully functional Z-machine interpreters to use Glk as their output system). Summary:
Add support for temporary style hints, which take effect immediately and take precedence over the currently selected style.
Add support for terminating characters, which end line input without printing a newline and let the game know which key the user pressed.
Add support for “unwriting” text at the end of a window, to support the Z-machine’s wacky arrangement for partial line input.
Increase the number of user styles to 16.
zarf, I imagine you won’t want any part of this, but I would like to at least coordinate the various constants (new user styles, gestalt selectors, dispatch selectors) to avoid conflicts with the official Glk spec.
This makes Hyperlink one of the basic ten (eleven) styles? I imagine with the web-based terps, having email addys and website links for the author’s homepage in the CREDITS will become increasingly common.
Also, is there a difference between hyperlinks that just do something in-game, and hyperlinks that actually go to the wilds of the internet?
No, hyperlink wouldn’t be one of the Glk styles. It would be controlled by the stylesheets, however, as the Glk styles are.
The current Glk hyperlink spec is only about doing things in-game. There’s no facility for making a “real” browser-level href. That falls into the category of “full HTML output”, which would be a new output mechanism, not an extension of Glk.
(However, I’m looking at the notion of HTML windows in Glk. Not going to be in the next revision, but maybe after that.)
I’ve already replied to some of vaporware’s post on the newsgroup.
The summary is: the suggestion of line-terminators is something that I had already planned to incorporate into the spec, and it will look more or less like that. The other suggestions are not going to become official Glk features (not even “optional features” in the spec), but I will reserve selector numbers for them, to prevent future collisions.