Re: doc: add missing "id" attributes to extension packaging page - Mailing list pgsql-hackers

From Brar Piening
Subject Re: doc: add missing "id" attributes to extension packaging page
Date
Msg-id 1fb57aa2-a763-da2b-eead-b92692f0ddb5@gmx.de
Whole thread Raw
In response to Re: doc: add missing "id" attributes to extension packaging page  ("Karl O. Pinc" <kop@karlpinc.com>)
Responses Re: doc: add missing "id" attributes to extension packaging page  (Brar Piening <brar@gmx.de>)
List pgsql-hackers
On 24.03.2023 at 05:09, Karl O. Pinc wrote:
> Hi Brar,
>
> An observation:  The # that shows up when hovering
> over section-level headings is styled as the
> section-level heading is.  But the # that shows
> up when hovering over varlistentrys has the default
> text style.
>
> This works for me.  It's nice to have the "section #"s
> look like the section heading.  But the varlistentry's
> terms are smaller than the normal font, and their
> line width is less heavy than normal.  I'm not really
> invested one way or the other, but I find it kind of
> nice that the varlistentry's #s are easier to click
> on and more noticable because they're slightly larger
> than might be expected.

TBH I didn't bother a lot with this.

Most of the time it's actually not the font size but rather the
font-family which gets inherited from the parent element if you don't
set it explicitly.

The link just inherits everithing (including the color, which I have set
to inherit explicitly since links don't inherit the parent's color by
default) from it's parent, which is the HTML <dt> element (ultimately
the inheritance probably goes up to the <body> element style in pretty
much all cases).

In some instances the input <term> element contains elements that are
styled differently in the output (e.g.: <literal> which translates to
HTML <code> which has "font-family: monospace;") which makes the # from
the link appear differently than the visible element it appears after.

Since (after tweaking the color) the general visual appearence looked ok
to me, I didn't bother with this any further.

Regards,

Brar





pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Should vacuum process config file reload more often
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Generate pg_stat_get_xact*() functions with Macros