Re: [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(at)cri(dot)ensmp(dot)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.

On 2/16/17 15:35, Fabien COELHO wrote:
> 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.

Can someone from the web site team look into this?

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

On Sat, Feb 18, 2017 at 1:45 AM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 2/16/17 15:35, Fabien COELHO wrote:
> > 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.
>
> Can someone from the web site team look into this?
>

Sure.

The script in question loads the docs from the build tarballs - we read
whatever goes in the snapshot tarballs on the site and load that in the db.

The developer docs, and the snapshot tarballs, run as a final step of the
buildfarm job on guaibasaurus.

The toolchain used previously (9.6) generates this code:
<P
> Protocol to use for submitting queries to the server:
<P
></P
></P><UL
><LI
><P
><TT
CLASS="LITERAL"
>simple</TT
>: use simple query protocol.</P
></LI
><LI
><P
><TT
CLASS="LITERAL"
>extended</TT
>: use extended query protocol.</P
></LI
><LI
><P
><TT
CLASS="LITERAL"
>prepared</TT
>: use extended query protocol with prepared statements.</P
></LI
></UL

(yes, including all the horrible newlines in the middle of tags and
whatnot, but there's nothing new about that)

The toolchain used for dev (10) generates this code:
<p> Protocol to use for submitting queries to the server:
</p><div class="itemizedlist"><ul class="itemizedlist"
style="list-style-type: disc; "><li class="listitem"><p><code
class="literal">simple</code>: use simple query protocol.</p></li><li
class="listitem"><p><code class="literal">extended</code>: use extended
query protocol.</p></li>

So the HTML generated is completely different. The old one didn't even use
unnumbered lists.

Is that intentional?

I for one did not realize the new toolchain created completely different
structure HTML. I know we applied a41a4cc74be8c34f7f8f1c4ec03b5dc01db06c17
to handle changes from the new toolchain, but that won't cover cases where
the whole structure is different.

In this particular case, the boldness comes from the c2 class as indicated
earlier. But that class has always been bold.

Might it just be that somebody has to actually go over the new structure of
the docs and provide the appropriate CSS rules? Or is something wrong with
the actual building of them as they give a completely different structure?

As for the reproduction - the snapshot tarballs are built by the buildfarm
animal guaibasaurus, which is on Debian Jessie. Could the inability to
reproduce be because of platform differences in the docs tools?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Hello Magnus,

> The toolchain used previously (9.6) generates this code:
> <UL
> > <LI
> > <P
> > <TT
> CLASS="LITERAL"
> > simple</TT
> > : use simple query protocol.</P
> [...]
>
> (yes, including all the horrible newlines in the middle of tags and
> whatnot, but there's nothing new about that)

Yes this is the "old" html generation with jade, which has been replaced
by some xsltproc-based html generation. Why not.

> The toolchain used for dev (10) generates this code:
>
> <p> Protocol to use for submitting queries to the server:
> </p><div class="itemizedlist"><ul class="itemizedlist"
> style="list-style-type: disc; "><li class="listitem"><p><code
> [...]

Yes, that the output I also have, which is somehow fine although verbose.
In particular, there is no "c2" class involved in "ul" above...

> So the HTML generated is completely different. The old one didn't even use
> unnumbered lists.

??? AFAICS there is a <UL> in the first 9.6 extract above... the
difference is about the added class, style & div... but the structure
seems to be basically the same.

> I for one did not realize the new toolchain created completely different
> structure HTML. I know we applied a41a4cc74be8c34f7f8f1c4ec03b5dc01db06c17
> to handle changes from the new toolchain, but that won't cover cases where
> the whole structure is different.

I'm not sure it is that different, but there seems to be side effect at
some stages when the doc files are integrated into the web site.

> In this particular case, the boldness comes from the c2 class as indicated
> earlier. But that class has always been bold.

Probably. The question is rather why is the ul in this class on the
website, while it is not in the raw generated file? What adds it?

> Might it just be that somebody has to actually go over the new structure of
> the docs and provide the appropriate CSS rules? Or is something wrong with
> the actual building of them as they give a completely different structure?

I'm unsure about "completely different", see above.

> As for the reproduction - the snapshot tarballs are built by the buildfarm
> animal guaibasaurus, which is on Debian Jessie. Could the inability to
> reproduce be because of platform differences in the docs tools?

I regenerated the 10 doc on a jessie host with the new xsltproc-based
toolchain and got the same result as what you outline above, in particular
no mention of "c2".

So my guess is that it would be enough not to add this c2 class to ul to
avoid boldness.

Now the actual web pages is clearly a reprocessing of the generated xml,
so this c2 get added between the raw xhtml documentation that one can
reproduce and the web-page xml where there are specific headers for
navigation, as well as some heavy reindentation.

The script on pgweb.git suggest that a "tidy" thing is called on the xml
which is probably responsible for the reindentation, but maybe there are
other xslt or misc tools involved which are not accessible and contribute
to the final result?

--
Fabien.

On Sat, Feb 18, 2017 at 1:44 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

>
> Hello Magnus,
>
> The toolchain used previously (9.6) generates this code:
>> <UL
>> > <LI
>> > <P
>> > <TT
>> CLASS="LITERAL"
>> > simple</TT
>> > : use simple query protocol.</P
>> [...]
>>
>> (yes, including all the horrible newlines in the middle of tags and
>> whatnot, but there's nothing new about that)
>>
>
> Yes this is the "old" html generation with jade, which has been replaced
> by some xsltproc-based html generation. Why not.
>
> The toolchain used for dev (10) generates this code:
>>
>> <p> Protocol to use for submitting queries to the server:
>> </p><div class="itemizedlist"><ul class="itemizedlist"
>> style="list-style-type: disc; "><li class="listitem"><p><code
>> [...]
>>
>
> Yes, that the output I also have, which is somehow fine although verbose.
> In particular, there is no "c2" class involved in "ul" above...

Ah, that is correct. I thought I could see it there, but turns out that no,
I cannot :) I was clearly not awake. My apologies.

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

There was a reason this was needed on the old docs. I honestly don't
remember what it was though, but it was needed (but many things were needed
on that source).

Turning if off makes that page work. It might break pages elsewhere though.

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.

Let's see if that breaks something else...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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.

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.

> 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 appears in 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 or some more
clever transformation.

--
Fabien.

Web team, any thoughts on the CSS details?

On 3/4/17 02:00, Fabien COELHO wrote:
>
> 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 or some more
> clever transformation.
>

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

On Fri, Mar 10, 2017 at 11:21:33AM -0500, Peter Eisentraut wrote:
> Web team, any thoughts on the CSS details?

I think I did some CSS long ago to adjust font sizes for certain font
types on our website. Should I find that?

--
Bruce Momjian <bruce(at)momjian(dot)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 +

Hello Bruce,

> On Fri, Mar 10, 2017 at 11:21:33AM -0500, Peter Eisentraut wrote:
>> Web team, any thoughts on the CSS details?
>
> I think I did some CSS long ago to adjust font sizes for certain font
> types on our website. Should I find that?

Dunno. Maybe?

The issue is the 1.3em associated to code, because when code is used
within code, the 1.3 multiplier accumulates and things get bigger and
bigger.

Now the font size fixing is a good thing because courrier like fonts are
somehow too small, it just must not accumulate, hence the suggested
solutions, one of which should be applied.

--
Fabien.

On Sat, Mar 11, 2017 at 07:04:06AM +0100, Fabien COELHO wrote:
>
> Hello Bruce,
>
> >On Fri, Mar 10, 2017 at 11:21:33AM -0500, Peter Eisentraut wrote:
> >>Web team, any thoughts on the CSS details?
> >
> >I think I did some CSS long ago to adjust font sizes for certain font
> >types on our website. Should I find that?
>
> Dunno. Maybe?
>
> The issue is the 1.3em associated to code, because when code is used within
> code, the 1.3 multiplier accumulates and things get bigger and bigger.
>
> Now the font size fixing is a good thing because courrier like fonts are
> somehow too small, it just must not accumulate, hence the suggested
> solutions, one of which should be applied.

OK, it was Javascript, not CSS. Here is what I think I did to fix the
fonts:

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

--
Bruce Momjian <bruce(at)momjian(dot)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 +

>> Now the font size fixing is a good thing because courrier like fonts are
>> somehow too small, it just must not accumulate, hence the suggested
>> solutions, one of which should be applied.
>
> OK, it was Javascript, not CSS. Here is what I think I did to fix the
> fonts:
>
> https://github.com/postgres/pgweb/blob/master/media/js/monospacefix.js

Indeed, this javascript does generates the faulty display based on a
dynamic evaluation of relative font sizes. That's fun.

Maybe just generate a fixed size instead so as to avoid accumulation on
nesting?

--
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(dot)eisentraut(at)2ndquadrant(dot)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(at)cri(dot)ensmp(dot)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(at)momjian(dot)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 +

> 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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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 3:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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.
>

There's more history in the pgweb-old repository. You can see that this
incarnation of the file actually came from Thom Brown:

https://git.postgresql.org/gitweb/?p=pgweb-old.git;a=commitdiff;h=c67090da83079be8f268564adb63e3f0d3379f29

Your was probably the version even before that one.

> 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.
>
>
Is there any chance we can find a way to do this witha ctual 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?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

On Sun, Apr 9, 2017 at 2:32 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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?

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

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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 4:02 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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(at)momjian(dot)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(at)momjian(dot)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
>

Oh. That shows my love for css, i missed the fact that it will only hit
*subentries* with that class.
So it hits either "h1" *or* "h2" followed by something that's class
"refentrytitle".

Gotcha.

> 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.

Seems reasonable?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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(at)momjian(dot)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/8/17 12:50, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce(at)momjian(dot)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

On Tue, Apr 11, 2017 at 5:06 AM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 4/8/17 12:50, Robert Haas wrote:
> > On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian <bruce(at)momjian(dot)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.
>

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?

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

That part looks safer.

> 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.
>

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.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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

On Tue, Apr 11, 2017 at 4:30 PM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> 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.
>
>
Thanks, I've applied all three patches. Your version of the color patch
also seemed slightly more appropriate than Bruce's since it only hit the
docs.css and not the global css.

Once difference I notice is that for example the "note boxes" are no longer
centered, but they do now get the new formatting. Tables now look a lot
better.

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?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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(at)momjian(dot)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(at)momjian(dot)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 Sat, Apr 8, 2017 at 3:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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.
>
>

Applied, thanks.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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 9:36 PM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)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.
> >
> >
> >
> > Applied, thanks.
>
> Oops, one </style> too many.
>
>
Indeed. Fix pushed.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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(dot)eisentraut(at)2ndquadrant(dot)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(dot)eisentraut(at)2ndquadrant(dot)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