Re: Poll: are people okay with function/operator table redesign?

Pierre Giraud <pierre(dot)giraud(at)dalibo(dot)com> writes:
> Le 16/04/2020 à 00:18, Tom Lane a écrit :
>> The main disadvantage I can see to the v2 design is that we're back
>> to having two <rows> per function, which is inevitably going to result
>> in PDF builds putting page breaks between those rows. But you can't
>> have everything ... and maybe we could find a way to discourage such
>> breaks if we tried.

Further experimentation shows that the PDF toolchain is perfectly willing
to put a page break *within* a multi-line <row>; if there is any
preference to break between rows instead, it's pretty weak. So that
argument is a red herring and we shouldn't waste time chasing it.
However, there'd still be some advantage in not being dependent on CSS
hackery to make it look nice in HTML.

What we're down to wanting, at this point, is basically a para with
hanging indent.

> What about putting everything into one <table row> and use a block with
> some left padding/margin for description + example.
> This would solve the PDF page break issue as well as the column
> separation border one.
> The screenshot attached uses a <dl> tag for the descrition/example block.

That looks about right, perhaps, but could you be a little clearer about
how you accomplished that?

regards, tom lane