Text Style in Stories

This is a bit of a crafty/artsy topic. We’ve been moving more towards web enabled content in the IF world for a number of years now. There a re number of web-enabled things you can do with Inform 7 and Quixe.

I’m wondering what the author’s perspective is on style. In my mind, there are two basic approaches, similar to web development. There are inline styles, often considered taboo, and CSS based styles, considered a standard. There are even standards for generated CSS from things like SASS and LESS. There may be an author or two that is fluent in web design, but I think most authors are just throwing paint at a wall and hoping for the best. In the latter case, we may decide to procure the assistance of someone outside the IF world to help with design.

Given the idea that we may design our stories, I’d like to develop something that would provide the average author with baseline techniques, but also enable a professionally designed approach.

Some of the basic inline type things that could be done include:

• Font-Weight: We might want the ability to weight our text (bold/normal or one of the standard numerical weights).
• Font-Family: We might want to implement our own flavor of fonts for various reasons.
• Background-Color and Color: We might want to display text in any color and have the background-color be set as well.

Some CSS type things we could do are relatively simple. As long as text is wrapped in tags, the result can be manipulated in CSS on the web side.

But it may be all of this is more than what is necessary. If a section of text will always be Arial, 12pt, Normal, then we really don’t need to relay any information to the browser. That would be handled by our target template. On the other hand, we may want to identify portions of text with markup such as weight and color and text-decoration. We may want some portions of text to be a hyperlink. We may want to inject images, videos, or other components with a portion of text.

I don’t expect a lot of comment on this subject, but I wanted to get your thoughts. Obviously my work is in reference to FyreVM-Web, which would allow a savvy author to do “anything”. But I’d like to create one or more style-based extensions that provide some baseline styling capabilities.

I have on extension that I wrote at least a year ago that provides in-text Font manipulation and CSS styles. Adding Hyperlinks would be trivial and it would all look like this:

To style the thingamabob: say "[arial-normal]The [bold]thingamabob[/bold] is a [underline]brightly[/underline] lit construct made of [link command="examine steel plating"]steel plating[/link][/arial-normal].";

or just emit HTML…(though links would still need processing, since we’re executing commands, and I wouldn’t expect an author to write that code in I7).

To style the thingamabob: say "The <b>thingamabob</b> is a <u>brightly</u> lit construct made of [link command="examine steel plating"]steel plating[/link].";

At a minimum I think it’d be good to allow all the same text formatting that is allowed in Glulx–bold, italic, fixed-width font, background color, text color, margins, different font sizes. There are probably others–I can’t remember if left or right justification, etc. is allowed. But of course, without limiting the custom text styles to two. Hyperlinks would be great too.

I think one of the reasons some Glulx features (for instance, margins and font size) are not as much used as they might otherwise be is because not all interpreters support them (Gargoyle doesn’t support margins or relative font size), and it’s hard to make things look good across different interpreters when the results vary as much as they do.

One thing that can’t currently be set by the author in a non-browser-interpreter, that would be really nice to be able to set, is a scrollbar. If there’s a sidebar that lists some text, for instance, that can’t all be displayed on the screen at once, there is sometimes a problem where every time that sidebar updates, you get a “More” message and the player has to hit a key to make it go away. It would be great to be able to just put a scrollbar there so it doesn’t keep bugging the player.

I…think I’m not quite sure I understand your question about inline CSS vs. a CSS stylesheet. Custom text styles in Quixe require a CSS stylesheet, and this has worked fine for my purposes. A default one is provided if you don’t want to mess with it yourself. While CSS can be annoying for complicated things, it really doesn’t seem that difficult for basic things like text color. (I say this as someone who has learned about stylesheets primarily by search engine.)

But back to the question: I’m not sure I understand what difference inline vs. stylesheet will actually make to the author. I’m assuming that either way, you are going to provide natural-language-ish tags for the author to use (or just let the author use the built-in tags for Glulx). So it’s not like the author is going to be putting “span” tags containing CSS in the story file…is it? If so, I’d definitely rather not have to put CSS in the source code. But regardless of whether the CSS is inline or in a separate CSS file, you still generally have to learn enough CSS to specify the custom styles, right?

Unless you generate a stylesheet by letting the author choose colors, font sizes, etc. from drop-down menus and such, without having to learn the format of a stylesheet. Or maybe some of the tools you mentioned already do something like that.

This is definitely not for non-web interpreters and I’m of the mind that those days are in our past. You can package a browser based app “like” a program now, so I’m focused strictly on browser tech.

So no html for the author. I’d agree with that. There certainly would be default style sheets for any given “template”. And I agree that the basic Glulx UI things should be implemented although I’d probably skip the fixed-width font business. To me, that’s a design issue better handled by the template.

I think the point I’m trying to make with FyreVM-Web is that if you use it, there may be templates, but as an author you’d still want to do some design work. It’s meant for stories that don’t “fit” in the standard template. It’s meant for authors that want to change the way the UI looks and feels.

But even in that context, the basic styles are important. I just might add more though.

Thanks for the feedback.

Aaron Reed’s Keyword Interface extension would make an interesting test case for this. It uses most of the available options for text styles I think.

Also it occurred to me that horizontal rules would be nice. I guess that doesn’t really count as text styling though.

(Unrelated: does your system support sound?)

Define “support”. I can think of any number of ways to implement communication from the story to the browser for sounds. Whatever you can do in JavaScript/HTML5, you can do with FyreVM. I don’t currently have an implementation because I’m not sure what all of the requirements would be. From the past I recall:

• play sound file
• play timed sound file
• play multiple sound files
• play multiple timed sound files

The issue of when to play a sound file has two meanings. One, to trigger sound from the result of a command. Two, to trigger sound from the UI alone based on timing. So if the player is just staring at the browser and not typing, the sounds could change based on whatever logic is implemented.

For FyreVM, we just need a decent list of requirements and I can make an extension that will do exactly that.

I meant the same things Glulx has built in: signaling a sound file (I think ogg is what Glulx/Inform allows, there might be another file type also?) to begin from any line in the code, signaling a sound to begin after a set amount of time has passed, and sound notifications (so you can automatically cue the next sound–or another event–when a sound has finished playing).

But it’d also be great to have some things that are not, I think, built in for Glulx, like fading/crossfading.

Sound is not supported (or not supported completely) by all the major interpreters, so it’d be nice to have an alternative way to present a game with sound. Wade Clarke has run into this as well, and might have some suggestions.

Well whatever sound files are supported in major browsers would be my recommendation. After that, all the fidelity controls you want would just be a matter of implementing logical controls for files. I’m not a sound guy, so I’m not sure what those would look like. I imagine this would be implemented in an extension that sent sound and control details to the browser in JSON format.

There’s a rundown of glulx’s sound support in section 8 of the glk spec, and the z-machine’s sound capabilities are described in sections 9 and 15 of the z-machine spec. These would be a good starting point, as they’re the baseline that Inform authors have come to expect.

Yeah that’s a programming guide. I think I’d like to move the requirements away from technical implementation to author/browser requirements.

For instance, I probably don’t need to know about an iterate function or channels. I probably just need to know that I have two sounds to play at the same time.

Yeah, the point wasn’t to adhere to those implementation details. It was that, by reading these docs, you can infer a minimal feature set to implement. Multiple sounds can be played simultaneously, playback can be paused and resumed, and so on.

That’s what I thought you meant, but wanted to be sure.