Re: Formatting of <itemizedlist> vs role="catalog_table_entry"

Hi,

When one uses an itemizedlist inside a table row with
role="catalog_table_entry", the indentation in the website style sheet
over-indents the contents of the generated <p>. See
e.g. pg_stat_replication.state's docs:
/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW

Note the large padding-left before 'startup', 'catchup', etc.

This is caused by the following rule in the website stylesheet:
padding-left: 4em;
https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=media/css/main.css;h=3ae2b505b401662624a9f073e37646123ebc0d0e;hb=HEAD#l1055

which doesn't just apply to <p>'s directly inside catalog_table_entry, but to
everything below it as well. Leading to said indentation.

I wonder if the rule should be changed to be > p?

I'm a bit confused by the approach of padding-left: 4em; which is then undone
by text-indent: -3.5em;. Why not just set padding-left to something reasonable
for .. p.column_definition?

Greetings,

Andres Freund

On 12/28/22 6:24 PM, Andres Freund wrote:
> Hi,
>
> When one uses an itemizedlist inside a table row with
> role="catalog_table_entry", the indentation in the website style sheet
> over-indents the contents of the generated <p>. See
> e.g. pg_stat_replication.state's docs:
> /docs/devel/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW
>
> Note the large padding-left before 'startup', 'catchup', etc.
>
> This is caused by the following rule in the website stylesheet:
> padding-left: 4em;
> https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=media/css/main.css;h=3ae2b505b401662624a9f073e37646123ebc0d0e;hb=HEAD#l1055
>
> which doesn't just apply to <p>'s directly inside catalog_table_entry, but to
> everything below it as well. Leading to said indentation.
>
> I wonder if the rule should be changed to be > p?
>
>
> I'm a bit confused by the approach of padding-left: 4em; which is then undone
> by text-indent: -3.5em;. Why not just set padding-left to something reasonable
> for .. p.column_definition?

The bigger question I have is why there are <p> blocks inside of <li>.
That does not seem correct, but I believe that would have to be adjusted
from the generation, and I seem to recall that this is a common pattern
in the SGML.

(FWIW, when I remove the <p> tag from the <li>, the indentation is no
longer an issue).

I agree that the padding doesn't belong there. This was added as a part
of [1] when we re-styled the tables.

I think this needs a new rule, i.e:

#docContent table.table th.catalog_table_entry .listitem > p,
#docContent table.table td.catalog_table_entry .listitem > p {
padding-left: 0em;
}

which seems to preserve the other formatting bits that the entry needs
from the original rule, but handles the padding.

Jonathan

[1]
https://git.postgresql.org/gitweb/?p=pgweb.git;a=commit;f=media/css/main.css;h=93716f2a817dbdae8cccf86bc951b45b68ea52d9

Hi,

On 2022-12-29 18:36:27 -0500, Jonathan S. Katz wrote:
> On 12/28/22 6:24 PM, Andres Freund wrote:
> > When one uses an itemizedlist inside a table row with
> > role="catalog_table_entry", the indentation in the website style sheet
> > over-indents the contents of the generated <p>. See
> > e.g. pg_stat_replication.state's docs:
> > /docs/devel/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW
> >
> > Note the large padding-left before 'startup', 'catchup', etc.
> >
> > This is caused by the following rule in the website stylesheet:
> > padding-left: 4em;
> > https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=media/css/main.css;h=3ae2b505b401662624a9f073e37646123ebc0d0e;hb=HEAD#l1055
> >
> > which doesn't just apply to <p>'s directly inside catalog_table_entry, but to
> > everything below it as well. Leading to said indentation.
> >
> > I wonder if the rule should be changed to be > p?
> >
> >
> > I'm a bit confused by the approach of padding-left: 4em; which is then undone
> > by text-indent: -3.5em;. Why not just set padding-left to something reasonable
> > for .. p.column_definition?
>
> The bigger question I have is why there are <p> blocks inside of
> <li>.

Docbook requires something like a <para> inside an itemized list. Which
is just turned into a <p> by the xslt.

> That does not seem correct, but I believe that would have to be
> adjusted from the generation, and I seem to recall that this is a
> common pattern in the SGML.

Is it really incorrect, or just superfluous?

> (FWIW, when I remove the <p> tag from the <li>, the indentation is no longer
> an issue).

I think there's plenty other ways to end up with a <p> further down, so
I think restricting the indentation rule is a good idea anyway.

> I agree that the padding doesn't belong there. This was added as a part of
> [1] when we re-styled the tables.
>
> I think this needs a new rule, i.e:
>
> #docContent table.table th.catalog_table_entry .listitem > p,
> #docContent table.table td.catalog_table_entry .listitem > p {
> padding-left: 0em;
> }
>
> which seems to preserve the other formatting bits that the entry needs from
> the original rule, but handles the padding.

I think right now it's 0.5em that we end up (4em - 3.5em), but not sure.

I don't think resetting padding-left specifically for listitem is the
right fix. The current code is the following:

/** Formatting for entries in tables of catalog/view columns **/
#docContent table.table th.catalog_table_entry p,
#docContent table.table td.catalog_table_entry p {
margin-top: 0.1em;
margin-bottom: 0.1em;
padding-left: 4em;
text-align: left;
}

#docContent table.table th.catalog_table_entry p.column_definition {
text-indent: -3.5em;
word-spacing: 0.25em;
}

#docContent table.table td.catalog_table_entry p.column_definition {
text-indent: -3.5em;
}

ISTM that the proper way to deal with this would be to
a) change the "*.catalog_table_entry p" to "th.catalog_table_entry > p",
to avoid the style to apply to every p anywhere inside a
catalog_table_entry
b) Change the p.column_definition styles to set padding-left to 0.5em,
instead of aligning it negatively
c) probably change the p.column_definition to not be specific to .p and
then do the word-spacing bit in a separate styel

But then I haven't dealt with css in ~15 years, so take this with a
whole salt shaker.

Greetings,

Andres Freund

> On 2 Jan 2023, at 03:10, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2022-12-29 18:36:27 -0500, Jonathan S. Katz wrote:

>> That does not seem correct, but I believe that would have to be
>> adjusted from the generation, and I seem to recall that this is a
>> common pattern in the SGML.
>
> Is it really incorrect, or just superfluous?

AFAIK it's legal HTML as <li> is defined as flow context.

--
Daniel Gustafsson https://vmware.com/