2 ms·

It would be much better if application developers (and web developers, too) -only- had access to semantic color labels like TEXT, BACKGROUND, ERROR, WARNING, IN

It would be much better if application developers (and web developers, too) -only- had access to semantic color labels like TEXT, BACKGROUND, ERROR, WARNING, INFO, HIGHLIGHT, and so on, rather than red, yellow, blue, green, black. I don’t want my applications to decide “this element must be red text on green background.” I want my applications to annotate the UI with things like “warning message” and “title.”

johncoltrane 9mo ago
I would really love to have that, too, on every "platform" I have to work on.
kps 9mo ago
That could be done with a few influential terminal emulators adopting a consensus extension to ISO8613-6, like this: ESC[38:99:‹purpose›m for foreground, ESC[48:99:‹purpose›m for background. e.g. Foreground Background Purpose ----------- ----------- ------- ESC[38:99:0m ESC[48:99:0m normal ( same as ESC[39m and ESC[49m ) ESC[38:99:1m ESC[48:99:1m emphasise ESC[38:99:2m ESC[48:99:2m de-emphasise ESC[38:99:3m ESC[48:99:3m error ESC[38:99:4m ESC[48:99:4m warning ESC[38:99:5m ESC[48:99:5m caution ESC[38:99:6m ESC[48:99:6m notice Then people (themes) could easily choose foreground colour or background highlighting for particular roles. Some terminal emulators might also choose to configure other stylistic choices like bold, italic, etc. (I believe ISO8613-6 defines sub-modes 0 through 5 (te;db), with 2 (rgb) and 5 (256-color indexed) being most widely implemented. But some terminals historically mess up : and ; in CSI sequences, and I know at least one would interpret ESC[38:6:1m as ESC[6;1m (blinking bold!), so here I pick 99 (ECMA-48 defines modes up to 65).)
- planckscnst 9mo ago
  "selected" and "highlighted" would also be useful
- hnlmorg 9mo ago
  This is a fantastic idea! I’m working on a terminal emulator. It’s not big like Ghostty but this is something I might adopt
  - kps 9mo ago
    After thinking about it a bit more, I think the specific details of that (i.e. inventing an extended colour mode) are not ideal. One alternative: Assign semantics to colour indexes above 256. Both of those have the disadvantage that they separate foreground and background colour, but a user really wants a combined semantic presentation. For instance, a user might want a warning message to be black text on a yellow background, and not have to rely on the program remembering to set both foreground and background to ‘warning’ colour. So another possibility is just to invent new SGR numbers, e.g. Control Purpose ------------ ------- CSI 2 0 0 m normal (undoes any CSI 1 x x m) CSI 2 0 1 m emphasise CSI 2 0 2 m de-emphasise CSI 2 0 3 m error CSI 2 0 4 m warning CSI 2 0 5 m caution CSI 2 0 6 m notice ⋮ Then the user can configure those as they please with any combination of foreground, background, weight, slant, etc. I'm now thinking about writing up pros and cons of alternatives.
- zzo38computer 9mo ago
  I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.
  - kps 9mo ago
    Yes, since this morning, I've thought a little more and agree. (I just finished replying to another reply.) Anyone interested, ping me (address in profile) and encourage me to set up a repo to discuss and formulate a concrete proposal.
    - kps 9mo ago
      OK, I've started making notes on this at https://codeberg.org/datatravelandexperiments/semantic-terminal-presentation https://codeberg.org/datatravelandexperiments/semantic-termi... . Feel free to jump in, or volunteer to adopt the whole thing.

johncoltrane 9mo ago

I would really love to have that, too, on every "platform" I have to work on.

kps 9mo ago

That could be done with a few influential terminal emulators adopting a consensus extension to ISO8613-6, like this: ESC[38:99:‹purpose›m for foreground, ESC[48:99:‹purpose›m for background. e.g. Foreground Background Purpose ----------- ----------- ------- ESC[38:99:0m ESC[48:99:0m normal ( same as ESC[39m and ESC[49m ) ESC[38:99:1m ESC[48:99:1m emphasise ESC[38:99:2m ESC[48:99:2m de-emphasise ESC[38:99:3m ESC[48:99:3m error ESC[38:99:4m ESC[48:99:4m warning ESC[38:99:5m ESC[48:99:5m caution ESC[38:99:6m ESC[48:99:6m notice Then people (themes) could easily choose foreground colour or background highlighting for particular roles. Some terminal emulators might also choose to configure other stylistic choices like bold, italic, etc. (I believe ISO8613-6 defines sub-modes 0 through 5 (te;db), with 2 (rgb) and 5 (256-color indexed) being most widely implemented. But some terminals historically mess up : and ; in CSI sequences, and I know at least one would interpret ESC[38:6:1m as ESC[6;1m (blinking bold!), so here I pick 99 (ECMA-48 defines modes up to 65).)

planckscnst 9mo ago
"selected" and "highlighted" would also be useful
hnlmorg 9mo ago
This is a fantastic idea! I’m working on a terminal emulator. It’s not big like Ghostty but this is something I might adopt
- kps 9mo ago
  After thinking about it a bit more, I think the specific details of that (i.e. inventing an extended colour mode) are not ideal. One alternative: Assign semantics to colour indexes above 256. Both of those have the disadvantage that they separate foreground and background colour, but a user really wants a combined semantic presentation. For instance, a user might want a warning message to be black text on a yellow background, and not have to rely on the program remembering to set both foreground and background to ‘warning’ colour. So another possibility is just to invent new SGR numbers, e.g. Control Purpose ------------ ------- CSI 2 0 0 m normal (undoes any CSI 1 x x m) CSI 2 0 1 m emphasise CSI 2 0 2 m de-emphasise CSI 2 0 3 m error CSI 2 0 4 m warning CSI 2 0 5 m caution CSI 2 0 6 m notice ⋮ Then the user can configure those as they please with any combination of foreground, background, weight, slant, etc. I'm now thinking about writing up pros and cons of alternatives.
zzo38computer 9mo ago
I like this idea, although I think that they should be only one code, which might program both the foreground and background (and font styles if applicable), rather than separate codes for foreground and for background.
- kps 9mo ago
  Yes, since this morning, I've thought a little more and agree. (I just finished replying to another reply.) Anyone interested, ping me (address in profile) and encourage me to set up a repo to discuss and formulate a concrete proposal.
  - kps 9mo ago
    OK, I've started making notes on this at https://codeberg.org/datatravelandexperiments/semantic-terminal-presentation https://codeberg.org/datatravelandexperiments/semantic-termi... . Feel free to jump in, or volunteer to adopt the whole thing.