Thread: Weird table alignment override in website docs style
Now that I've pushed the first iteration of my planned reformatting of function/operator tables [1], I notice that the table headings are being laid out weirdly on the website. For example look at Table 9.33 at https://www.postgresql.org/docs/devel/functions-enum.html You can see that the headings are being placed as though by align=left, valign=bottom. This is directly contrary to what it says in the XML source: <thead> <row> <entry spanname="name" align="center" valign="middle" morerows="2">Function</entry> <entry spanname="sig" align="center">Signature</entry> </row> <row> <entry spanname="desc" align="center">Description</entry> </row> <row> <entry spanname="example" align="center">Example</entry> <entry spanname="exresult" align="center">Example Result</entry> </row> </thead> Weirder yet, the default valign=top *does* seem to get applied correctly in the table body; it's just the header that's wrong. I poked around in the website stylesheets and couldn't spot anything that seemed to be an intentional override of table alignment, so I'm wondering if this is an artifact of the margins-hacking that I do see there. Any ideas how to fix it? regards, tom lane [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e894c61836e4b967f7ec65358fdaed2ba86ed238
On 4/13/20 12:16 PM, Tom Lane wrote: > Now that I've pushed the first iteration of my planned reformatting > of function/operator tables [1], I notice that the table headings > are being laid out weirdly on the website. For example look at > Table 9.33 at > > https://www.postgresql.org/docs/devel/functions-enum.html > > You can see that the headings are being placed as though by > align=left, valign=bottom. This is directly contrary to > what it says in the XML source: > > <thead> > <row> > <entry spanname="name" align="center" valign="middle" morerows="2">Function</entry> > <entry spanname="sig" align="center">Signature</entry> > </row> > <row> > <entry spanname="desc" align="center">Description</entry> > </row> > <row> > <entry spanname="example" align="center">Example</entry> > <entry spanname="exresult" align="center">Example Result</entry> > </row> > </thead> > > Weirder yet, the default valign=top *does* seem to get applied > correctly in the table body; it's just the header that's wrong. > > I poked around in the website stylesheets and couldn't spot anything > that seemed to be an intentional override of table alignment, so > I'm wondering if this is an artifact of the margins-hacking that > I do see there. Any ideas how to fix it? Yeah, there appear to be two CSS rules overriding the valign="middle" attribute that end up forcing it to the top. It shouldn't be too difficult to fix -- I have a prototype of it working on my local. I can test it against a nightly tarball and push up a fix. Jonathan
Attachment
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 4/13/20 12:16 PM, Tom Lane wrote:
>> I poked around in the website stylesheets and couldn't spot anything
>> that seemed to be an intentional override of table alignment, so
>> I'm wondering if this is an artifact of the margins-hacking that
>> I do see there. Any ideas how to fix it?
> Yeah, there appear to be two CSS rules overriding the valign="middle"
> attribute that end up forcing it to the top. It shouldn't be too
> difficult to fix -- I have a prototype of it working on my local. I can
> test it against a nightly tarball and push up a fix.
Cool, thanks!
regards, tom lane
On 4/13/20 1:14 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 4/13/20 12:16 PM, Tom Lane wrote:
>>> I poked around in the website stylesheets and couldn't spot anything
>>> that seemed to be an intentional override of table alignment, so
>>> I'm wondering if this is an artifact of the margins-hacking that
>>> I do see there. Any ideas how to fix it?
>
>> Yeah, there appear to be two CSS rules overriding the valign="middle"
>> attribute that end up forcing it to the top. It shouldn't be too
>> difficult to fix -- I have a prototype of it working on my local. I can
>> test it against a nightly tarball and push up a fix.
>
> Cool, thanks!
The fix is now live:
https://www.postgresql.org/docs/devel/functions-enum.html
Back to opining on the other thread ;)
Thanks,
Jonathan
Attachment
"Jonathan S. Katz" <jkatz@postgresql.org> writes: > The fix is now live: > https://www.postgresql.org/docs/devel/functions-enum.html Hm, looking at https://www.postgresql.org/docs/devel/functions-enum.html it seems like it's now handling valign=middle for the "Function" header, but it's still ignoring align=center for all the headers. regards, tom lane
On 4/14/20 5:40 PM, Tom Lane wrote: > "Jonathan S. Katz" <jkatz@postgresql.org> writes: >> The fix is now live: >> https://www.postgresql.org/docs/devel/functions-enum.html > > Hm, looking at > > https://www.postgresql.org/docs/devel/functions-enum.html > > it seems like it's now handling valign=middle for the "Function" > header, but it's still ignoring align=center for all the headers. Oops I missed that, sorry. Doing some research, and from what I recall, align/valign as HTML properties are technically no longer supported in HTML5 -- you are supposed to handle this with CSS (text-align & vertical-align respectively)[1]. The main reason it still works is that browsers still support that backwards compatibility. I do have a fix on my local that accounts for this using CSS attribute selectors to check for that value and then apply it as CSS and it is safe across browsers. I do wonder if it's more prudent to have a class on it that I can check for? For the latter path, the "easiest" way would be to directly use a Bootstrap class (text-center, align-middle) but that creates tighter coupling to Bootstrap. If we have some class available, we can fairly easily hook into that. I'm ok with any of these approaches. I think it's better if we don't have deprecated HTML properties floating around (though I know we likely still have a bunch throughout the codebase), but there is at least a decent workaround. Jonathan [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/th
Attachment
On 4/14/20 5:53 PM, Jonathan S. Katz wrote: > On 4/14/20 5:40 PM, Tom Lane wrote: > I do have a fix on my local that accounts for this using CSS attribute > selectors to check for that value and then apply it as CSS and it is > safe across browsers. I went with this solution. Knowing the pain I went through the last time I tried to edit "things with attributes" with DocBook, I felt this was the last painful and generally safe path. The (proper) fix is now live. Thanks, Jonathan
Attachment
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> The (proper) fix is now live.
Looks good now, thanks!
regards, tom lane
On Tue, Apr 14, 2020 at 2:53 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 4/14/20 5:40 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> The fix is now live:
>> https://www.postgresql.org/docs/devel/functions-enum.html
>
> Hm, looking at
>
> https://www.postgresql.org/docs/devel/functions-enum.html
>
> it seems like it's now handling valign=middle for the "Function"
> header, but it's still ignoring align=center for all the headers.
Oops I missed that, sorry.
Doing some research, and from what I recall, align/valign as HTML
properties are technically no longer supported in HTML5 -- you are
supposed to handle this with CSS (text-align & vertical-align
respectively)[1]. The main reason it still works is that browsers still
support that backwards compatibility.
I do have a fix on my local that accounts for this using CSS attribute
selectors to check for that value and then apply it as CSS and it is
safe across browsers. I do wonder if it's more prudent to have a class
on it that I can check for?
I would suggest adding a class to the table element designating this as a "v12" style table. Then something like the following would (untested) just work:
table.v12 > thead > tr > th {
text-align: center,
vertical-align: middle
}
Adding semantic classes to the other elements, namely the <th>, would work too and allow for more precision and less potential for conflicts.
I do think (though not really knowing the existing state) that regardless of the precision for the sub-table selectors that these tables should probably have new css rules created for them and those rules limited to applying only to properly classed tables. Being as they should be more selective than existing table related selectors the newly added rules should then also take precedence. And newly added rules here won't impact the body of existing tables that we have - not all of which I would presume are going to change.
David J.
On 4/14/20 6:17 PM, David G. Johnston wrote: > On Tue, Apr 14, 2020 at 2:53 PM Jonathan S. Katz <jkatz@postgresql.org > <mailto:jkatz@postgresql.org>> wrote: > > On 4/14/20 5:40 PM, Tom Lane wrote: > > "Jonathan S. Katz" <jkatz@postgresql.org > <mailto:jkatz@postgresql.org>> writes: > >> The fix is now live: > >> https://www.postgresql.org/docs/devel/functions-enum.html > > > > Hm, looking at > > > > https://www.postgresql.org/docs/devel/functions-enum.html > > > > it seems like it's now handling valign=middle for the "Function" > > header, but it's still ignoring align=center for all the headers. > > Oops I missed that, sorry. > > Doing some research, and from what I recall, align/valign as HTML > properties are technically no longer supported in HTML5 -- you are > supposed to handle this with CSS (text-align & vertical-align > respectively)[1]. The main reason it still works is that browsers still > support that backwards compatibility. > > I do have a fix on my local that accounts for this using CSS attribute > selectors to check for that value and then apply it as CSS and it is > safe across browsers. I do wonder if it's more prudent to have a class > on it that I can check for? > > > I would suggest adding a class to the table element designating this as > a "v12" style table. This would involve edits to the source documentation generation. Perhaps not unreasonable to do, and then we can namespace the changes (which we already do in the pgweb CSS). However, I would be a -1 for doing it by PostgreSQL version, but rather have it for "table version" as the table versions change less. Jonathan
Attachment
On Tue, Apr 14, 2020 at 3:29 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
However, I would be a -1 for doing it by PostgreSQL version, but rather
have it for "table version" as the table versions change less.
Agreed, but there isn't presently a table version value. We could call unversioned tables "version 1" and then these become "version 2". Or we can call them "version 12 (13?)" after the version where they were first defined/introduced. We wouldn't change them annually.
Using numbers at all implies order which really doesn't apply here so a noun label seems preferable to a numeric one anyway.
David J.
On Wed, Apr 15, 2020 at 12:29 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 4/14/20 6:17 PM, David G. Johnston wrote:
> On Tue, Apr 14, 2020 at 2:53 PM Jonathan S. Katz <jkatz@postgresql.org
> <mailto:jkatz@postgresql.org>> wrote:
>
> On 4/14/20 5:40 PM, Tom Lane wrote:
> > "Jonathan S. Katz" <jkatz@postgresql.org
> <mailto:jkatz@postgresql.org>> writes:
> >> The fix is now live:
> >> https://www.postgresql.org/docs/devel/functions-enum.html
> >
> > Hm, looking at
> >
> > https://www.postgresql.org/docs/devel/functions-enum.html
> >
> > it seems like it's now handling valign=middle for the "Function"
> > header, but it's still ignoring align=center for all the headers.
>
> Oops I missed that, sorry.
>
> Doing some research, and from what I recall, align/valign as HTML
> properties are technically no longer supported in HTML5 -- you are
> supposed to handle this with CSS (text-align & vertical-align
> respectively)[1]. The main reason it still works is that browsers still
> support that backwards compatibility.
>
> I do have a fix on my local that accounts for this using CSS attribute
> selectors to check for that value and then apply it as CSS and it is
> safe across browsers. I do wonder if it's more prudent to have a class
> on it that I can check for?
>
>
> I would suggest adding a class to the table element designating this as
> a "v12" style table.
This would involve edits to the source documentation generation. Perhaps
not unreasonable to do, and then we can namespace the changes (which we
already do in the pgweb CSS).
However, I would be a -1 for doing it by PostgreSQL version, but rather
have it for "table version" as the table versions change less.
We could add a wrapper maybe? That is, we have a "<div id="docContent">". We could add a version-dependent class to that one, e.g. class="docsv12" and then style things below that.
But I'm not sure that's going to be scalable? You'll eventually end up with rules that match docsv12, docsv13, docsv14, docsv15 etc. AFAIK you don't do greaterthan/lessthan matching in css?
Bottom line is adding any info that we have at the db level to the wrapper is easy.