Re: Poll: are people okay with function/operator table redesign? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Poll: are people okay with function/operator table redesign?
Date
Msg-id 15395.1587660207@sss.pgh.pa.us
Whole thread Raw
In response to Re: Poll: are people okay with function/operator table redesign?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Poll: are people okay with function/operator table redesign?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Thu, Apr 23, 2020 at 12:04:01PM -0400, Tom Lane wrote:
>> As I said, I'm happy to do the legwork of improving the markup if someone
>> will point me in the right direction.  But I know next to zip about CSS,
>> so it would not be productive for me to do the basic design there ---
>> it would take too long and there would probably still be lots to criticize
>> in whatever I came up with.

> I can do the CSS if you tell me what you want.

I think the existing visual appearance is more or less agreed to, so
what we want is to reproduce that as closely as possible from some
saner markup.  The first problem is to agree on what "saner markup"
is exactly.

We could possibly use margin and vertical-space CSS adjustments starting
from just using several <para>s within each table cell (one <para> for
signature, one for description, one for each example).  I'm not sure
whether that meets Peter's desire for "semantic" markup though.  It's not
any worse than the old way with otherwise-unlabeled <entry>s, but it's not
better either.  Do we want, say, to distinguish descriptions from examples
in the markup?  If so, will paras with a role attribute do, or does it
need to be something else?

I'm also not sure whether or not Peter is objecting to the way I used
<returnvalue>.  That seems reasonably semantically-based to me, but since
he hasn't stated what his criteria are, I don't know if he thinks so.
(I'll admit that it's a bit of an abuse to use that for both function
return types and example results.)  If that's out then we need some other
design for getting the right arrows into place.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators
Next
From: Alvaro Herrera
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?