Two API styles of doing special things involving text in UIs

November 19, 2024

A lot of programs (or applications) that have a 'user interface' mostly don't have a strongly graphical one; instead, they mostly have text, although with special presentation (fonts, colours, underlines, etc) and perhaps controls and meaning attached to interacting with it (including things like buttons that are rendered as text with a border around it). All of these are not just plain text, so programs have to create and manipulate all of them through some API or collection of APIs. Over time, there have sprung up at least two styles of APIs, which I will call external and inline, after how they approach the problem.

The external style API is the older of the two. In the external API, the program makes distinct API calls to do anything other than plain text (well, it makes API calls for plain text, but you have to do something there). If you want to make some text italic or underlined, you have a special API call (or perhaps you modify the context of a 'display this text' API). If you want to attach special actions to things like clicking on a piece of text or hovering the mouse pointer over it, again, more API calls. This leads to programs that make a lot of API calls in their code and are very explicit about what they're doing in their UI. Sometimes this is bundled together with a layout model in the API, where the underlying UI library will flexibly lay out a set of controls so that they accommodate your variously sized and styled text, your buttons, your dividers, and so on.

In the inline style API, you primarily communicate all of this by passing in text that is in some way marked up, instead of plain text that is rendered literally. One form of such inline markup is HTML (and it is popularly styled by CSS). However, there have been other forms, such as XML markup, and even with HTML, you and the UI library will cooperate to attach special meanings and actions to various DOM nodes. Inline style APIs are less efficient at runtime because they have to parse the text you pass in to determine all of this, instead of your program telling the UI library directly through API calls. At the same time, inline style APIs are quite popular at a number of levels. For example, it's popular in UI toolkits to use textual formats to describe your program's UI layout (sometimes this is then compiled into a direct form of UI API calls, and sometimes you hand the textual version to the UI library for it to interpret).

Despite it being potentially less efficient at runtime, my impression is that plenty of programmers prefer the inline style to the external style for text focused applications, where styled text and text based controls are almost all of the UI. My belief is also that an inline style API is probably what's needed for an attractive text focused programming environment.


Comments on this page:

By Nobody in particular at 2024-11-20 10:01:08:

I know you're talking about APIs, but the concept of "text" itself tends to accumulate inline control effectors over time. The way to effect bold print on a mechanical typewriter was to type a printing character, move the carriage back one space, and type the character again. ASCII's inclusion of BS (0x08) was to support such "overstriking". Overstriking with an underscore effected underlining, with a hyphen strikethrough, with a 0x27, 0x5e, 0x60, or 0x7e, a few accent marks. Orthogonally, horizontal tabs could be used for aligning tabular data on a page.

Less vestigially, one might consider non-breaking whitespace, word joiners, and bidirectionality controls to be inline control effectors, too.

And some GUIs in the 70s, including Smalltalk and the MIT Lisp Machine, treated fonts as an attribute of certain subtypes of string. The precise details differed a little, but roughly speaking, some subsequences of a string of the appropriate subtype simply "were" of a particular font. (These systems were monochrome in the 70s; IDK whether/how they evolved to cope with color.)

Motif's Compound String type likewise was conceptually a string that could have different fonts attached to different subsequences. I think it eventually got the ability to render different subsequences using different colors, too. It was technically possible, via interpretive capabilities in the underlying Xt library, to invent custom notations, (i.e., markup) for Compound Strings (or any other datum in the Xt object model), but I don't think most people noticed.

A "rich" NSText instance has analogous capabilities, but with a subset of the RTF format as a defined I/O syntax: https://www.gnustep.org/resources/OpenStepSpec/ApplicationKit/Classes/NSText.html

My takeaway from these kinds of factoids is that the old-fashioned idea of a difference between "content" and "presentation" is probably inherently vague. Once some presentation capability can be taken for granted, people seem always to stuff that capability into their idea of data. IOW, something like font, color, etc. is only in the complement of "content" to user who hasn't got the capability to display it.

Written on 19 November 2024.
« Ubuntu LTS (server) releases have become fairly similar to each other
Thinking about how to tame the interaction of conditional GET and caching »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Tue Nov 19 23:43:30 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.