On 2020-09-11 14:58, Fabien COELHO wrote:
On 2020-09-08 21:10, Bruce Momjian wrote:
I see this only applied to master. Shouldn't this be backpatched?
I wasn't planning to. It's not a bug fix.
Other thoughts?
Yep. ISTM nicer if all docs have the same navigation, especially as
googling
On 2020-09-08 21:10, Bruce Momjian wrote:
I see this only applied to master. Shouldn't this be backpatched?
I wasn't planning to. It's not a bug fix.
Other thoughts?
Yep. ISTM nicer if all docs have the same navigation, especially as
googling often points to random versions. No big
On 2020-09-08 21:10, Bruce Momjian wrote:
On Sun, Sep 6, 2020 at 04:59:11PM +0200, Peter Eisentraut wrote:
I have made the analogous changes to the footer as well and committed this.
I see this only applied to master. Shouldn't this be backpatched?
I wasn't planning to. It's not a bug
On Sun, Sep 6, 2020 at 04:59:11PM +0200, Peter Eisentraut wrote:
> On 2020-08-25 21:48, Bruce Momjian wrote:
> > On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote:
> > >
> > > Hello Peter,
> > >
> > > > The original stylesheets explicitly go out of their way to do it that
> > > >
On 2020-08-25 21:48, Bruce Momjian wrote:
On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote:
Hello Peter,
The original stylesheets explicitly go out of their way to do it that
way. We can easily fix that by removing that special case. See attached
patch.
That patch only fixes
On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote:
>
> Hello Peter,
>
> > The original stylesheets explicitly go out of their way to do it that
> > way. We can easily fix that by removing that special case. See attached
> > patch.
> >
> > That patch only fixes it for the header.
Hello Peter,
The original stylesheets explicitly go out of their way to do it that way.
We can easily fix that by removing that special case. See attached patch.
That patch only fixes it for the header. To fix it for the footer as well,
we'd first need to import the navfooter template to
The original stylesheets explicitly go out of their way to do it that
way.
Can we find any evidence of the reasoning? As you say, that clearly was
an intentional choice.
Given the code, my guess would be the well-intentioned but misplaced
desire to avoid a redundancy, i.e. two links
On 2020-Jul-03, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 2020-06-21 09:19, Fabien COELHO wrote:
> >> I've been annoyed that the documentation navigation does not always has an
> >> "Up" link. It has them inside parts, but the link disappears and you have
> >> to go for the "Home" link
Peter Eisentraut writes:
> On 2020-06-21 09:19, Fabien COELHO wrote:
>> I've been annoyed that the documentation navigation does not always has an
>> "Up" link. It has them inside parts, but the link disappears and you have
>> to go for the "Home" link which is far on the right when on the root
On 2020-06-21 09:19, Fabien COELHO wrote:
I've been annoyed that the documentation navigation does not always has an
"Up" link. It has them inside parts, but the link disappears and you have
to go for the "Home" link which is far on the right when on the root page
of a part?
Is there a good
On Sun, Jun 21, 2020 at 09:19:27AM +0200, Fabien COELHO wrote:
>
> Hello devs,
>
> I've been annoyed that the documentation navigation does not always has an
> "Up" link. It has them inside parts, but the link disappears and you have to
> go for the "Home" link which is far on the right when on
Hello devs,
I've been annoyed that the documentation navigation does not always has an
"Up" link. It has them inside parts, but the link disappears and you have
to go for the "Home" link which is far on the right when on the root page
of a part?
Is there a good reason not to have the "Up"
13 matches
Mail list logo
