Thread: [HACKERS] Small issue in online devel documentation build

When consulting the online "devel" documentation, for instance for 
"pgbench":
    https://www.postgresql.org/docs/devel/static/pgbench.html

Unordered lists <ul> are shown in bold, as can be seen in the -M option 
and in the description of random functions. This is because "ul" is in 
class "c2" in the html:
    <ul class="itemizedList c2"> ...

I cannot reproduce this when generating html for head, so I gather that 
the web-site doc generation must be based on a different transformations.

My point is that some xsl file should be fixed somewhere, probably, to 
avoid that.

-- 
Fabien.

On Thu, Feb 16, 2017 at 1:05 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> When consulting the online "devel" documentation, for instance for
> "pgbench":
>
>         https://www.postgresql.org/docs/devel/static/pgbench.html
>
> Unordered lists <ul> are shown in bold, as can be seen in the -M option and
> in the description of random functions. This is because "ul" is in class
> "c2" in the html:
>
>         <ul class="itemizedList c2"> ...
>
> I cannot reproduce this when generating html for head, so I gather that the
> web-site doc generation must be based on a different transformations.
>
> My point is that some xsl file should be fixed somewhere, probably, to avoid
> that.

Yeah, I noticed this too, and I think Ashutosh also complained about
it on another thread.  It's pretty annoying - I hope somebody can
figure out the cause and fix it.  It seems to be only affecting the
development docs.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

>> My point is that some xsl file should be fixed somewhere, probably, to avoid
>> that.
>
> Yeah, I noticed this too, and I think Ashutosh also complained about
> it on another thread.  It's pretty annoying - I hope somebody can
> figure out the cause and fix it.  It seems to be only affecting the
> development docs.

My 0.02€:

After some random digging, it seems that the documentation files are 
loaded from provided tarballs by a script: "tools/docs/docload.py" 
maintained in "pgweb.git". Maybe this is run from some cron.

AFAICS from the script, the provided tarballs contains the generated html 
that someone/something has already generated and put somewhere. I have 
found no clear clue about who, where and when. However I would bet that 
"Magnus Hagander" and "Dave Page" know, given that they commits suggest 
that they are maintaining the site:-)

The load script passes the doc through "tidy" with some options, and 
registers the pages into a database probably for django. I doubt this 
would change the ul class.

-- 
Fabien.

Hello Magnus,


> It turns out the "c2" class is added by tidy. The reason is this:
> http://api.html-tidy.org/tidy/quickref_5.0.0.html#clean

> I've removed the flag for the devel docs build for now (or - for any XML
> based docs build). I've also forced another docs load, so the results can
> be checked.

Indeed, thanks, now it looks great... under firefox at least.


Another issue in the new HTML documentation, this time not related to the 
web site. Under chrome there are some strange font size effects on 
options, for instance with this HTML in "app-psql.html":
 <span class="term">   <code class="option">-f     <em class="replaceable"><code>filename</code></em>   </code>   <br>
</span>

For previous versions, the following html was generated:
  <tt class="OPTION">-f <tt class="REPLACEABLE c2">filename</tt></tt>


The filename in the newer html appears much larger under chrome, seemingly 
because of the <code> within a <code>. Maybe a bug in chrome CSS 
interpretation, because CSS on code seems to indicate "font-size: 1.3em", 
but it seems to do 1.3**2 instead for "filename"... However it does not do 
that elsewhere so it may not be that simple...


Basically it looks ok under chrome if in the initial sgml file there is:
  <term><option>-s</option> <replaceable>scale_factor</></term>

(replaceable is out of option)

But bad on:
  <term><option>--tablespace=<replaceable>tablespace</replaceable></option></term>

(replaceable is in the option), because the size change is somehow applied 
twice.

The docbook doc says that "replaceable" is a children of "option", which 
seems to suggest that this nested usage is legit... but it may be buggy as 
well.


This may be fixed/worked around in several places:
 1. html generation could be clever enough not to nest "code" tags?    or generate tt tags instead as was done before?
    I have not found where this transformation is defined, probably    somewhere within "docbook"...
 2. avoid replaceable within option in initial sgml files    => many changes, will reappear if someone forgets.
 3. some more post-processing tidying could be done    hmmm:-(
 4. chrome should be repaired if there is indeed a bug...

-- 
Fabien.

> <span class="term">
>   <code class="option">-f
>     <em class="replaceable"><code>filename</code></em>
>   </code>
>   <br>
>  </span>

> The filename in the newer html appears much larger under chrome, seemingly 
> because of the <code> within a <code>. Maybe a bug in chrome CSS 
> interpretation, because CSS on code seems to indicate "font-size: 1.3em", but 
> it seems to do 1.3**2 instead for "filename"... However it does not do that 
> elsewhere so it may not be that simple...

> 2. avoid replaceable within option in initial sgml files
>    => many changes, will reappear if someone forgets.

I wrote a few lines of perl to move replaceable out of option and did some 
manual editing is special cases, the resulting simple 359 changes is 
attached.

-- 
Fabien.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2/19/17 12:34, Fabien COELHO wrote:
> I wrote a few lines of perl to move replaceable out of option and did some 
> manual editing is special cases, the resulting simple 359 changes is 
> attached.

If the stylesheet produces unpleasant output, then the stylesheet should
be changed.

The current markup looks fine (to me) with the minimal default/non-web
stylesheet, so the issue is somewhere else.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hello Peter,

>> I wrote a few lines of perl to move replaceable out of option and did some
>> manual editing is special cases, the resulting simple 359 changes is
>> attached.
>
> If the stylesheet produces unpleasant output, then the stylesheet should
> be changed.

Sure.

I'm not sure whether it is a stylesheet issue: it is the stylesheet as 
interpreted by chrome... all is fine with firefox. Whether the bug is in 
chrome or the stylesheet or elsewhere is well beyond my HTML/CSS skills, 
but I can ask around.

> The current markup looks fine (to me) with the minimal default/non-web
> stylesheet, so the issue is somewhere else.

Attached how "Google Chrome 56.0.2924.87 (Official Build) (64-bit)" on my 
ubuntu laptop shows the options in of the psql dev doc using the online 
css.

-- 
Fabien.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

> I'm not sure whether it is a stylesheet issue: it is the stylesheet as 
> interpreted by chrome... all is fine with firefox. Whether the bug is in 
> chrome or the stylesheet or elsewhere is well beyond my HTML/CSS skills, but 
> I can ask around.

After asking around, and testing with a colleague, we got the same 
strange size behavior on firefox mac as well.

There are 2 possible solutions:

(1) do not nest in the first place (i.e. apply the patch I sent).

(2) do use absolute sizes in the CSS, not relative ones like "1.3em"    which accumulate multiplications when code
appearsin code,    and count on the navigator ctrl-+/- for users to adjust size    consistently to their needs.
 

-- 
Fabien.

> After asking around, and testing with a colleague, we got the same strange 
> size behavior on firefox mac as well.
>
> There are 2 possible solutions:
>
> (1) do not nest in the first place (i.e. apply the patch I sent).
>
> (2) do use absolute sizes in the CSS, not relative ones like "1.3em"
>    which accumulate multiplications when code appears in code,
>    and count on the navigator ctrl-+/- for users to adjust size
>    consistently to their needs.

(3) a CSS work-around, including the "!important" marker:
    code code {      font-size: 100% !important;    }

This is probably the minimum fuss solution.

-- 
Fabien.

On 3/2/17 05:50, Fabien COELHO wrote:
> (2) do use absolute sizes in the CSS, not relative ones like "1.3em"
>      which accumulate multiplications when code appears in code,
>      and count on the navigator ctrl-+/- for users to adjust size
>      consistently to their needs.

I think what you are looking at is the web site stylesheet.  The whole
thing looks fine to me using the default stylesheet.  On the web site,
it looks wrong to me too.  I don't know what the rationale for using
1.3em for <code> is, but apparently it's not working correctly.

We could perhaps consider which markup style is better, but the problem
is that it's hard to enforce either way going forward.  So we need to
find the root of the problem.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hello Peter,

> I think what you are looking at is the web site stylesheet.

Yep.

> The whole thing looks fine to me using the default stylesheet.  On the 
> web site, it looks wrong to me too.  I don't know what the rationale for 
> using 1.3em for <code> is, but apparently it's not working correctly.

Indeed. The idea of relative size is to be able to adjust the size for the 
whole page and have everything scale accordingly... however this mostly 
works well with text, but not with images. It seems that the trend is now 
to specify absolute size, and to let the browser do whole page scaling as 
required by the user.

> We could perhaps consider which markup style is better, but the problem
> is that it's hard to enforce either way going forward.  So we need to
> find the root of the problem.

The root of the problem is the combination of relative size & nesting, so 
one or the other has to be removed:
 (1) don't nest in the input (patch I sent) (2) don't use relative sizes (update the web site CSS)

Otherwise there are workarounds:
 (3) CSS work around "code code { font-size: 100% !important; }" (4) unnest code in the output by some postprocessing
orsome more     clever transformation.
 

-- 
Fabien.

I think the fix belongs into the web site CSS, so there is nothing to
commit into PostgreSQL here.  I will close the commit fest entry, but I
have added a section to the open items list so we keep track of it.
(https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hello Peter,

> I think the fix belongs into the web site CSS, so there is nothing to
> commit into PostgreSQL here.

Indeed, the changes were only for the "remove nesting" solution.

> I will close the commit fest entry, but I have added a section to the 
> open items list so we keep track of it. 
> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)

I put forward that the quick workaround a colleague of mine suggested (aka 
something like code code { font-size: 100%; important! }) could also be 
applied to the web site CSS while waiting for a more definite answer which 
might take some pretty unknown time close to never?

-- 
Fabien.

On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
> I think the fix belongs into the web site CSS, so there is nothing to
> commit into PostgreSQL here.  I will close the commit fest entry, but I
> have added a section to the open items list so we keep track of it.
> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)

[Action required within three days.  This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item.  Peter,
since you committed the patch believed to have created it, you own this open
item.  If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know.  Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message.  Include a date for your subsequent status update.  Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10.  Consequently, I will appreciate your efforts
toward speedy resolution.  Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

On 4/5/17 02:56, Noah Misch wrote:
> On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
>> I think the fix belongs into the web site CSS, so there is nothing to
>> commit into PostgreSQL here.  I will close the commit fest entry, but I
>> have added a section to the open items list so we keep track of it.
>> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
> 
> [Action required within three days.  This is a generic notification.]

I will work on this next week.  I believe I will be able to provide a
patch for the web site CSS by April 12, but ultimate success will likely
depend on the collaboration of the web team.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 4/5/17 02:56, Noah Misch wrote:
> > On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
> >> I think the fix belongs into the web site CSS, so there is nothing to
> >> commit into PostgreSQL here.  I will close the commit fest entry, but I
> >> have added a section to the open items list so we keep track of it.
> >> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
> >
> > [Action required within three days.  This is a generic notification.]
>
> I will work on this next week.  I believe I will be able to provide a
> patch for the web site CSS by April 12, but ultimate success will likely
> depend on the collaboration of the web team.

I'm happy to try and help with this.

Thanks!

Stephen

>>> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
>>
>> [Action required within three days.  This is a generic notification.]
>
> I will work on this next week.  I believe I will be able to provide a
> patch for the web site CSS by April 12, but ultimate success will likely
> depend on the collaboration of the web team.

Just to point out that as it has been decided to fix the web site CSS, 
there is no expected change for pg 10 source base, so ISTM that the item 
can be closed as far as pg 10 is concerned.

-- 
Fabien.

On Wed, Apr 5, 2017 at 2:18 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>>> [Action required within three days.  This is a generic notification.]
>>
>>
>> I will work on this next week.  I believe I will be able to provide a
>> patch for the web site CSS by April 12, but ultimate success will likely
>> depend on the collaboration of the web team.
>
>
> Just to point out that as it has been decided to fix the web site CSS, there
> is no expected change for pg 10 source base, so ISTM that the item can be
> closed as far as pg 10 is concerned.

Well, the documentation doesn't look right, currently, so I think that
should be fixed before we close this.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Mar 24, 2017 at 07:01:46AM +0100, Fabien COELHO wrote:
> 
> Hello Peter,
> 
> >I think the fix belongs into the web site CSS, so there is nothing to
> >commit into PostgreSQL here.
> 
> Indeed, the changes were only for the "remove nesting" solution.
> 
> >I will close the commit fest entry, but I have added a section to the open
> >items list so we keep track of it.
(https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
> 
> I put forward that the quick workaround a colleague of mine suggested (aka
> something like code code { font-size: 100%; important! }) could also be
> applied to the web site CSS while waiting for a more definite answer which
> might take some pretty unknown time close to never?

Sorry I am just getting back to this.  Below I am going to cover only
the problem with the font size of nested <code> tags, and I am going to
confirm what most people already figured out.

The basic problem was already posted by Fabien, with an image example. 
The cause of the fonts being too large on Chrome is an interaction of
Chrome's default font size for different blocks, the JavaScript that is
meant to fix such mismatches, and the new nested code blocks in the PG
10 docs.

First, the JavaScript:

    https://github.com/postgres/pgweb/blob/master/media/js/monospacefix.js

There is no git history for this file except for its initial checkin in
2011, but I am pretty sure I wrote it.  What it does is to create <pre>
and <p> blocks, find the font point size, and compute a ratio.  If the
ratio is not 1, <pre>, <tt>, and <code> blocks are adjusted in size to
match <p>.  The complex part is that the JavaScript conditionally
injects CSS into the web-page to accomplish this.

The reason the PG 10 docs look fine on Linux Firefox is because the font
points sizes match so no CSS is injected.  They don't match on Chrome,
so the CSS is injected.  When the CSS hits double-embedded code blocks,
<code> <code>, it makes the font too large because it double-adjusts.

The fix, as Fabien identified, is to conditionally inject additional CSS
to be _more_ specific than the first CSS and set the font-size to a
simple '1em' so the first CSS is not called twice.  I don't think
'important!' is necessary but it would be good to test this.

Attached is a patch that can be applied to pgweb which should fix all of
this.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

> The fix, as Fabien identified, is to conditionally inject additional CSS
> to be _more_ specific than the first CSS and set the font-size to a
> simple '1em' so the first CSS is not called twice.  I don't think
> 'important!' is necessary but it would be good to test this.

I did not wrote the fix, a JS-guru colleague of mine did, and he argued 
that it was useful to fix priorities between competing and contradicting 
CSS rules. Now maybe in this particular case it might work without it.

> Attached is a patch that can be applied to pgweb which should fix all of
> this.

Great, the devel doc looks ok now.

-- 
Fabien.

On Sat, Apr  8, 2017 at 07:33:15PM +0900, Fabien COELHO wrote:
> 
> >The fix, as Fabien identified, is to conditionally inject additional CSS
> >to be _more_ specific than the first CSS and set the font-size to a
> >simple '1em' so the first CSS is not called twice.  I don't think
> >'important!' is necessary but it would be good to test this.
> 
> I did not wrote the fix, a JS-guru colleague of mine did, and he argued that
> it was useful to fix priorities between competing and contradicting CSS
> rules. Now maybe in this particular case it might work without it.

It would be needed for his version because he wasn't matching the exact
tags of the CSS that the JavaScript generated.

> >Attached is a patch that can be applied to pgweb which should fix all of
> >this.
> 
> Great, the devel doc looks ok now.

Great.

What other problems do we have with pgweb that I can work on?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
> What other problems do we have with pgweb that I can work on?

Well, the 10devel documentation doesn't believe in orange.  Compare:

https://www.postgresql.org/docs/devel/static/sql-createtable.html
https://www.postgresql.org/docs/9.6/static/sql-createtable.html

I think that needs to be fixed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Sat, Apr  8, 2017 at 12:50:19PM -0400, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > What other problems do we have with pgweb that I can work on?
> 
> Well, the 10devel documentation doesn't believe in orange.  Compare:
> 
> https://www.postgresql.org/docs/devel/static/sql-createtable.html
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
> 
> I think that needs to be fixed.

The attached CSS patch will fix that specific issue, but I am unclear if
there are more places that need color.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On Sun, Apr  9, 2017 at 07:00:38PM +0200, Magnus Hagander wrote:
> 
> 
> On Sun, Apr 9, 2017 at 2:32 AM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     On Sat, Apr  8, 2017 at 12:50:19PM -0400, Robert Haas wrote:
>     > On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
>     > > What other problems do we have with pgweb that I can work on?
>     >
>     > Well, the 10devel documentation doesn't believe in orange.  Compare:
>     >
>     > https://www.postgresql.org/docs/devel/static/sql-createtable.html
>     > https://www.postgresql.org/docs/9.6/static/sql-createtable.html
>     >
>     > I think that needs to be fixed.
> 
>     The attached CSS patch will fix that specific issue, but I am unclear if
>     there are more places that need color.
> 
> 
> 
> Does this not also affect existing versions of the docs? AFAICT it would hit
> any and all <h2> tags, and we certainly have those in earlier versions?

It would hit any class of .refentrytitle inside of an <h2> block.  I
didn't that that happened in the old docs, but I can use an href filter
to do it only for docs of versions starting with '1' or saying 'devel'.

> And it also modifies a global stylesheet for *all* pages. So what about the
> <h2> on all the non-docs pages?

Again, we can restrict to only certain href patterns.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Sun, Apr  9, 2017 at 06:59:09PM +0200, Magnus Hagander wrote:
> On Sat, Apr 8, 2017 at 3:52 AM, Bruce Momjian <bruce@momjian.us> wrote:
>     Attached is a patch that can be applied to pgweb which should fix all of
>     this.
>
> Is there any chance we can find a way to do this with actual CSS selectors and
> not use javascript? I realize there might not be, but have we explored the
> option properly on the way the site layout looks now and with reasonably modern
> browsers?

I realize that using JavaScript to insert CSS styles into an HTML
document is complex, but I know of no other way to scale a font style to
match another font style.  CSS doesn't give you that control.  You can
use CSS to prevent the display of certain font styles, but that hardly
seems like a win.  There is probably a way to do the entire thing only
in JavaScript, but again, that doesn't seem any better.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Mon, Apr 10, 2017 at 10:17:26AM +0200, Magnus Hagander wrote:
>     didn't that that happened in the old docs, but I can use an href filter
>     to do it only for docs of versions starting with '1' or saying 'devel'.
> 
> That said, doing something like this would probably be cleaner. However, I
> think doing it based on href is a bad idea -- we're bound to silently break
> that somehow.
> 
> What if we changed the <div id="docContent"> tag to be something like <div id=
> "docContent" class="post-10"> 
> 
> Please suggest a better name -- but the idea being we add a class do it,
> conditionally for the docs of v10 and newer (which would include devel). That
> way that logic stays where it belongs, and the CSS just uses the information to
> style on.

While we could trigger on some special tag, it is best to trigger on
something the build system does anyway so that if someone builds pre-10
docs with the new build system, they get the same output.  The attached
patch uses:

    div.refnamediv h2 .refentrytitle

and "div.refnamediv" is only generated in the new build system.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On 4/8/17 12:50, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> What other problems do we have with pgweb that I can work on?
> 
> Well, the 10devel documentation doesn't believe in orange.  Compare:
> 
> https://www.postgresql.org/docs/devel/static/sql-createtable.html
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
> 
> I think that needs to be fixed.

Patch for that attached.

Also patch for improved note/warning/etc. formatting.

Another issue I saw is that tables no longer get the fancy style, e.g.,
https://www.postgresql.org/docs/devel/static/sql-syntax-lexical.html.
The style selector is table.table, which is what the build produces, but
somehow the class attribute no longer shows up on the web site.

Along with the nested <code> issue, which is already being discussed,
these are all the issues I'm aware of.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On 4/11/17 08:49, Magnus Hagander wrote:
> At the risk of being proven wrong again, won't this affect <h2> tags in
> the old documentation as well? And if so, is that something we actually
> want?

Right.  New patch with more refined selectors attached.

> It does? The output on my laptop for that produces <table
> summary="Backslash Escape Sequences" border="1"> (for example). It's
> wrapped in a div with class=table. But the old code had <table
> border="1" class="CALSTABLE">. And AFAICT, it's the CALSTABLE that the
> css is actually matching on?
> 
> Could this be a toolchain version thing? I'm using jessie on my laptop,
> which is the same one that the website is built with.

Seems so.  Patch for that attached as well.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

On Wed, Apr 12, 2017 at 01:31:51PM +0200, Magnus Hagander wrote:
> I think that only leaves the change to the javascript code that Bruce sent.
> Let's see if we can figure out a way to do that one without requiring
> javascript, but after that we have covered all listed issues I think?

Well, we have been using JavaScript for years, so my patch only fixes
the JavaScript we already have.  Seems applying the fix now makes sense
and then we can ponder other methods.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 4/12/17 07:31, Magnus Hagander wrote:
> Once difference I notice is that for example the "note boxes" are no
> longer centered, but they do now get the new formatting.

I have committed something for that.  The issue was that the generated
HTML contained hard-coded style attributes.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/12/17 15:43, Peter Eisentraut wrote:
> On 4/12/17 07:31, Magnus Hagander wrote:
>> Once difference I notice is that for example the "note boxes" are no
>> longer centered, but they do now get the new formatting.
> 
> I have committed something for that.  The issue was that the generated
> HTML contained hard-coded style attributes.

This appears to have been successful.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/12/17 09:50, Bruce Momjian wrote:
> On Wed, Apr 12, 2017 at 01:31:51PM +0200, Magnus Hagander wrote:
>> I think that only leaves the change to the javascript code that Bruce sent.
>> Let's see if we can figure out a way to do that one without requiring
>> javascript, but after that we have covered all listed issues I think?
> 
> Well, we have been using JavaScript for years, so my patch only fixes
> the JavaScript we already have.  Seems applying the fix now makes sense
> and then we can ponder other methods.

I have googled a bit.  These two articles describe what I think is the
issue we are trying to address:

http://code.stephenmorley.org/html-and-css/fixing-browsers-broken-monospace-font-handling/

http://meyerweb.com/eric/thoughts/2010/02/12/fixed-monospace-sizing/

The recipe in the first one seems to work somewhat, but not quite as
well as the current javascript.  (The recipe in the second article is
ultimately equivalent but more verbose.)

I tend to agree with Bruce that we could just fix this within the
current framework.  But if we want to make a change, there is the
information.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Apr 05, 2017 at 01:43:42PM -0400, Peter Eisentraut wrote:
> On 4/5/17 02:56, Noah Misch wrote:
> > On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
> >> I think the fix belongs into the web site CSS, so there is nothing to
> >> commit into PostgreSQL here.  I will close the commit fest entry, but I
> >> have added a section to the open items list so we keep track of it.
> >> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
> > 
> > [Action required within three days.  This is a generic notification.]
> 
> I will work on this next week.  I believe I will be able to provide a
> patch for the web site CSS by April 12, but ultimate success will likely
> depend on the collaboration of the web team.

This PostgreSQL 10 open item is past due for your status update.  Kindly send
a status update within 24 hours, and include a date for your subsequent status
update.  Refer to the policy on open item ownership:
https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

On 4/7/17 21:52, Bruce Momjian wrote:
> The fix, as Fabien identified, is to conditionally inject additional CSS
> to be _more_ specific than the first CSS and set the font-size to a
> simple '1em' so the first CSS is not called twice.  I don't think
> 'important!' is necessary but it would be good to test this.
> 
> Attached is a patch that can be applied to pgweb which should fix all of
> this.

IMO, this patch is correct and the best way to fix this.  Please proceed.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/14/17 01:49, Noah Misch wrote:
> On Wed, Apr 05, 2017 at 01:43:42PM -0400, Peter Eisentraut wrote:
>> On 4/5/17 02:56, Noah Misch wrote:
>>> On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
>>>> I think the fix belongs into the web site CSS, so there is nothing to
>>>> commit into PostgreSQL here.  I will close the commit fest entry, but I
>>>> have added a section to the open items list so we keep track of it.
>>>> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
>>>
>>> [Action required within three days.  This is a generic notification.]
>>
>> I will work on this next week.  I believe I will be able to provide a
>> patch for the web site CSS by April 12, but ultimate success will likely
>> depend on the collaboration of the web team.
> 
> This PostgreSQL 10 open item is past due for your status update.  Kindly send
> a status update within 24 hours, and include a date for your subsequent status
> update.  Refer to the policy on open item ownership:
> https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

A patch for the web site CSS has been proposed but it is not getting the
same urgent attention.  I will report back by Tuesday.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, Apr 14, 2017 at 11:25:48AM -0400, Peter Eisentraut wrote:
> On 4/14/17 01:49, Noah Misch wrote:
> > On Wed, Apr 05, 2017 at 01:43:42PM -0400, Peter Eisentraut wrote:
> >> On 4/5/17 02:56, Noah Misch wrote:
> >>> On Thu, Mar 23, 2017 at 11:21:39PM -0400, Peter Eisentraut wrote:
> >>>> I think the fix belongs into the web site CSS, so there is nothing to
> >>>> commit into PostgreSQL here.  I will close the commit fest entry, but I
> >>>> have added a section to the open items list so we keep track of it.
> >>>> (https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Documentation_tool_chain)
> >>>
> >>> [Action required within three days.  This is a generic notification.]
> >>
> >> I will work on this next week.  I believe I will be able to provide a
> >> patch for the web site CSS by April 12, but ultimate success will likely
> >> depend on the collaboration of the web team.
> > 
> > This PostgreSQL 10 open item is past due for your status update.  Kindly send
> > a status update within 24 hours, and include a date for your subsequent status
> > update.  Refer to the policy on open item ownership:
> > https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
> 
> A patch for the web site CSS has been proposed but it is not getting the
> same urgent attention.  I will report back by Tuesday.

Uh, unless I am missing something, I think it has been applied to pgweb,
specifically on April 12:
https://github.com/postgres/pgweb/commits/master

and this April 12 commit fixed the heading color:
https://github.com/postgres/pgweb/commit/c513457da76a4d864f706c21312d3def1fc8f8c8

I think the only open issue is the JavaScript CSS font fix that has a
posted patch here:
https://www.postgresql.org/message-id/20170408015201.GA18573@momjian.us

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 4/14/17 11:35, Bruce Momjian wrote:
> I think the only open issue is the JavaScript CSS font fix that has a
> posted patch here:
> 
>     https://www.postgresql.org/message-id/20170408015201.GA18573@momjian.us

The open item is specifically about this issue.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 4/14/17 14:45, Magnus Hagander wrote:
>     Attached is a patch that can be applied to pgweb which should fix all of
>     this.
> 
> 
> 
> Applied, thanks. 

Oops, one </style> too many.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, Apr 14, 2017 at 09:38:32PM +0200, Magnus Hagander wrote:
> On Fri, Apr 14, 2017 at 9:36 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> > On 4/14/17 14:45, Magnus Hagander wrote:
> > >     Attached is a patch that can be applied to pgweb which should fix all of
> > >     this.

> Indeed. Fix pushed.

I see <replaceable> formats as italic, instead of the bold-italic seen in the
9.6 docs.  (This is visible in the CREATE TABLE page, linked upthread.)  Is it
worth restoring the former formatting thereof?

Noah Misch wrote:
> On Fri, Apr 14, 2017 at 09:38:32PM +0200, Magnus Hagander wrote:
> > On Fri, Apr 14, 2017 at 9:36 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
> > > On 4/14/17 14:45, Magnus Hagander wrote:
> > > >     Attached is a patch that can be applied to pgweb which should fix all of
> > > >     this.
> 
> > Indeed. Fix pushed.
> 
> I see <replaceable> formats as italic, instead of the bold-italic seen in the
> 9.6 docs.  (This is visible in the CREATE TABLE page, linked upthread.)  Is it
> worth restoring the former formatting thereof?

I think the bold in the original looks terrible.  Regular italic looks
much nicer to me, so I'd keep it as is.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services