Re: rethinking @def*

[Gavin Smith]

On Tue, Aug 09, 2022 at 10:13:19PM +0100, Gavin Smith wrote:
> I think there is a big improvement now for the libc manual, HTML
> output. The attached clip1.png is from the current web documentation.
> clip2.png is generated with the development version of texi2any. Note
> that although there was @var used in the Texinfo source and <var>
> present on the webpage, this was not apparent in the rendering before.
> 
> The only thing I am not really happy about is the fact that in the
> definition body, <var> does not have the same font style as on the
> definition line. Perhaps we should specify
> 
> var.var { font-family: monospace };
> 
> (or "initial", "serif", ...) in the CSS for consistency throughout the page.

After trying various possibilities I think it is best left as it is.
Making <var> monospace throughout the page would be too big a change, and
would create an inconsistency with untyped @def*, the fonts of which we
aren't considering changing.  Since in both typed and untyped @def the document
could refer to arguments with @var in the descriptive text, it means we
leave @var as using a variable width (or system default) font.  If we
were to get consistency, we'd use a variable-width font for @var on @def*
lines, using a CSS rule like

dt var.var { font.family: initial };

However, the visual results of this are questionable: see attached image.
I'm afraid someone would look at that and feel it looked wonky, even if
it looked right for some systems/users/documents.  The biggest problem
is the size of the brackets and how closing brackets disappear into the
letter before them, as after "vector-ptr" in the image.

(Using a compound CSS selector would also be incompatible with
'texi2any -c INLINE_CSS=1'.)

So I say to leave the current output as it is.  People are free to
customize the appearance of <var> using CSS.

clip3.png
Description: PNG image