Then how come markdown on Github, WhatsApp’s method newly released in March 2016, reddit, and even this phpBB we are using right now doesn’t have you use CSS? There is inline COLOR coding right here, it isn’t obsolete in the Browser HTML5/CSS3 world. Same goes for strikethrough - has Glk entirely forgotten it’s ANSI / VT100 roots? character-oriented inline protocol over RS-232 serial!
Cascading is not trivial to implement and Android does not support it naively, nor does ANSI terminal like ncurses! “CSS parsers are available in most languages”, you think a big new can of worms isn’t going to open with C library choosing to parse CSS one way vs. Java library another? I’ve pointed out the historic Glk avoidance of zcolors that has frustrated interpreter app developers (including the Inform 7 6M62 IDE on Gnome)… what good is a standard if it doesn’t admit that it overlooked what the whole thing was modeled after - an ANSI / VT100 terminal with inline styles! You think CSS has a good history of how Mozilla Firefox interprets CSS vs. Microsoft Internet Explorer? Just because you can parse it, doesn’t mean that you have produced solid working examples of “how it should be” like zcolors had all along! And strikethrough is a perfectly reasonable request - Glk is supposed to support more than just Inform 6 and Inform 7 z-code and glulx!
Bigger picture: What’s happening here is that Parchment/Quixie/ifvms.js ZVM via GlkOte has made the choice to not implement zcolors + stylehints that were documented and now with desktops on Apple rapidly migrating to Lectrote - old interpreters are going to continue to decay and be abandoned. Since CSS is native to Quixe and has none of the problems of CSS in C, Java, Python, etc - it seems like a grand choice.
But I’m working with RemGlk - which isn’t Quixe where CSS is king. And you know what, Glk is supposed to support Hugo, and TADS, and all these other systems that also don’t use CSS. And introducting CSS isn’t going to modernize what is basically an inline ANSI / VT100 design that is still spiritually alive today in the examples I cited: phpBB, WhatsApp androidauthority.com/whatsap … ng-680598/ , Github Markdown, Reddit comments, Wiki formatting, etc. Inline styles (non cascading) didn’t die off and go away like was expected.
Hmm. What’s the status of CSS-based styling these days? It’s a great idea, but I don’t want to make the perfect the enemy of the good.
The plan for CSS in Glk was first described about 7 years ago. Meanwhile, we’re still living in a world where even though Glk is the obvious choice for anyone developing an interpreter, it has no official support for a styling feature that’s part of most IF platform specs and most system text APIs.
There was some good discussion in that thread. One of the proposed features (line terminators) was added to Glk 0.7.1. Another (erasing previously printed text for use in line input) can be done without support from Glk, at the cost of some complexity in the interpreter. For the remaining feature, I proposed glk_set_stylehint_temp, which is basically garglk_set_zcolors generalized to apply to all style hints, so it could be used to implement @set_text_style as well.
garglk_set_zcolors is currently supported by Gargoyle and Chimara, and used by Nitfol, Bocfel, Frotz, and (sort of) ZLR. When I first hacked it in for ZLR, it took Z-machine color numbers and only supported the Z-machine’s palette. As implemented today in Gargoyle and Chimara, it has a companion function garglk_set_zcolors_stream, and it takes arbitrary 24-bit colors; now might be a good time to take that “z” out of the name.
I guess the next steps are
write a spec
assign gestalt and dispatch selectors
patch Gargoyle and Chimara to support the selectors
patch Basic Screen Effects to support color changes on Glulx (?)
I would much rather see this as a proposal, rather than an ugly hack like garglk_set_zcolors() which limits you for no good reason to the Z-Machine colour set.
If you’re going to propose adding something to Glk, the object of the exercise is surely to add something that is the most possible use to everyone. What vapourware suggested would let you set the colours to anything, not just the Z-Machine set. Why restrict the colour choices to the Z-Machine set? It’s useful for writing a Z-code interpreter, yes (though not if you wanted to include the Z-Machine 1.1 specification additions) but not if you’re writing a Glulx game and want arbitrary colours.
Maybe with a selector for original ANSI 8 set (with intensity, doubled), 256, and 24-bit (yes, there are 24-bit terminals out there gist.github.com/XVilka/8346728 ) - all that is grounded in the character-oriented world that Glk has grown out of.
garglk_set_zcolors doesn’t actually limit you to the Z-machine color set - it takes true color values, and the implementation of @set_colour has to map the Z-machine color numbers to RGB (example).
The original implementation of garglk_set_zcolors in my fork for Demona did have that limitation (and in fact still does), hence the name, but it seems the behavior was changed when the patch was merged upstream.
This has been a really interesting discussion and I’m hesitant to derail. I’ll point out something I said earlier up thread:
From this thread and others, I now realize that where “Inform 7 development” is going and where “Glulx development is going” are broadly separate ideas, even if interleaved by a certain necessity.
All this said, I’m still curious about these questions which I consider to be fundamental. There seems to be a certain level of intransparency in details (i.e., one example “garglk_set_colors doesn’t limit to the z-machine color set” as was possibly thought). There is certainly fragmentation of effort. It’s of course a subjective value judgment as to how effective that is, regardless of what can be done about it or whether anything should.
I’ve seen a couple of times this desire to stick with the ability to harness the past: i.e., z-code and the z-machine. But how important is that really? Loaded question! But I’m wondering how much effort is put into propping up an older standard and what it would mean if that effort was channeled into propping up the new standard? It’s not like the old stuff goes away. Existing interpreters and whatnot would still support z-machine. But the “next generation” would be focused on just that: the next generation. Which, it seems, has actually been here for quite some time, as evidenced by the work people have done.
The short story to that is it’s unclear to me how much of an albatross the z-machine and z-code is to current and future interactive fiction development. I get why its role is as it is right now. I grew up playing the Infocom games like I’m sure many here did. But I certainly don’t want to cling to that past necessarily, particularly if it’s more fruitful to diverge and focus on a new way that things could be.
I think the original z-code of identified 8 colors (really ANSI set with intensity is 16) should be preserved through interpreter->glk->app via indexing. Even if the Glk library glk_ call only ends up calling a second glk_call with the translated 24-bit color - the interpreters should have the option of a “known indexed set”. The reason for this is vision impairment. And I think all interpreters (even those outside Inform 7 sourcing) can deal with these original ANSI colors as a recognizable set, identified by an index, that could be re-mapped. That’s was part of the reason I was experimenting with and originally saying make them style_ equal to established ones. making style_NUMSTYLES + 16.
The game author, writing script, could have the option to query the client and see if some request is placed to limit colors to this indexed set… and chose to use them instead of 16 million 24-bit colors. (You could go 32 bit and add alpha transparency while you are visiting the topic.) When being treated like bold, italics, underline, etc - 16 colors is a pretty rich selection for reading and highlighting content. Reference index codes; en.wikipedia.org/wiki/ANSI_escape_code#Colors
I’m not saying that 24bit or even the latest HDMI standards shouldn’t also be supported. A second function could do that, etc. What I was suggesting is a focus on these legacy ANSI colors and the concept that a client could remap them for visual impairment reasons. For example, a sophisticated interpreter app client could choose to map each of these 16 ANSI colors to a different font family for someone who is colorblind. Or even an e-ink reader that can do fonts but is otherwise black&white. With z-code/z-machine being the legacy basis for testing and demonstrating such features. Please excuse my verbosity on the topic. Thank you and Happy New Year.