Thread: Problem with WIKI Contents links
I just noticed that some of the wiki page "Contents" headings are not clickable (no underline, no jumping to section on click), e.g.: 3 Functions4 Multi-Language Support6 SQL Commands15 Cache Usage I dumped the page to HTML and loading it manually and everything worked fine so there must be something beyond the HTML that is causing this. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > I just noticed that some of the wiki page "Contents" headings are not > clickable (no underline, no jumping to section on click), e.g.: > > 3 Functions > 4 Multi-Language Support > 6 SQL Commands > 15 Cache Usage > > I dumped the page to HTML and loading it manually and everything worked > fine so there must be something beyond the HTML that is causing this. Let me clarify, I am talking about the TODO Wiki: http://wiki.postgresql.org/wiki/Todo -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian escribió: > I just noticed that some of the wiki page "Contents" headings are not > clickable (no underline, no jumping to section on click), e.g.: > > 3 Functions > 4 Multi-Language Support > 6 SQL Commands > 15 Cache Usage > > I dumped the page to HTML and loading it manually and everything worked > fine so there must be something beyond the HTML that is causing this. I've seen this too. I think this is a browser bug. For example I notice that some links work fine on all the height of the font, but some others only work when I hover the pointer on a specific horizontal area (one pixel tall in some cases). Some others do not work at all, as you say. What's your browser? I use Epiphany (a Gecko derivate). In links (text mode browser) all the links seem to work fine. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > I just noticed that some of the wiki page "Contents" headings are not > > clickable (no underline, no jumping to section on click), e.g.: > > > > 3 Functions > > 4 Multi-Language Support > > 6 SQL Commands > > 15 Cache Usage > > > > I dumped the page to HTML and loading it manually and everything worked > > fine so there must be something beyond the HTML that is causing this. > > I've seen this too. I think this is a browser bug. For example I > notice that some links work fine on all the height of the font, but some > others only work when I hover the pointer on a specific horizontal area > (one pixel tall in some cases). Some others do not work at all, as you > say. > > What's your browser? I use Epiphany (a Gecko derivate). In links (text > mode browser) all the links seem to work fine. I am using Firefox 3. What is odd is that the HTML as a file works fine so I am betting there is some something outside the HTML file. I tried turning off Javascript but that didn't help. I am guessing Epiphany just doesn't support the feature that is causing the bug. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian escribió: > I am using Firefox 3. What is odd is that the HTML as a file works fine > so I am betting there is some something outside the HTML file. I tried > turning off Javascript but that didn't help. I am guessing Epiphany > just doesn't support the feature that is causing the bug. I assume you meant Links, not Epiphany. I said I can reproduce the problem with Epiphany, but not Links. I can reproduce it with SeaMonkey (Mozilla) too. I cannot reproduce it with IE6 either. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Sunday 07 December 2008 05:00:49 Alvaro Herrera wrote: > Bruce Momjian escribió: > > I just noticed that some of the wiki page "Contents" headings are not > > clickable (no underline, no jumping to section on click), e.g.: > > > > 3 Functions > > 4 Multi-Language Support > > 6 SQL Commands > > 15 Cache Usage > > > > I dumped the page to HTML and loading it manually and everything worked > > fine so there must be something beyond the HTML that is causing this. > > I've seen this too. I think this is a browser bug. For example I > notice that some links work fine on all the height of the font, but some > others only work when I hover the pointer on a specific horizontal area > (one pixel tall in some cases). Some others do not work at all, as you > say. I can reproduce it in variations with Konqueror and Iceweasel, but not with Opera. The W3C validator shows 2874 errors on that page, so we are lucky to see anything at all ...
Peter Eisentraut escribió: > The W3C validator shows 2874 errors on that page, so we are lucky to see > anything at all ... Apparently a lot of these are related to the fact that <dt> and <dd> are not closed in the TodoItemBase template. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Peter Eisentraut escribi?: > > > The W3C validator shows 2874 errors on that page, so we are lucky to see > > anything at all ... > > Apparently a lot of these are related to the fact that <dt> and <dd> are > not closed in the TodoItemBase template. Brendan, someone, can this be corrected? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, Jan 21, 2009 at 3:59 AM, Bruce Momjian <bruce@momjian.us> wrote: > Alvaro Herrera wrote: >> Apparently a lot of these are related to the fact that <dt> and <dd> are >> not closed in the TodoItemBase template. > > Brendan, someone, can this be corrected? It's possible. The <dt> and <dd> tags were an easy way to get the kind of layout I wanted (and they are appropriate semantic markup for TODO items), but because of some of the quirks of mediawiki, I wasn't able to close the tags in the normal way. It's less than ideal. Obviously producing bogus HTML isn't my idea of a good time, but when I put the TODO templates together it seemed to be the best of several poor alternatives. I suppose we could switch to using <div>s with style="..." attributes to control the layout, but the TODO already renders as a 53kB of HTML. It's quite heavy. Switching to <div> for the list items themselves will increase this substantially, which in turn increases load times and therefore reduces usability. Cheers, BJ
Bruce Momjian escribió: > Alvaro Herrera wrote: > > Peter Eisentraut escribi?: > > > > > The W3C validator shows 2874 errors on that page, so we are lucky to see > > > anything at all ... > > > > Apparently a lot of these are related to the fact that <dt> and <dd> are > > not closed in the TodoItemBase template. > > Brendan, someone, can this be corrected? FWIW I did a quick experiment the other day to add the </dd> and </dt> tags, but it resulted in the tags being displayed verbatim in the Todo page, so I reverted it. I figured it was safer to play on a local Mediawiki installation, but I don't have one so I left it at that. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Wed, 2009-01-21 at 06:37 +1100, Brendan Jurd wrote: > On Wed, Jan 21, 2009 at 3:59 AM, Bruce Momjian <bruce@momjian.us> wrote: > I suppose we could switch to using <div>s with style="..." attributes > to control the layout, but the TODO already renders as a 53kB of HTML. This is easily solved with mod_deflate I think. Are we running it on wiki? Any browser we should be supporting will support the compressed content. Joshua D. Drake -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Joshua D. Drake wrote: > On Wed, 2009-01-21 at 06:37 +1100, Brendan Jurd wrote: >> On Wed, Jan 21, 2009 at 3:59 AM, Bruce Momjian <bruce@momjian.us> wrote: > >> I suppose we could switch to using <div>s with style="..." attributes >> to control the layout, but the TODO already renders as a 53kB of HTML. > > This is easily solved with mod_deflate I think. Are we running it on > wiki? Any browser we should be supporting will support the compressed > content. mediawiki is using PHPs zlib support to automatically compress pages even if mod_deflate is not installed as long as the browser supports it. In this case the todo is actually ~400kB large and gets compressed down to ~50kB ... Stefan
On Tue, 2009-01-20 at 21:02 +0100, Stefan Kaltenbrunner wrote: > mediawiki is using PHPs zlib support to automatically compress pages > even if mod_deflate is not installed as long as the browser supports it. > In this case the todo is actually ~400kB large and gets compressed down > to ~50kB ... Heh o.k. :). Joshua D. Drake -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Stefan Kaltenbrunner escribió: > Joshua D. Drake wrote: >> On Wed, 2009-01-21 at 06:37 +1100, Brendan Jurd wrote: >>> On Wed, Jan 21, 2009 at 3:59 AM, Bruce Momjian <bruce@momjian.us> wrote: >> >>> I suppose we could switch to using <div>s with style="..." attributes >>> to control the layout, but the TODO already renders as a 53kB of HTML. >> >> This is easily solved with mod_deflate I think. Are we running it on >> wiki? Any browser we should be supporting will support the compressed >> content. > > mediawiki is using PHPs zlib support to automatically compress pages > even if mod_deflate is not installed as long as the browser supports it. > In this case the todo is actually ~400kB large and gets compressed down > to ~50kB ... So it comes down to adding a bunch of highly compressible tags ... probably not going to add a lot of extra download time (not sure about the extra render time). -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Stefan Kaltenbrunner escribi?: > > Joshua D. Drake wrote: > >> On Wed, 2009-01-21 at 06:37 +1100, Brendan Jurd wrote: > >>> On Wed, Jan 21, 2009 at 3:59 AM, Bruce Momjian <bruce@momjian.us> wrote: > >> > >>> I suppose we could switch to using <div>s with style="..." attributes > >>> to control the layout, but the TODO already renders as a 53kB of HTML. > >> > >> This is easily solved with mod_deflate I think. Are we running it on > >> wiki? Any browser we should be supporting will support the compressed > >> content. > > > > mediawiki is using PHPs zlib support to automatically compress pages > > even if mod_deflate is not installed as long as the browser supports it. > > In this case the todo is actually ~400kB large and gets compressed down > > to ~50kB ... > > So it comes down to adding a bunch of highly compressible tags ... > probably not going to add a lot of extra download time (not sure about > the extra render time). The big question is whether the additional close tags fix the problem with clicking on subsections at the top right of the wiki, e.g. "Functions"? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, Jan 21, 2009 at 8:52 AM, Bruce Momjian <bruce@momjian.us> wrote: > > The big question is whether the additional close tags fix the problem > with clicking on subsections at the top right of the wiki, e.g. > "Functions"? > Unknown. I have exactly zero idea what's causing the issue with the links in the TOC. Having a whole bunch of unclosed tags on the page might be the cause -- or it might be something else altogether. Cheers, BJ