One styles the room name, turn number, and score in the status line via .GridWindow .GridLine span.Style_normal instead of something like .status-line-room-name, for example.
That is, styling elements requires a fair amount of DOM archeology, which I imagine only a vanishingly small fraction of the IF authors that end up looking at this particular problem actually care about. That is, they don’t want to have to understand the structure of the DOM. They just want to make the room titles purple (or whatever).
Presumably the existing system is the way it is because a) the system isn’t a system, but an accretion of a whole bunch of them that don’t all do things the same way, and b) the focus really isn’t on providing an accessable interface for skinning the UI, presumably because the default assumption is that the underlying interpreters will a lot of the heavy lifting.
Ah, well the output from the virtual machines is unstructured. Parchment doesn’t and can’t know if you’re printing the name of the room or the title of a menu or directions to the sea. Glk has 11 styles that can be used, and those have more inherent semantic meaning, so you could use user1 style to refer to room names, and then tell it to make user1 purple. But you’d have to manually switch to the style every time you print a room name. And for TADS there’s no way currently to set any of those styles. But in the future we’ll be able to make it understand more of TADS’ native formatting code.
Yeah, it’s possible that I’m just approaching this all the wrong way and the real answer is that I shouldn’t be trying to do all this with a TADS3 game at this point at all. Like maybe it makes sense for the style sheet to basically have an “Employees Only” sign over it because the “real” way to handle this sort of thing is to rely on the terp/VM to do all the markup and styling.
But the point I was trying to make was a purely practical one: if I, as a person writing a game, have to figure out that I need to style .GridWindow .GridLine span.Style_normal in order to change the color of stuff in the status line, then—if this is a reasonable thing for a person writing a game to want to do—then the system probably should provide a less cumbersome way of doing it than memorizing that you have to style .GridWindow .GridLine span.Style_normal in order to do it. If that makes sense.
But it’s also possible that I’m just overthinking it.
Well you don’t need both .GridWindow and .GridLine… just .GridWindow or .BufferWindow followed by .Style_normal/.Style_header/etc will work. Grid lines only appear in grid windows. Every piece of text appears in a window and has a style, so you only need those two things in the CSS selector.
But yeah, in general, editing the CSS manually is nonideal.
Yeah, if you say that .GridWindow .GridLine is redundant I believe you, but there’s no way to determine that from just looking at the DOM of a rendered document. Which is one of the reasons why it seems preferable to have classes that reflect the semantic role instead of their geographic position.
And as an aside, you can’t just style .GridLine .Style_normal because .GridLine span.Style_normal and .GridLine div.Style_normal are applied to different UI elements. Or I guess you can’t just style .GridLine .Style_normal if you want the room name, score, and turn number to be styled differently than items in the exit list, for example.
…At one point I had a plan to divide style_Foo into linestyle_Foo and parastyle_Foo. It would at least have avoided the problem of piling two levels of the same CSS class on top of each other. (Which gives bad results if you do, say, font-size: 0.8em.)
I had no idea that Parchment was related to GlkOte. I don’t even know what it is. Now that I know, I can use the reference you gave me. I recognise most of the class names.
This is also helpful. Between the two references, I should be able to work out why the css changes don’t behave the way I would expect them to behave under normal circumstances.