Glk stylesheets: the Plan

Two days before the end of the month, even.

I have posted three documents:

There is a whole lot of work involved in this plan, so you’re not going to start using it next week or anything. But I am reasonably convinced that this is the roadmap. It’s consistent with the last discussion I had with Graham on the subject.

Comments:

  • If glk_end_style_name()/glk_end_style() generate run time errors then will they get used? It would be far too risky for the library to call them, because the user may have forgotten to end a style they added to the stack. I’d like to suggest the following API functions instead:[list][*]glk_inspect_style(): returns the style at the top of the stack
  • glk_end_style_name()/glk_end_style(): these functions would instead pop styles from the stack until the given style is popped. The whole stack could be emptied. No errors would be generated
    [/:m]
    [
    ]Part of me wants to say that the generated HTML shouldn’t have para_ and span_ class names as style sheets could have div.style and span.style instead. (As well as a generic .style.) But then that would lock implementations into using particular elements, which I don’t like the idea of (I’d like to use s I think.)[/:m]
    [
    ]Can you explain some of the use cases for HTML windows/frames?[/:m]
    [
    ]Instead of html windows loading resources from the blorb, can they just use inline styles and scripts, and use data: for images?[/:m]
    [
    ]Instead of GlkEntry/GlkEvent, what about just using postMessage()? Support is good: caniuse.com/x-doc-messaging[/*:m][/list:u]

Neat-o.

I think that’s wise, for Glk not to check strict usage and let a higher level do, or not do, it. But if it does take this hands-off approach, is printing a run-time message to the player appropriate for confused usage? Maybe Glk should just tell the calling library instead, and let the library decide whether to bother the player.

What does Glk do in cases of the style stack overflowing or underflowing? I think underflow could be silently ignored, but overflow…?

This confuses me. If I don’t use paragraph styles, but just stick a span style mid-paragraph, the above wording implies than when I end the span, the rest of the paragraph will still have that style – it won’t turn off until the end of the paragraph even though I told it to end at the end of the span. Do I misunderstand something here?

Other parts of I7 use the form “a number based rulebook”, so I’d be somewhat surprised by anything but “header based text style”. A minor point, I know. (And please let us not capitalize non-proper names mid-sentence! “header”, not “Header”! It’s a pet peeve of mine when I read others’ I7 code.)

I feel slashes are un-Inform-like – witness [bracket] and [close bracket] – but, ::shrug::

Yes please!

Also: is Glk married to Javascript, disallowing Javascript’s competitors?

That’s a fair point.

I want errors to be visible to the author during testing. But they don’t have to be fatal errors for that, and the interpreter really can only throw fatal errors. At the same time, I don’t want game code to be in a paranoid loop of constantly interrogating the style state in order to do anything. That’s a waste of time.

I like Ron’s suggestion that the call should return an error value. That way, the game can display a warning when in debug mode only.

I separated them out because, in some cases, double-applying a CSS attribute is bad.

If you have “Header” as the current style, then (following the rules as I’ve written them) you’ll get span_Header spans inside para_Header divs. That’s not a problem with my sample stylesheet. But if these had the same class name (“Header”), then a “.Header {font-size: 1.4em;}” declaration would apply twice, and the font size would be multiplied by 1.96!

The examples I gave are supposed to be definitive for elements as well as classes. So yes, I’m already locking the implementing into using

and .

I’ve got a guy in email who’s been begging me to permit panoramic photo display in a Glulx window. I don’t know how that works (it’s probably a Flash applet) but if he can make it work in a web browser, he should be able to make it work in a Glulx window.

More generally, it’s an out for people who are tired of writing graphics in I7 code. No offense to GLIMMR! But if I want a fancier status line, with custom fonts, gradients, some icons, and maybe a decorative border, it’s very easy to build that using HTML.

People could do that but I’d hate to require it of them. We’ll see how practical my other ideas are.

I hadn’t looked at that; I’ll read up on it. It looks designed for JS-to-JS communication, right? I also have to think about (e.g.) a MacOS app which has embedded a WebKit view and is calling from ObjC-to-JS.

Underflowing is an error, which is currently described as a fatal error, but I’ll change that to an error return value. As for overflow, there is no limit on span nesting. (If you want to run the interpreter out of memory, there are easier ways than style abuse.)

The “current paragraph style” is only applied to a paragraph when the paragraph begins. Further changes only affect what will happen to the next paragraph. I guess that’s not very clear – I’ll add some explanation.

Up to Graham. But you’re right about capitalization. I’ll change those examples.

Ask me again in a couple of years, if there are competitors by then. :confused:

I deliberately made the call name generic – “glk_script_send()” – to avoid specifying this. In theory, Glk doesn’t care what the scripting language is, as long as the game and browser agree. In practice, that means Javascript. I can imagine a future where there’s a real choice, and then somebody would have to specify a language somewhere, but we’re not there today.

No offense taken. I will be very happy to see Glimmr obsolesce when these new features are in place and widely supported! Embedding an HTML frame will allow for all kinds of stuff that you can’t do with Glulx graphics–images mixed with actual text, dynamic rotation, shadows, etc. And the ability to get input from embedded frames opens up all kinds of possibilities.

The plan looks great. Will there be a core of recommended CSS rules that interpreters that don’t use HTML for display should support? (Mostly so that game authors will know what will work widely and what will only work on web or widget interpreters.)

I noticed the call naming, but the spec has JS all over it and even called out jQuery specifically. I don’t know how agnostic Glk can be, but the spec should at least state if it’s agnostic or not, or at least where it is and isn’t, or at least its intention.

I know JS is everywhere now, but IF tech seems to have longer shelf life than many tech, so it’s not unreasonable to presume this spec will live to see a JS competitor.

I was confused too. As I read the document, it looks like:

  • There is a stack of styles.
  • A style is either a single ClassicStyleNum or a pair (ClassicStyleNum, StyleNameStr).
  • The “current paragraph style” is an alternate name for the style at the bottom of the style stack.
  • The “style of the current paragraph” is the default style used within the paragraph. The paragraph’s style is set to the “current paragraph style” the first time text is emitted after a paragraph break and cannot be changed thereafter (because the
    open tag has already been emitted).
  • Text emitted as part of a paragraph uses the style at the top of stack.
  • The style stack MUST NOT be cleared by glk_paragraph_break().
  • The distinction between “the current paragraph style” and “the style of the current paragraph” is a subtle one. Replacing “the current paragraph style” with “the bottommost style” or “the style at bottom of stack” might reduce the confusion.