No interpreter ever has to implement all of Glk. Big parts of it are put behind gestalt selectors.
Sure, but there are parts that aren't optional (windows, streams), yet are redundant for an HTML-based interpreter.
As to inaccessible games on Floyd, I think the responsibility is the author's. I do expect that the extensions for this HTML stuff will be written with portability in mind, or else I'll help fix them until they are.
Much more useful would be a glk function that takes a CSS selector and a JSON object of CSS properties to apply to the matched elements. That will be an essential function that no doubt anyone writing custom JS will make, but a glk function might be better.
We can't assume that it's possible to change the style of text that has already been printed. It's possible in a browser, and in a full-screen console terp that has a sufficiently complicated screen buffer, but not over Guncho/IRC/etc.
At the moment my feeling is that Glk doesn't need to move the style limit for the purposes of Z-Machine compatibility, because that is a problem that can be solved at the library level.
Solved at the Glk library level by hacking in library-specific extensions? I'm not sure why that's preferable. Surely at least it'd make sense to standardize these extensions so they don't have to be reinvented by every Glk library author who wants to support the Z-machine.
Glk supports true color in every one of its eleven styles. The issue is quantity, not quality.
Well, it's more than that. I'd say there are two blocking issues and one major issue that can be worked around:
1. There aren't enough styles.
If at some point in your game you want to show various combinations of bold, italic, underline, and a handful of colors, you won't even be able to predefine the styles because there aren't enough slots.
2. Styles can't be changed without recreating the window.
This means you have to predefine all
styles you want to use in the game. If issue #1 were eliminated, this wouldn't be a problem for games that only need semantic styling: even predefining a few hundred styles isn't unreasonable. But it is a problem for games that use color for color's sake, e.g. for drawing ASCII art or for printing the temperature in a color mixed between blue and red according to how warm it is. Predefining 16.7 million styles to gain access to the full color spectrum is not reasonable.
3. Styles have to be referenced by name/number.
If issues #1 and #2 were eliminated, this could be worked around by making the game do a lot of silly, inefficient bookkeeping to keep track of which style combinations had already been allocated... or by assigning a new style for every piece of text and bogging down the interpreter with a lot of duplicated styles. But HTML has <span style="color:#abcdef">, so why not let the game take advantage of it?
I think the latter case holds for most authors, and if that's true then I see HTML + CSS as the only reasonable way forward.
The problem is that the CSS-based fork of Glk as described here is still missing a very basic style feature from HTML.