Should we standardize a pseudo-CSS property for "reverse video"?

Consider me convinced! I didn’t realize it would interact like that with other values of text-decoration.

I don’t particularly care about the prefix; I somewhat prefer -iftf- over the rest (we can throw -glk- in there as well if we want), because I think it reads better, but I’ll go with whatever works for everyone.

The shortest thing is usually the easiest to remember, so my preference is for -x-reverse-video

Plus the x- prefix has prior usage for custom MIME types, and also custom fields in email headers.

1 Like

“Reverse video” is traditional (ANSI etc), but a little weird today as it sounds like it’s about multimedia. How about -iftf-reverse-mode: reverse | none?

What would an initial value do?

Normal in the main window, reversed in the status bar (Dialog’s default for each). Dialog lets you put non-reversed text in the status bar if you explicitly ask for it, and this would reset that.

In practice, I don’t think anyone would ever use it. They’d just set the property to whichever mode they want. Dialog mostly supports initial for the sake of color and background-color, since the Z-machine has a specific way to request “set these back to how they started”.

For both the Z-Machine and Glulx the story must switch on reverse mode in grid windows.

This is of course important to be able to do, though an unset operation is better IMO. If you set something to the Z-Machine’s default colour, I’d expect it to stop emitting CSS properties.

If we included initial I’d probably just ignore it in AsyncGlk, which should be fine. :slight_smile:

If the browser is sharing in using the class style of the text in page and the ‘text-decoration’ is more than just a payload then not using a style property makes sense. I’m not versed enough in the separation of concerns of who does what to the text. Is it normal to display a IF HTML document outside of a game engine? I think though that seeing that the style is supposed to be thrown out bodes well for the concern of it somehow filtering down into the document and having some other side effect. Also, if these documents are consumed by other renderers then it is a coin toss whether you want the engine to ignore something or try to process it. I’m glad to be a fly on the wall of the problem and more glad that it isn’t going to my inbox to make happen.

May I infer from your suggesting -iftf-reverse-mode that you’d be OK with -iftf- as the prefix?

If so, I’d say we’re very close now!

As for your point, I suggested -iftf-reverse-video instead of just -iftf-reverse to include a noun that explains what’s being reversed; I don’t think “mode” does that job. -iftf-reverse-mode doesn’t convey any more information than -iftf-reverse.

Maybe one of these?

Yeah, the trick is that Dialog styling is all hierarchical, not linear. The basic styling operation is “execute this next block inside a div/span with these particular CSS properties”, so the initial value for color and background-color lets the Z-machine “reset to default colors” operation fit into that model.

Even then it’s an edge case, though. In Glk, where the game emits a linear sequence of “set these properties” calls, I don’t think it would be needed at all.

To me, “reverse colors” sounds like “invert the RGB of each color” and “reverse background” sounds like it only affects the background, so I would prefer either “reverse” or “reverse video”. But again that’s not a blocking concern.

1 Like

Okay let’s just settle on -iftf-reverse-video!

The CSS Glk extension will let you set both paragraph and span styles, so maybe I need to give this more thought. There would in effect be 3 styles to cascade: the Glk style, the inline paragraph style, the inline span style.

3 Likes

Sounds like it’s settled, then! In the next release of Dialog, -iftf-reverse-video: reverse | none | initial | inherit will be the standard way to set reverse-video style on a div or span, and text-decoration: reverse will do nothing but raise a warning telling people the new syntax.

And done!

(style class @reverse-old)
	text-decoration: reverse;

(style class @reverse-new)
	-iftf-reverse-video: reverse;

(style class @unreverse)
	-iftf-reverse-video: none;

(program entry point)
	(status bar @unreverse) { This is an unreversed status bar. }
	(div @reverse-old) { This line will not be reversed. }
	(div @reverse-new) { This line will be reversed. }
	> (get input $)

Warning: text-decoration: reverse is no longer supported; use -iftf-reverse-video: reverse instead (in style class @reverse-old)

:rofl: Oh the irony.

Yeah, I liked the elegance of that syntax too; but if it messes up other values of text-decoration on the web, then it has to go.

For sure, the best of the solutions needs to bubble up. It’s the tech debt being paid. If there is ever a HTML5 based version you’ll get to start over and all.