It most likely would require JavaScript. Not hard if you know how, but a bit tricky if not.
The simplest way, IMO, would be to do a simple search and replace of a placeholder in the HTML code with data from a KM Variable. This would, of course, require that you store the HTML in a KM Variable, and then use that Variable in the HTML Prompt Action.
It just occurred to me that perhaps the standard browser zoom control (⌘+ and ⌘-) might take care of this need. But it appears that zoom control is NOT supported in the KM HTML Prompt. @peternlewis, is this correct? If so could you please add it.
I'm not a CSS expert, but this method is commonly used on today's web sites. I'm sure there are some CSS tutorials available if you are interested.
Sorry to be such a complainer on this. It is just that poor readability (due to font size, family, and contrast with background) is my chief issue with many of today's web sites.
I'm sure you did not expect, nor want, this type of user feedback for your post of a free macro. So please feel free to just ignore all of this if you wish.
Yeah, I don't really see a clean (readable) way to implement variables in any CSS used in Custom HTML Prompts.
There are plenty of JavaScript snippets in Glossarium to display Keyboard Maestro variables (like the popup menu itself) but they're awkward constructions within the HTML.
Then, too, WebKit has its limitations in this implementation. Can't set focus on a select element, can't call a JavaScript alert, etc. So while sites may use CSS preprocessors like Sass and Less to implement variables, those are preprocessors whose output is static CSS.
Anyway, I appreciate your perspective. I hope the larger text (from 0.8em to 0.9em) works on your monitor, which is higher res than the three I'm using. And I hope the design is not too hard on anyone's eyes, either.
Small update today to copy the description of any term found to the clipboard. You can then paste the description into any working document as long as its window is still displayed. Because once you close the window, the clipboard entry is removed to keep things neat and tidy.
This makes it feasible to use Glossarium as a reference tool. Your term would be a citation while the description would be what you want to put in your text for the citation.
No attempt has been made to format the description but the clipboard copy reflects exactly what's in the data file not the HTML massage used by Glossarium to display the description in its window.
The PDF manual has been updated to reflect that change.
Note the line below the existing body tag: body {[[BODY_CSS]]}
This my placeholder, and is invalid HTML until replaced.
As you probably know, web browsers will just ignore all invalid HTML.
So the HTML will display just fine as is.
But, I will replace the placeholder in my KM Macro before executing the HTML Prompt Action, and save to a temp file just for this one Macro execution:
In my limited testing this works very well, and runs fast.
As you probably know, the first body CSS properties will be used unless overridden by the user-supplied CSS. In my example I am just changing the body background-color.
Of course, it is totally up to you whether or not you want to use this, but I thought I'd share JIC.
In the Perl world that's known as templating. The usual delimiters are %% (which doesn't occur in the wild) but they could be anything (like yours, in fact).
It's a bit like the more familiar mail merge of word processing software, if anyone is following this thread. You've got your document with placeholders for the variable data that get filled in when the process is run.
It is, however, a world of its own (what delimiters, what variables, what template). Quite opaque. In a Perl environment it's invisible (I build the stories on my site using a set of templates but can't tell you what any of the placeholders for the variables are -- which is how it should be).
And in my environment, those variables change with every story. Which makes templates very efficient.
But where the variable is likely to change once, say, I think it's more efficient to search the CSS code in the Custom HTML Prompt and change it there once and for ever. You know, if you don't like the default.
Textcavator lets you pick the highlight color (it's default is Navy) but in that case, the entire report is generated by Perl so it has no trouble talking about the highlight color as a variable.
And, I have to say, I doubt anybody tinkers with the highlight color. I myself don't (except for testing).
Glossarium is a bit like that. Change the CSS if you want; it's open code. But offering various color schemes (there is a scheme not just a color) and debugging them isn't something on my radar.
Thanks for digging into this, though. With variables that are likely to change, it would be the solution.