Thread: Example indenting
I noticed that while the development docs indent examples (for example http://developer.postgresql.org/pgdocs/postgres/sql-explain.html), the main docs don't (http://www.postgresql.org/docs/9.0/static/sql-explain.html). As you can see, the same page on the main docs doesn't scan well, and all the examples and paragraphs merge into a tangled mess. Could someone update the main docs so it outputs a similar style to the dev docs? This will probably require changes to the actual docs to separate examples from other sections which share the same markup. Thanks -- Thom Brown Registered Linux user: #516935
Thom Brown <thom@linux.com> writes: > I noticed that while the development docs indent examples (for example > http://developer.postgresql.org/pgdocs/postgres/sql-explain.html), the > main docs don't > (http://www.postgresql.org/docs/9.0/static/sql-explain.html). I believe this isn't so much a function of the docs themselves as the webpage template they're being stuffed into on the latter site. Probably pgsql-www is the place to complain about it. > As you can see, the same page on the main docs doesn't scan well, and > all the examples and paragraphs merge into a tangled mess. Hm, both pages render acceptably for me in Safari --- it's true that the examples aren't inset relative to the text on the main-docs site, but I don't see anything "messed up" beyond that. What browser are you using? Could you post a screenshot of what you see? regards, tom lane
On mån, 2010-08-23 at 13:56 +0100, Thom Brown wrote: > Could someone update the main docs so it outputs a similar style to > the dev docs? This will probably require changes to the actual docs > to separate examples from other sections which share the same markup. I suspect that the docs on the web site don't use the CSS stylesheet that comes with the docs.
Thom Brown <thom@linux.com> writes:
> On 23 August 2010 14:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm, both pages render acceptably for me in Safari --- it's true that the
>> examples aren't inset relative to the text on the main-docs site, but
>> I don't see anything "messed up" beyond that. �What browser are you
>> using? �Could you post a screenshot of what you see?
> By "mess" I mean examples aren't sufficiently distinct from paragraph
> text. There's nothing actually malformed. It's more of a styling
> issue from my perspective.
Ah, I see. It looks like you are using a monospaced font that is
visually very similar to your regular text font, and so with neither
a font difference or insetting, there's indeed not a lot to distinguish
example from text. On my display the two fonts are a bit more visually
distinct so it's more readable. (Checks preferences ... I've got Safari
set to Times 16 for "standard font" and Courier 13 for "fixed-width
font", though I'm not sure whether the PG docs pages make use of those
selections.)
Anyway, that was a red herring, and the question remains why the
examples are rendered without insetting on the main docs pages.
Was that intentional? I can see that it might be because the text
is already inset from the window edge more than it is on the devel site,
and so insetting the examples even more might result in page width
problems. Maybe the problem is not so much that we want to indent the
examples more as that the text needs to be indented less.
regards, tom lane
On Mon, Aug 23, 2010 at 16:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 23 August 2010 14:43, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Hm, both pages render acceptably for me in Safari --- it's true that the >>> examples aren't inset relative to the text on the main-docs site, but >>> I don't see anything "messed up" beyond that. What browser are you >>> using? Could you post a screenshot of what you see? > >> By "mess" I mean examples aren't sufficiently distinct from paragraph >> text. There's nothing actually malformed. It's more of a styling >> issue from my perspective. > > Ah, I see. It looks like you are using a monospaced font that is > visually very similar to your regular text font, and so with neither > a font difference or insetting, there's indeed not a lot to distinguish > example from text. On my display the two fonts are a bit more visually > distinct so it's more readable. (Checks preferences ... I've got Safari > set to Times 16 for "standard font" and Courier 13 for "fixed-width > font", though I'm not sure whether the PG docs pages make use of those > selections.) > > Anyway, that was a red herring, and the question remains why the > examples are rendered without insetting on the main docs pages. > Was that intentional? I can see that it might be because the text > is already inset from the window edge more than it is on the devel site, > and so insetting the examples even more might result in page width > problems. Maybe the problem is not so much that we want to indent the > examples more as that the text needs to be indented less. Not having dug into any details, but it seems that example is tagged with CSS class PROGRAMLISTING - which isn't included anywhere in the main site CSS. Whereas on the developer site, tehre is a rule for it that gives margin-left: 4ex. Probably worth experimenting with that one. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 23 August 2010 15:37, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Aug 23, 2010 at 16:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thom Brown <thom@linux.com> writes:
>>> On 23 August 2010 14:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Hm, both pages render acceptably for me in Safari --- it's true that the
>>>> examples aren't inset relative to the text on the main-docs site, but
>>>> I don't see anything "messed up" beyond that. What browser are you
>>>> using? Could you post a screenshot of what you see?
>>
>>> By "mess" I mean examples aren't sufficiently distinct from paragraph
>>> text. There's nothing actually malformed. It's more of a styling
>>> issue from my perspective.
>>
>> Ah, I see. It looks like you are using a monospaced font that is
>> visually very similar to your regular text font, and so with neither
>> a font difference or insetting, there's indeed not a lot to distinguish
>> example from text. On my display the two fonts are a bit more visually
>> distinct so it's more readable. (Checks preferences ... I've got Safari
>> set to Times 16 for "standard font" and Courier 13 for "fixed-width
>> font", though I'm not sure whether the PG docs pages make use of those
>> selections.)
>>
>> Anyway, that was a red herring, and the question remains why the
>> examples are rendered without insetting on the main docs pages.
>> Was that intentional? I can see that it might be because the text
>> is already inset from the window edge more than it is on the devel site,
>> and so insetting the examples even more might result in page width
>> problems. Maybe the problem is not so much that we want to indent the
>> examples more as that the text needs to be indented less.
>
> Not having dug into any details, but it seems that example is tagged
> with CSS class PROGRAMLISTING - which isn't included anywhere in the
> main site CSS. Whereas on the developer site, tehre is a rule for it
> that gives margin-left: 4ex. Probably worth experimenting with that
> one.
>
Yes the following style is present in the dev docs, but not the www docs:
pre.LITERALLAYOUT,
.SCREEN,
.SYNOPSIS,
.PROGRAMLISTING
{
margin-left:4ex;
}
So as Peter said, the stylesheet in use isn't the same as the dev
version. Importing that one style into the www docs, it looks fine.
--
Thom Brown
Registered Linux user: #516935
On 24 August 2010 15:44, Thom Brown <thom@linux.com> wrote:
> On 24 August 2010 09:35, Thom Brown <thom@linux.com> wrote:
>> On 23 August 2010 16:09, Thom Brown <thom@linux.com> wrote:
>>> On 23 August 2010 15:37, Magnus Hagander <magnus@hagander.net> wrote:
>>>> On Mon, Aug 23, 2010 at 16:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>> Thom Brown <thom@linux.com> writes:
>>>>>> On 23 August 2010 14:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>>>> Hm, both pages render acceptably for me in Safari --- it's true that the
>>>>>>> examples aren't inset relative to the text on the main-docs site, but
>>>>>>> I don't see anything "messed up" beyond that. What browser are you
>>>>>>> using? Could you post a screenshot of what you see?
>>>>>
>>>>>> By "mess" I mean examples aren't sufficiently distinct from paragraph
>>>>>> text. There's nothing actually malformed. It's more of a styling
>>>>>> issue from my perspective.
>>>>>
>>>>> Ah, I see. It looks like you are using a monospaced font that is
>>>>> visually very similar to your regular text font, and so with neither
>>>>> a font difference or insetting, there's indeed not a lot to distinguish
>>>>> example from text. On my display the two fonts are a bit more visually
>>>>> distinct so it's more readable. (Checks preferences ... I've got Safari
>>>>> set to Times 16 for "standard font" and Courier 13 for "fixed-width
>>>>> font", though I'm not sure whether the PG docs pages make use of those
>>>>> selections.)
>>>>>
>>>>> Anyway, that was a red herring, and the question remains why the
>>>>> examples are rendered without insetting on the main docs pages.
>>>>> Was that intentional? I can see that it might be because the text
>>>>> is already inset from the window edge more than it is on the devel site,
>>>>> and so insetting the examples even more might result in page width
>>>>> problems. Maybe the problem is not so much that we want to indent the
>>>>> examples more as that the text needs to be indented less.
>>>>
>>>> Not having dug into any details, but it seems that example is tagged
>>>> with CSS class PROGRAMLISTING - which isn't included anywhere in the
>>>> main site CSS. Whereas on the developer site, tehre is a rule for it
>>>> that gives margin-left: 4ex. Probably worth experimenting with that
>>>> one.
>>>>
>>>
>>> Yes the following style is present in the dev docs, but not the www docs:
>>>
>>> pre.LITERALLAYOUT,
>>> .SCREEN,
>>> .SYNOPSIS,
>>> .PROGRAMLISTING
>>> {
>>> margin-left:4ex;
>>> }
>>>
>>> So as Peter said, the stylesheet in use isn't the same as the dev
>>> version. Importing that one style into the www docs, it looks fine.
>>>
>>
>> Just as a quick test, I also tried out applying a style which clearly
>> defines these sections. I attach an example of how this transforms
>> the page (and how it looks without any style changes). Just an idea.
>>
>> The style applied here is:
>>
>> pre.LITERALLAYOUT,
>> .SCREEN,
>> .SYNOPSIS,
>> .PROGRAMLISTING
>> {
>> margin: 0 4ex;
>> padding: 2ex 4ex;
>> border-left: 4px solid #008EBD;
>> background-color: #E0ECEF;
>> }
>
> And this is possibly overkill, but the following CSS results in the
> attached screenshot:
>
> pre.LITERALLAYOUT,
> .SCREEN,
> .SYNOPSIS,
> .PROGRAMLISTING
> {
> margin: 0 4ex;
> padding: 2ex 4ex;
> }
>
> pre.LITERALLAYOUT,
> .SCREEN
> {
> border-left: 4px solid #DFA60D;
> background-color: #FFFCDF;
>
> }
>
> pre.SYNOPSIS
> {
> border-left: 4px solid #AFAFAF;
> background-color: #EFEFEF;
> }
>
> pre.PROGRAMLISTING
> {
> border-left: 4px solid #008EBD;
> background-color: #E0ECEF;
> }
>
> It makes a visual distinction between examples, definitions and actual
> terminal output.
And another prototype:
http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/
(not attached because the messages don't come through otherwise)
..(and this time really without the attachment)
--
Thom Brown
Registered Linux user: #516935
Thom Brown <thom@linux.com> wrote: > And another prototype: > http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ Wow! That looks *really* slick! That is much more readable than what I'm used to seeing! -Kevin
On Wed, 2010-08-25 at 17:51 -0500, Kevin Grittner wrote: > Thom Brown <thom@linux.com> wrote: > > > And another prototype: > > http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ > > Wow! That looks *really* slick! > > That is much more readable than what I'm used to seeing! Wait, what? Were going to have documentation that is representative of someone who has designed a web page circa 2005? WOOT! Seriously, +1. Very nice work. Joshua D. Drake > > -Kevin > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Le 26/08/2010 01:29, Joshua D. Drake a écrit : > On Wed, 2010-08-25 at 17:51 -0500, Kevin Grittner wrote: >> Thom Brown <thom@linux.com> wrote: >> >>> And another prototype: >>> http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ >> >> Wow! That looks *really* slick! >> >> That is much more readable than what I'm used to seeing! > > Wait, what? Were going to have documentation that is representative of > someone who has designed a web page circa 2005? WOOT! > > Seriously, +1. Very nice work. > Yeah, quite impressive. Would love to know how Thom did that. And if I can borrow it for the french translation of the manual :) -- Guillaume http://www.postgresql.fr http://dalibo.com
On Wed, 2010-08-25 at 17:51 -0500, Kevin Grittner wrote: > Thom Brown <thom@linux.com> wrote: > > > And another prototype: > > http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ > > Wow! That looks *really* slick! > > That is much more readable than what I'm used to seeing! Wait, what? Were going to have documentation that is representative of someone who has designed a web page circa 2005? WOOT! Seriously, +1. Very nice work. Joshua D. Drake > > -Kevin > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 26 August 2010 06:52, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 26/08/2010 01:29, Joshua D. Drake a écrit : >> On Wed, 2010-08-25 at 17:51 -0500, Kevin Grittner wrote: >>> Thom Brown <thom@linux.com> wrote: >>> >>>> And another prototype: >>>> http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ >>> >>> Wow! That looks *really* slick! >>> >>> That is much more readable than what I'm used to seeing! >> >> Wait, what? Were going to have documentation that is representative of >> someone who has designed a web page circa 2005? WOOT! >> >> Seriously, +1. Very nice work. >> > > Yeah, quite impressive. Would love to know how Thom did that. And if I > can borrow it for the french translation of the manual :) Thanks, although I'm worried it's a bit too distracting. I got a bit carried away as originally it was only to make the documentation more readable, so if these changes make it less functional, it doesn't really matter if it looks good or not. It also happens to show up mistakes in the documentation markup on some pages, so if any similar sort of cosmetic changes were to take place, they may have to come after fixes to the SGML. But I've left the CSS additions in a comment on the Flickr page: http://www.flickr.com/photos/dark_ixion/4927669444/ Just looked at the French documentation for the first time and it shocked at how similar my changes are. :O I wasn't aware the French docs looked any different to the English ones. -- Thom Brown Registered Linux user: #516935
On Thu, Aug 26, 2010 at 09:03, Thom Brown <thom@linux.com> wrote: > On 26 August 2010 06:52, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> Le 26/08/2010 01:29, Joshua D. Drake a écrit : >>> On Wed, 2010-08-25 at 17:51 -0500, Kevin Grittner wrote: >>>> Thom Brown <thom@linux.com> wrote: >>>> >>>>> And another prototype: >>>>> http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ >>>> >>>> Wow! That looks *really* slick! >>>> >>>> That is much more readable than what I'm used to seeing! >>> >>> Wait, what? Were going to have documentation that is representative of >>> someone who has designed a web page circa 2005? WOOT! >>> >>> Seriously, +1. Very nice work. >>> >> >> Yeah, quite impressive. Would love to know how Thom did that. And if I >> can borrow it for the french translation of the manual :) > > Thanks, although I'm worried it's a bit too distracting. I got a bit > carried away as originally it was only to make the documentation more > readable, so if these changes make it less functional, it doesn't > really matter if it looks good or not. It also happens to show up > mistakes in the documentation markup on some pages, so if any similar > sort of cosmetic changes were to take place, they may have to come > after fixes to the SGML. > > But I've left the CSS additions in a comment on the Flickr page: > http://www.flickr.com/photos/dark_ixion/4927669444/ > > Just looked at the French documentation for the first time and it > shocked at how similar my changes are. :O I wasn't aware the French > docs looked any different to the English ones. Thanks, Thom, this is great work. And just FYI to everybody else, I've tried Thom into the task of structuring our CSS a bit more, so that we can apply this without risk ;) Thom - there you go, now it's public, there's no backing down now :P -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 26 August 2010 13:11, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Aug 26, 2010 at 09:03, Thom Brown <thom@linux.com> wrote: >> On 26 August 2010 06:52, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>> Le 26/08/2010 01:29, Joshua D. Drake a écrit : >>>> On Wed, 2010-08-25 at 17:51 -0500, Kevin Grittner wrote: >>>>> Thom Brown <thom@linux.com> wrote: >>>>> >>>>>> And another prototype: >>>>>> http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ >>>>> >>>>> Wow! That looks *really* slick! >>>>> >>>>> That is much more readable than what I'm used to seeing! >>>> >>>> Wait, what? Were going to have documentation that is representative of >>>> someone who has designed a web page circa 2005? WOOT! >>>> >>>> Seriously, +1. Very nice work. >>>> >>> >>> Yeah, quite impressive. Would love to know how Thom did that. And if I >>> can borrow it for the french translation of the manual :) >> >> Thanks, although I'm worried it's a bit too distracting. I got a bit >> carried away as originally it was only to make the documentation more >> readable, so if these changes make it less functional, it doesn't >> really matter if it looks good or not. It also happens to show up >> mistakes in the documentation markup on some pages, so if any similar >> sort of cosmetic changes were to take place, they may have to come >> after fixes to the SGML. >> >> But I've left the CSS additions in a comment on the Flickr page: >> http://www.flickr.com/photos/dark_ixion/4927669444/ >> >> Just looked at the French documentation for the first time and it >> shocked at how similar my changes are. :O I wasn't aware the French >> docs looked any different to the English ones. > > Thanks, Thom, this is great work. > > And just FYI to everybody else, I've tried Thom into the task of > structuring our CSS a bit more, so that we can apply this without risk > ;) > > Thom - there you go, now it's public, there's no backing down now :P > Looks like the webkit rendering engine can't deal with rounded corners neatly where the borders are different widths so got rid of the left-hand border-width. Did a little bit more today: http://www.flickr.com/photos/dark_ixion/4929208375/sizes/o/ And I get to play with stuff on Github which I'm new to :) -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Thu, 2010-08-26 at 17:28 +0100, Thom Brown wrote: > > Looks like the webkit rendering engine can't deal with rounded corners > neatly where the borders are different widths so got rid of the > left-hand border-width. did you use --webkit-border-radius > > Did a little bit more today: > http://www.flickr.com/photos/dark_ixion/4929208375/sizes/o/ > > And I get to play with stuff on Github which I'm new to :) > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, 2010-08-26 at 08:03 +0100, Thom Brown wrote: > > Yeah, quite impressive. Would love to know how Thom did that. And if I > > can borrow it for the french translation of the manual :) > > Thanks, although I'm worried it's a bit too distracting. I got a bit > carried away as originally it was only to make the documentation more > readable, so if these changes make it less functional, it doesn't > really matter if it looks good or not. I would consider two things since we are talking documentation. 1. Drop the shadow 2. Keep the sizes consistent on the borders (notably the left side) It is great for it to be aesthetically pleasing but if we have those minor inconsistencies I think it would be distracting from the information itself. Otherwise, I think it is a bang up job. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 26 August 2010 18:03, Joshua D. Drake <jd@commandprompt.com> wrote: > On Thu, 2010-08-26 at 08:03 +0100, Thom Brown wrote: > >> > Yeah, quite impressive. Would love to know how Thom did that. And if I >> > can borrow it for the french translation of the manual :) >> >> Thanks, although I'm worried it's a bit too distracting. I got a bit >> carried away as originally it was only to make the documentation more >> readable, so if these changes make it less functional, it doesn't >> really matter if it looks good or not. > > I would consider two things since we are talking documentation. > > 1. Drop the shadow Okay. > 2. Keep the sizes consistent on the borders (notably the left side) All borders in the updated image are identical. > It is great for it to be aesthetically pleasing but if we have those > minor inconsistencies I think it would be distracting from the > information itself. Agreed, and it's sort of experimental at the moment. If it doesn't help present information better, it's useless really. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 26 August 2010 18:00, Joshua D. Drake <jd@commandprompt.com> wrote: > On Thu, 2010-08-26 at 17:28 +0100, Thom Brown wrote: > >> >> Looks like the webkit rendering engine can't deal with rounded corners >> neatly where the borders are different widths so got rid of the >> left-hand border-width. > > did you use --webkit-border-radius > Yes, although that's not the issue. It's where the width of two perpendicular borders differ, the corner goes a bit weird in webkit engines, so I just dropped the varying widths. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> wrote: > Joshua D. Drake <jd@commandprompt.com> wrote: >> It is great for it to be aesthetically pleasing but if we have >> those minor inconsistencies I think it would be distracting from >> the information itself. > > Agreed, and it's sort of experimental at the moment. If it > doesn't help present information better, it's useless really. I know this sort of thing gets pretty subjective, but having gone back and looked at it a couple times... (1) I don't find the shadows distracting, but I can see where that could be a factor for some -- if it distracts anybody, I won't miss them too much. (2) The one thing I *do* find distracting is the wide separation in the colors used for the different boxes (grey, yellow, blue, red). I like the warning to stand out with red, but if the others were somewhat more subtle differences, I think it would be less jarring and distracting. You know, enough that you can tell the difference if you're looking for it, and enough to register subliminally, but not enough to slap you upside the head. Hmmm... Does that qualify as bikeshedding? -Kevin
On 26 August 2010 18:23, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: >> Joshua D. Drake <jd@commandprompt.com> wrote: > >>> It is great for it to be aesthetically pleasing but if we have >>> those minor inconsistencies I think it would be distracting from >>> the information itself. >> >> Agreed, and it's sort of experimental at the moment. If it >> doesn't help present information better, it's useless really. > > I know this sort of thing gets pretty subjective, but having gone > back and looked at it a couple times... > > (1) I don't find the shadows distracting, but I can see where that > could be a factor for some -- if it distracts anybody, I won't miss > them too much. > > (2) The one thing I *do* find distracting is the wide separation in > the colors used for the different boxes (grey, yellow, blue, red). > I like the warning to stand out with red, but if the others were > somewhat more subtle differences, I think it would be less jarring > and distracting. You know, enough that you can tell the difference > if you're looking for it, and enough to register subliminally, but > not enough to slap you upside the head. > I agree with this too and I'll work on making sure things look more consistent. I'll just have to think about how to make the differences clear without random splashes of colour on the page. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown wrote: > > Thom - there you go, now it's public, there's no backing down now :P > > > > Looks like the webkit rendering engine can't deal with rounded corners > neatly where the borders are different widths so got rid of the > left-hand border-width. > > Did a little bit more today: > http://www.flickr.com/photos/dark_ixion/4929208375/sizes/o/ > > And I get to play with stuff on Github which I'm new to :) That really pumps up the appearance of our docs! -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, 2010-08-26 at 18:27 +0100, Thom Brown wrote: > I agree with this too and I'll work on making sure things look more > consistent. I'll just have to think about how to make the differences > clear without random splashes of colour on the page. blues and greys are going to be easier on the eyes for a long read. The red is obviously great. Joshua D. Drake > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, 2010-08-26 at 17:28 +0100, Thom Brown wrote: > > Looks like the webkit rendering engine can't deal with rounded corners > neatly where the borders are different widths so got rid of the > left-hand border-width. did you use --webkit-border-radius > > Did a little bit more today: > http://www.flickr.com/photos/dark_ixion/4929208375/sizes/o/ > > And I get to play with stuff on Github which I'm new to :) > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, 2010-08-26 at 08:03 +0100, Thom Brown wrote: > > Yeah, quite impressive. Would love to know how Thom did that. And if I > > can borrow it for the french translation of the manual :) > > Thanks, although I'm worried it's a bit too distracting. I got a bit > carried away as originally it was only to make the documentation more > readable, so if these changes make it less functional, it doesn't > really matter if it looks good or not. I would consider two things since we are talking documentation. 1. Drop the shadow 2. Keep the sizes consistent on the borders (notably the left side) It is great for it to be aesthetically pleasing but if we have those minor inconsistencies I think it would be distracting from the information itself. Otherwise, I think it is a bang up job. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Thu, 2010-08-26 at 18:27 +0100, Thom Brown wrote: > I agree with this too and I'll work on making sure things look more > consistent. I'll just have to think about how to make the differences > clear without random splashes of colour on the page. blues and greys are going to be easier on the eyes for a long read. The red is obviously great. Joshua D. Drake > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 26 August 2010 18:44, Joshua D. Drake <jd@commandprompt.com> wrote: > On Thu, 2010-08-26 at 18:27 +0100, Thom Brown wrote: > >> I agree with this too and I'll work on making sure things look more >> consistent. I'll just have to think about how to make the differences >> clear without random splashes of colour on the page. > > blues and greys are going to be easier on the eyes for a long read. The > red is obviously great. > > Joshua D. Drake > Okay, got rid of all the shadows, rounded corners etc and made some other changes: http://www.flickr.com/photos/dark_ixion/4932396780/sizes/o/ -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 27 August 2010 16:46, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: > >> Okay, got rid of all the shadows, rounded corners etc and made >> some other changes: >> http://www.flickr.com/photos/dark_ixion/4932396780/sizes/o/ > > I generally liked the rounded corners. The tables near the front > are probably better off without them, but I would rather see rounded > corners on the rest. I know someone said the shadows were > distracting, but I don't remember any complaints about the > corners. Did I miss or forget something? The reason I removed the corners is that they can't be applied to a warning or caution box using their current markup (as the background pushes beyond the rounded corner), and when they appear near a normal rounded-corner box, it might look a bit inconsistent (same but with rounded corners): http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ Hmmm.. although looking at it again, maybe it doesn't. I dunno. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Fri, 2010-08-27 at 10:46 -0500, Kevin Grittner wrote: > Thom Brown <thom@linux.com> wrote: > > > Okay, got rid of all the shadows, rounded corners etc and made > > some other changes: > > http://www.flickr.com/photos/dark_ixion/4932396780/sizes/o/ > > I generally liked the rounded corners. As did I. > The tables near the front > are probably better off without them, but I would rather see rounded > corners on the rest. +1 Also for a community that had ugly docs and recently spent a lot of time making them pretty, take a look at python. http://docs.python.org/using/cmdline.html#options-you-shouldn-t-use Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Thom Brown <thom@linux.com> wrote: > Okay, got rid of all the shadows, rounded corners etc and made > some other changes: > http://www.flickr.com/photos/dark_ixion/4932396780/sizes/o/ I generally liked the rounded corners. The tables near the front are probably better off without them, but I would rather see rounded corners on the rest. I know someone said the shadows were distracting, but I don't remember any complaints about the corners. Did I miss or forget something? -Kevin
Thom Brown <thom@linux.com> wrote: > The reason I removed the corners is that they can't be applied to > a warning or caution box using their current markup (as the > background pushes beyond the rounded corner), and when they appear > near a normal rounded-corner box, it might look a bit inconsistent > (same but with rounded corners): > http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ > > Hmmm.. although looking at it again, maybe it doesn't. I dunno. That looks better to my eye -- square corners on a page with that many boxes for code start to look pretty harsh, to the point of being a bit jarring. The round corners soften that for me, and make it easier to look at. (I don't know how widespread that reaction is, though.) -Kevin
On 27 August 2010 17:10, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: > >> The reason I removed the corners is that they can't be applied to >> a warning or caution box using their current markup (as the >> background pushes beyond the rounded corner), and when they appear >> near a normal rounded-corner box, it might look a bit inconsistent >> (same but with rounded corners): >> http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ >> >> Hmmm.. although looking at it again, maybe it doesn't. I dunno. > > That looks better to my eye -- square corners on a page with that > many boxes for code start to look pretty harsh, to the point of > being a bit jarring. The round corners soften that for me, and make > it easier to look at. (I don't know how widespread that reaction > is, though.) > Something I've noticed is an inconsistency in the SGML markup around functions listed in tables. Sometimes the entire function signature is considered to be the function, and other times it's just the function name, with its parameters outside of the <function> tags. E.g.: <function>variance</function>(<replaceable class="parameter">expression</replaceable>) vs <function>stddev_samp(<replaceable class="parameter">expression</replaceable>)</function> Which way is correct? It will make a big difference visually with these changes. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Fri, 2010-08-27 at 18:04 +0100, Thom Brown wrote: > Something I've noticed is an inconsistency in the SGML markup around > functions listed in tables. Sometimes the entire function signature > is considered to be the function, and other times it's just the > function name, with its parameters outside of the <function> tags. > > E.g.: > > <function>variance</function>(<replaceable > class="parameter">expression</replaceable>) > > vs > > <function>stddev_samp(<replaceable > class="parameter">expression</replaceable>)</function> > > Which way is correct? It will make a big difference visually with > these changes. That is actually a question for pgsql-docs. Joshua D. Drake > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
>>> http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ FWIW, I like the changes to the tables, but I do dislike both boxes *and* background-coloring of both <synopsis> and <screen> (=code examples). To my eyes the changed font is enough for both <synopsis> and <screen>. OTOH, I mainly use the .pdf version of the documentation; and I suppose the changes so far are all CSS-only (i.e. no effect on the PDF)? sorry if I sound negative... Erik Rijkers
On Fri, 2010-08-27 at 10:46 -0500, Kevin Grittner wrote: > Thom Brown <thom@linux.com> wrote: > > > Okay, got rid of all the shadows, rounded corners etc and made > > some other changes: > > http://www.flickr.com/photos/dark_ixion/4932396780/sizes/o/ > > I generally liked the rounded corners. As did I. > The tables near the front > are probably better off without them, but I would rather see rounded > corners on the rest. +1 Also for a community that had ugly docs and recently spent a lot of time making them pretty, take a look at python. http://docs.python.org/using/cmdline.html#options-you-shouldn-t-use Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Fri, 2010-08-27 at 18:04 +0100, Thom Brown wrote: > Something I've noticed is an inconsistency in the SGML markup around > functions listed in tables. Sometimes the entire function signature > is considered to be the function, and other times it's just the > function name, with its parameters outside of the <function> tags. > > E.g.: > > <function>variance</function>(<replaceable > class="parameter">expression</replaceable>) > > vs > > <function>stddev_samp(<replaceable > class="parameter">expression</replaceable>)</function> > > Which way is correct? It will make a big difference visually with > these changes. That is actually a question for pgsql-docs. Joshua D. Drake > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 27 August 2010 20:23, Erik Rijkers <er@xs4all.nl> wrote: >>>> http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ > > FWIW, I like the changes to the tables, but I do dislike both boxes *and* background-coloring of > both <synopsis> and <screen> (=code examples). To my eyes the changed font is enough for both > <synopsis> and <screen>. > > OTOH, I mainly use the .pdf version of the documentation; and I suppose the changes so far are all > CSS-only (i.e. no effect on the PDF)? > > sorry if I sound negative... > I don't think it will have any bearing on the PDF. Okay, I've made some more changes, and hopefully they're a bit more logical now. blue boxes - definitions grey boxes - examples, output etc red boxes - warnings, cautions yellow boxes - notes The yellow and red ones don't often occur, and the reason why I keep providing screenshots of the same page is because it's the only page in the documentation which contains one of each type of element. So here's the updated one: http://www.flickr.com/photos/dark_ixion/4935126375/sizes/o/ Unfortunately the tool I'm using to grab the whole page screenshot uses jpeg compression, but saves as PNG, which I then reduce the palette on to shrink the file size, so the colours are a bit off and the text looks a bit fuzzy. Are the boxes really that distracting? How about if I remove the border and just have a light background? The problem with relying on font difference is that it's not the same on every platform, hence why this all started. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 28 August 2010 20:53, Thom Brown <thom@linux.com> wrote: > On 27 August 2010 20:23, Erik Rijkers <er@xs4all.nl> wrote: >>>>> http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ >> >> FWIW, I like the changes to the tables, but I do dislike both boxes *and* background-coloring of >> both <synopsis> and <screen> (=code examples). To my eyes the changed font is enough for both >> <synopsis> and <screen>. >> >> OTOH, I mainly use the .pdf version of the documentation; and I suppose the changes so far are all >> CSS-only (i.e. no effect on the PDF)? >> >> sorry if I sound negative... >> > > I don't think it will have any bearing on the PDF. > > Okay, I've made some more changes, and hopefully they're a bit more logical now. > > blue boxes - definitions > grey boxes - examples, output etc > red boxes - warnings, cautions > yellow boxes - notes > > The yellow and red ones don't often occur, and the reason why I keep > providing screenshots of the same page is because it's the only page > in the documentation which contains one of each type of element. > > So here's the updated one: > http://www.flickr.com/photos/dark_ixion/4935126375/sizes/o/ > > Unfortunately the tool I'm using to grab the whole page screenshot > uses jpeg compression, but saves as PNG, which I then reduce the > palette on to shrink the file size, so the colours are a bit off and > the text looks a bit fuzzy. > > Are the boxes really that distracting? How about if I remove the > border and just have a light background? The problem with relying on > font difference is that it's not the same on every platform, hence why > this all started. > Modified without borders on boxes: http://www.flickr.com/photos/dark_ixion/4935194179/sizes/o/ -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 29 August 2010 08:39, Dave Page <dpage@pgadmin.org> wrote: > On Sat, Aug 28, 2010 at 9:08 PM, Thom Brown <thom@linux.com> wrote: >> >> > Are the boxes really that distracting? How about if I remove the >> > border and just have a light background? The problem with relying on >> > font difference is that it's not the same on every platform, hence why >> > this all started. >> > >> >> Modified without borders on boxes: >> http://www.flickr.com/photos/dark_ixion/4935194179/sizes/o/ > > I definitely prefer with the borders (frankly I thought it looked even > better with the shadows too). > > The grey text on light blue/grey boxes should be fixed though - that's > a potential accessibility issue due to the lack of contrast. > Okay, as per Robert's suggestion, I've changed all example/definition/synopsis boxes to grey, and followed Dave's suggestion of restoring borders and making the default text colour black for all boxed content. Bear in mind the rubbish screenshot app I'm using heavily compresses the image, so elements aren't appearing as clear as they should do. http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/ -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Sat, Aug 28, 2010 at 9:08 PM, Thom Brown <thom@linux.com> wrote: > > > Are the boxes really that distracting? How about if I remove the > > border and just have a light background? The problem with relying on > > font difference is that it's not the same on every platform, hence why > > this all started. > > > > Modified without borders on boxes: > http://www.flickr.com/photos/dark_ixion/4935194179/sizes/o/ I definitely prefer with the borders (frankly I thought it looked even better with the shadows too). The grey text on light blue/grey boxes should be fixed though - that's a potential accessibility issue due to the lack of contrast. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Sat, Aug 28, 2010 at 3:53 PM, Thom Brown <thom@linux.com> wrote: > blue boxes - definitions > grey boxes - examples, output etc > red boxes - warnings, cautions > yellow boxes - notes I think yellow notes and red warnings are good, but I wonder if definitions should get the same markup as examples, output, etc. It's not too intuitive what the distinction is, at least not to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Thom Brown <thom@linux.com> wrote: > Okay, as per Robert's suggestion, I've changed all > example/definition/synopsis boxes to grey, and followed Dave's > suggestion of restoring borders and making the default text colour > black for all boxed content. Bear in mind the rubbish screenshot > app I'm using heavily compresses the image, so elements aren't > appearing as clear as they should do. > > http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/ For me, that's the easiest to read so far. With a lot of the other distractions cleaned up, I wonder if it's worth throwing another version up with subtle shadows on the boxes which have rounded corners. I think that glitzes things up enough to make it more pleasing visually, without really distracting me. Of course if its distracting enough for anyone to annoy or detract from usability then they don't belong -- I just wonder if they might have previously been seen as distracting largely because of they were next to all those eye-grabbing colors.... -Kevin
On 08/29/2010 03:56 AM, Thom Brown wrote: > Okay, as per Robert's suggestion, I've changed all > example/definition/synopsis boxes to grey, and followed Dave's > suggestion of restoring borders and making the default text colour > black for all boxed content. Bear in mind the rubbish screenshot app > I'm using heavily compresses the image, so elements aren't appearing > as clear as they should do. > > http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/ +1 I really like this version. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support
Attachment
Thom Brown <thom@linux.com> wrote: > The only change is the addition of very light shadowing (for Dave > and Kevin) Sorry for sounding picky, but can the shadowing be even lighter? It seems a tad heavy next to the light gray in the boxes. -Kevin
On 29 August 2010 17:28, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Thom Brown <thom@linux.com> wrote: >>> http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/ > >> For me, that's the easiest to read so far. With a lot of the other >> distractions cleaned up, I wonder if it's worth throwing another >> version up with subtle shadows on the boxes which have rounded >> corners. I think that glitzes things up enough to make it more >> pleasing visually, without really distracting me. Of course if its >> distracting enough for anyone to annoy or detract from usability >> then they don't belong -- I just wonder if they might have >> previously been seen as distracting largely because of they were >> next to all those eye-grabbing colors.... > > The yellow "note" boxes still strike me as too eye-grabbing for > their purpose. Otherwise this version seems nice. > > regards, tom lane New version. http://www.flickr.com/photos/dark_ixion/4938452850/sizes/o/ The only change is the addition of very light shadowing (for Dave and Kevin), and done on my fella's Mac (yes, I washed my hands after) where Screengrab actually works so no compression or weird colour-bleeding/shifting issues :) As for the notes being too distracting, I'll work on getting those more subdued. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Tom Lane <tgl@sss.pgh.pa.us> wrote: > The yellow "note" boxes still strike me as too eye-grabbing for > their purpose. Otherwise this version seems nice. How about a color which still differentiates these without being quite so bold -- like Beige (#F5F5DC)? For an example, see: http://en.wikipedia.org/wiki/Beige (What *don't* they have?) -Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > Thom Brown <thom@linux.com> wrote: >> http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/ > For me, that's the easiest to read so far. With a lot of the other > distractions cleaned up, I wonder if it's worth throwing another > version up with subtle shadows on the boxes which have rounded > corners. I think that glitzes things up enough to make it more > pleasing visually, without really distracting me. Of course if its > distracting enough for anyone to annoy or detract from usability > then they don't belong -- I just wonder if they might have > previously been seen as distracting largely because of they were > next to all those eye-grabbing colors.... The yellow "note" boxes still strike me as too eye-grabbing for their purpose. Otherwise this version seems nice. regards, tom lane
On 29 August 2010 17:46, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: > >> The only change is the addition of very light shadowing (for Dave >> and Kevin) > > Sorry for sounding picky, but can the shadowing be even lighter? It > seems a tad heavy next to the light gray in the boxes. Okay, I've stopped using screenshots and now put up a more useful version up: http://pgweb.darkixion.com:8081/docs/8.4/static/functions-datetime.html So you can check out other pages, and at your own screen size. And Kevin, I made the shadows a bit lighter in this version and used the beige notes box. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 29 August 2010 20:02, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: >> Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > >>> The rounded corners and shadows aren't showing up in Konqueror > >> Okay, it appears there's also a KHTML engine setting for pre-CSS3 >> support. I've added that in now for rounded corners and shadows. >> Any different? > > Konqueror now shows rounded corners but no shadows. Okay, I've made a couple other changes, but if it's not working now, I don't think it's supported. This page suggests that box-shadow isn't yet supported by KHTML: http://www.legendscrolls.co.uk/webstandards/khtml I've just tested it in Opera, and CSS as it is causes massive jumps in font size for some elements, so I'll need to fix those too. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> wrote: > Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> The rounded corners and shadows aren't showing up in Konqueror > Okay, it appears there's also a KHTML engine setting for pre-CSS3 > support. I've added that in now for rounded corners and shadows. > Any different? Konqueror now shows rounded corners but no shadows. (As you probably expected, no change in Firefox.) -Kevin
Thom Brown <thom@linux.com> wrote: > And Kevin, I made the shadows a bit lighter in this version and > used the beige notes box. For my taste, that's perfect. (Now there's the trivial matter of making everyone else happy. ;-) ) The rounded corners and shadows aren't showing up in Konqueror, but everything still looks great there -- just not a jazzy as it does in Firefox. This seems to me to be a very professional, attractive presentation. Outstanding work! -Kevin
On 29 August 2010 19:39, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: > >> And Kevin, I made the shadows a bit lighter in this version and >> used the beige notes box. > > For my taste, that's perfect. (Now there's the trivial matter of > making everyone else happy. ;-) ) > > The rounded corners and shadows aren't showing up in Konqueror, but > everything still looks great there -- just not a jazzy as it does in > Firefox. This seems to me to be a very professional, attractive > presentation. Okay, it appears there's also a KHTML engine setting for pre-CSS3 support. I've added that in now for rounded corners and shadows. Any different? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> wrote: > Okay, I've made a couple other changes, but if it's not working > now, I don't think it's supported. This page suggests that > box-shadow isn't yet supported by KHTML: > http://www.legendscrolls.co.uk/webstandards/khtml No shadows in Konqueror. > I've just tested it in Opera, and CSS as it is causes massive > jumps in font size for some elements, so I'll need to fix those > too. Now that you mention it, there are some large fonts for some elements in Konqueror, too. I'll check that after you fix it for Opera. -Kevin
Excerpts from Thom Brown's message of dom ago 29 14:56:47 -0400 2010: > Okay, it appears there's also a KHTML engine setting for pre-CSS3 > support. I've added that in now for rounded corners and shadows. Any > different? You know you can try these things in http://browsershots.org, right? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 30 August 2010 18:09, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Thom Brown's message of dom ago 29 14:56:47 -0400 2010: > >> Okay, it appears there's also a KHTML engine setting for pre-CSS3 >> support. I've added that in now for rounded corners and shadows. Any >> different? > > You know you can try these things in http://browsershots.org, right? Yes, but they're very slow and very unreliable unfortunately. :( -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
> On 31 August 2010 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thom Brown <thom@linux.com> writes:
>>> Now the font sizes should be virtually the same in all browsers.
>>
>> That seems pretty unfriendly from an accessibility standpoint.
> Maybe, but the only alternative is to copy the current site's javascript hack.
There's a reason why it was done that way before ...
regards, tom lane
On 31 August 2010 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> Well that was a pain. Didn't realise there was a special hacky CSS >> file to fix fonts for gecko and webkit browsers. We use javascript to >> add it in on the current documentation, which is a nasty hack (try >> disabling javascript and look at our docs in Firefox, Chrome or >> Safari... the monospace text will be really small). Fortunately I've >> worked around that, with the downside being that if users have >> selected different default font settings for their browser, I've >> overridden it. Now the font sizes should be virtually the same in all >> browsers. > > That seems pretty unfriendly from an accessibility standpoint. Maybe, but the only alternative is to copy the current site's javascript hack. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
> Well that was a pain. Didn't realise there was a special hacky CSS
> file to fix fonts for gecko and webkit browsers. We use javascript to
> add it in on the current documentation, which is a nasty hack (try
> disabling javascript and look at our docs in Firefox, Chrome or
> Safari... the monospace text will be really small). Fortunately I've
> worked around that, with the downside being that if users have
> selected different default font settings for their browser, I've
> overridden it. Now the font sizes should be virtually the same in all
> browsers.
That seems pretty unfriendly from an accessibility standpoint.
regards, tom lane
On 29 August 2010 20:27, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: > >> Okay, I've made a couple other changes, but if it's not working >> now, I don't think it's supported. This page suggests that >> box-shadow isn't yet supported by KHTML: >> http://www.legendscrolls.co.uk/webstandards/khtml > > No shadows in Konqueror. > >> I've just tested it in Opera, and CSS as it is causes massive >> jumps in font size for some elements, so I'll need to fix those >> too. > > Now that you mention it, there are some large fonts for some > elements in Konqueror, too. I'll check that after you fix it for > Opera. Well that was a pain. Didn't realise there was a special hacky CSS file to fix fonts for gecko and webkit browsers. We use javascript to add it in on the current documentation, which is a nasty hack (try disabling javascript and look at our docs in Firefox, Chrome or Safari... the monospace text will be really small). Fortunately I've worked around that, with the downside being that if users have selected different default font settings for their browser, I've overridden it. Now the font sizes should be virtually the same in all browsers. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Tue, 2010-08-31 at 12:24 -0400, Tom Lane wrote: > Thom Brown <thom@linux.com> writes: > > On 31 August 2010 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Thom Brown <thom@linux.com> writes: > >>> Now the font sizes should be virtually the same in all browsers. > >> > >> That seems pretty unfriendly from an accessibility standpoint. > > > Maybe, but the only alternative is to copy the current site's javascript hack. > > There's a reason why it was done that way before ... There is no reason to do that. Every browser has the ability to override font settings. If the user has accessibility issues, they have the ability to deal with it. Heck, as I get older I find myself using ctrl-shift+/- all the time. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Joshua D. Drake wrote: > On Tue, 2010-08-31 at 12:24 -0400, Tom Lane wrote: > > Thom Brown <thom@linux.com> writes: > > > On 31 August 2010 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> Thom Brown <thom@linux.com> writes: > > >>> Now the font sizes should be virtually the same in all browsers. > > >> > > >> That seems pretty unfriendly from an accessibility standpoint. > > > > > Maybe, but the only alternative is to copy the current site's javascript hack. > > > > There's a reason why it was done that way before ... > > There is no reason to do that. Every browser has the ability to override > font settings. If the user has accessibility issues, they have the > ability to deal with it. > > Heck, as I get older I find myself using ctrl-shift+/- all the time. Are we talking about the Firefox hack that assume fixed-width font has a smaller font size and therefore is set to larger than the variable-width font? I never liked that code and thought there must be a better way to fix that. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Tue, 2010-08-31 at 12:24 -0400, Tom Lane wrote:
>> There's a reason why it was done that way before ...
> There is no reason to do that. Every browser has the ability to override
> font settings. If the user has accessibility issues, they have the
> ability to deal with it.
If that's actually the case, I withdraw the complaint. I read Thom's
message as saying that he was overriding the user's font settings.
regards, tom lane
Thom Brown <thom@linux.com> wrote: >>>> Thom Brown <thom@linux.com> writes: >>>>> Now the font sizes should be virtually the same in all >>>>> browsers. That looked good in Firefox and Konqueror on my kubuntu machine. > Okay, I've added a slightly modified version of that in (was > missing in the new version of the site), removed the generic > font-size for monospace, and adjusted the gecko CSS file to target > a reduced set of elements (the previous targetted too much on the > new site). Back to giant monospace characters in Konqueror. -Kevin
On 31 August 2010 17:24, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 31 August 2010 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Thom Brown <thom@linux.com> writes: >>>> Now the font sizes should be virtually the same in all browsers. >>> >>> That seems pretty unfriendly from an accessibility standpoint. > >> Maybe, but the only alternative is to copy the current site's javascript hack. > > There's a reason why it was done that way before ... Okay, I've added a slightly modified version of that in (was missing in the new version of the site), removed the generic font-size for monospace, and adjusted the gecko CSS file to target a reduced set of elements (the previous targetted too much on the new site). -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 31 August 2010 17:57, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> On Tue, 2010-08-31 at 12:24 -0400, Tom Lane wrote: >>> There's a reason why it was done that way before ... > >> There is no reason to do that. Every browser has the ability to override >> font settings. If the user has accessibility issues, they have the >> ability to deal with it. > > If that's actually the case, I withdraw the complaint. I read Thom's > message as saying that he was overriding the user's font settings. In a way I am. Users have the ability (although not often exercised) to change the default font and size. I gave the HTML tag a font-size, so that anything under it would be based on that. We use relative font sizes in our CSS, which means usually we'd be proportional to whatever the user had set. But what I've done is set a base size (17px in this case, and only in documentation) which everything else will be based on. So the downside is whatever the user set their default font size to in their browser will be ignored (or not fallen back to if you prefer). This doesn't, however, prevent them from using a text zoom (available in pretty much every web browser) to increase the size of all rendered fonts. The problem is, by default, Firefox sets proportional fonts to 16px, and monospace to 12px, so there's always a visual discrepancy when these fonts appear alongside one another. But the benefit of the javascript hack was that we weren't setting a base font size for everything, we just bump up the relative font size for elements which are monospaced by default. There's pros and cons to both approaches. I'm not sure which one you guys prefer. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown wrote: > In a way I am. Users have the ability (although not often exercised) > to change the default font and size. I gave the HTML tag a font-size, > so that anything under it would be based on that. We use relative > font sizes in our CSS, which means usually we'd be proportional to > whatever the user had set. But what I've done is set a base size > (17px in this case, and only in documentation) which everything else > will be based on. So the downside is whatever the user set their > default font size to in their browser will be ignored (or not fallen > back to if you prefer). This doesn't, however, prevent them from > using a text zoom (available in pretty much every web browser) to > increase the size of all rendered fonts. > > The problem is, by default, Firefox sets proportional fonts to 16px, > and monospace to 12px, so there's always a visual discrepancy when > these fonts appear alongside one another. > > But the benefit of the javascript hack was that we weren't setting a > base font size for everything, we just bump up the relative font size > for elements which are monospaced by default. > > There's pros and cons to both approaches. I'm not sure which one you > guys prefer. If we are using Javascript, why can't we probe the font size and do something reasonable, e.g. make monospace larger only if it smaller than proportional? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 31 August 2010 18:37, Bruce Momjian <bruce@momjian.us> wrote: > Thom Brown wrote: >> In a way I am. Users have the ability (although not often exercised) >> to change the default font and size. I gave the HTML tag a font-size, >> so that anything under it would be based on that. We use relative >> font sizes in our CSS, which means usually we'd be proportional to >> whatever the user had set. But what I've done is set a base size >> (17px in this case, and only in documentation) which everything else >> will be based on. So the downside is whatever the user set their >> default font size to in their browser will be ignored (or not fallen >> back to if you prefer). This doesn't, however, prevent them from >> using a text zoom (available in pretty much every web browser) to >> increase the size of all rendered fonts. >> >> The problem is, by default, Firefox sets proportional fonts to 16px, >> and monospace to 12px, so there's always a visual discrepancy when >> these fonts appear alongside one another. >> >> But the benefit of the javascript hack was that we weren't setting a >> base font size for everything, we just bump up the relative font size >> for elements which are monospaced by default. >> >> There's pros and cons to both approaches. I'm not sure which one you >> guys prefer. > > If we are using Javascript, why can't we probe the font size and do > something reasonable, e.g. make monospace larger only if it smaller than > proportional? Hmm.. I don't know if the rendered font size is exposed to the DOM. If someone with some ECMAScript-fu knows how, we could do that. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown wrote:
> >> But the benefit of the javascript hack was that we weren't setting a
> >> base font size for everything, we just bump up the relative font size
> >> for elements which are monospaced by default.
> >>
> >> There's pros and cons to both approaches. ?I'm not sure which one you
> >> guys prefer.
> >
> > If we are using Javascript, why can't we probe the font size and do
> > something reasonable, e.g. make monospace larger only if it smaller than
> > proportional?
>
> Hmm.. I don't know if the rendered font size is exposed to the DOM.
I quick search shows it as document.body.style.fontSize:
http://www.ehow.com/how_5924039_change-font-size-javascript.html
I believe you can query a fixed-width attribute to find its font size.
Would you like me to write some Javascript that illustrates that?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On 31 August 2010 18:45, Bruce Momjian <bruce@momjian.us> wrote: > Thom Brown wrote: >> >> But the benefit of the javascript hack was that we weren't setting a >> >> base font size for everything, we just bump up the relative font size >> >> for elements which are monospaced by default. >> >> >> >> There's pros and cons to both approaches. ?I'm not sure which one you >> >> guys prefer. >> > >> > If we are using Javascript, why can't we probe the font size and do >> > something reasonable, e.g. make monospace larger only if it smaller than >> > proportional? >> >> Hmm.. I don't know if the rendered font size is exposed to the DOM. > > I quick search shows it as document.body.style.fontSize: > > http://www.ehow.com/how_5924039_change-font-size-javascript.html > > I believe you can query a fixed-width attribute to find its font size. > Would you like me to write some Javascript that illustrates that? The code on that page shows that the value can be blank, suggesting it only picks up applied CSS styles, not font sizes which are a result of falling back on the defaults. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown wrote: > On 31 August 2010 18:45, Bruce Momjian <bruce@momjian.us> wrote: > > Thom Brown wrote: > >> >> But the benefit of the javascript hack was that we weren't setting a > >> >> base font size for everything, we just bump up the relative font size > >> >> for elements which are monospaced by default. > >> >> > >> >> There's pros and cons to both approaches. ?I'm not sure which one you > >> >> guys prefer. > >> > > >> > If we are using Javascript, why can't we probe the font size and do > >> > something reasonable, e.g. make monospace larger only if it smaller than > >> > proportional? > >> > >> Hmm.. I don't know if the rendered font size is exposed to the DOM. > > > > I quick search shows it as document.body.style.fontSize: > > > > ? ? ? ?http://www.ehow.com/how_5924039_change-font-size-javascript.html > > > > I believe you can query a fixed-width attribute to find its font size. > > Would you like me to write some Javascript that illustrates that? > > The code on that page shows that the value can be blank, suggesting it > only picks up applied CSS styles, not font sizes which are a result of > falling back on the defaults. OK, let me dig around. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian wrote: > Thom Brown wrote: > > On 31 August 2010 18:45, Bruce Momjian <bruce@momjian.us> wrote: > > > Thom Brown wrote: > > >> >> But the benefit of the javascript hack was that we weren't setting a > > >> >> base font size for everything, we just bump up the relative font size > > >> >> for elements which are monospaced by default. > > >> >> > > >> >> There's pros and cons to both approaches. ?I'm not sure which one you > > >> >> guys prefer. > > >> > > > >> > If we are using Javascript, why can't we probe the font size and do > > >> > something reasonable, e.g. make monospace larger only if it smaller than > > >> > proportional? > > >> > > >> Hmm.. I don't know if the rendered font size is exposed to the DOM. > > > > > > I quick search shows it as document.body.style.fontSize: > > > > > > ? ? ? ?http://www.ehow.com/how_5924039_change-font-size-javascript.html > > > > > > I believe you can query a fixed-width attribute to find its font size. > > > Would you like me to write some Javascript that illustrates that? > > > > The code on that page shows that the value can be blank, suggesting it > > only picks up applied CSS styles, not font sizes which are a result of > > falling back on the defaults. > > OK, let me dig around. I found some sample code the is supposed to work in all browers. I tested it in Firefox and it worked. It should work in Opera and IE as well. HTML/Javascript file attached. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 31 August 2010 21:16, Bruce Momjian <bruce@momjian.us> wrote: > Bruce Momjian wrote: >> Thom Brown wrote: >> > On 31 August 2010 18:45, Bruce Momjian <bruce@momjian.us> wrote: >> > > Thom Brown wrote: >> > >> >> But the benefit of the javascript hack was that we weren't setting a >> > >> >> base font size for everything, we just bump up the relative font size >> > >> >> for elements which are monospaced by default. >> > >> >> >> > >> >> There's pros and cons to both approaches. ?I'm not sure which one you >> > >> >> guys prefer. >> > >> > >> > >> > If we are using Javascript, why can't we probe the font size and do >> > >> > something reasonable, e.g. make monospace larger only if it smaller than >> > >> > proportional? >> > >> >> > >> Hmm.. I don't know if the rendered font size is exposed to the DOM. >> > > >> > > I quick search shows it as document.body.style.fontSize: >> > > >> > > ? ? ? ?http://www.ehow.com/how_5924039_change-font-size-javascript.html >> > > >> > > I believe you can query a fixed-width attribute to find its font size. >> > > Would you like me to write some Javascript that illustrates that? >> > >> > The code on that page shows that the value can be blank, suggesting it >> > only picks up applied CSS styles, not font sizes which are a result of >> > falling back on the defaults. >> >> OK, let me dig around. > > I found some sample code the is supposed to work in all browers. I > tested it in Firefox and it worked. It should work in Opera and IE as > well. HTML/Javascript file attached. Thanks Bruce. I've implemented your recommended change. :) -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> wrote: > Bruce Momjian <bruce@momjian.us> wrote: >> I found some sample code the is supposed to work in all browers. >> I tested it in Firefox and it worked. It should work in Opera >> and IE as well. HTML/Javascript file attached. > > Thanks Bruce. I've implemented your recommended change. :) Looks good to me in both Firefox and Konqueror. -Kevin
On 31 August 2010 21:59, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: >> Bruce Momjian <bruce@momjian.us> wrote: > >>> I found some sample code the is supposed to work in all browers. >>> I tested it in Firefox and it worked. It should work in Opera >>> and IE as well. HTML/Javascript file attached. >> >> Thanks Bruce. I've implemented your recommended change. :) > > Looks good to me in both Firefox and Konqueror. I've just tested it at work in IE6/7/8 and looks fine (sans shadows and rounded corners of course). So I think that's no longer a problem. There are some changes that should be made to the docs to accommodate style changes though. A good example can be seen on http://pgweb.darkixion.com:8081/docs/8.4/static/xml2.html . The functions and parameter tables don't have a header, and the functions listed in the functions table are each written as a synopsis rather than a function. Also take a look at http://pgweb.darkixion.com:8081/docs/8.4/static/functions-aggregate.html . Table 9-43 lists functions but the formatting changes for the last 3 functions because the parameters weren't in the <function> element in the SGML. This happens inconsistently throughout the documentation. I previously submitted a patch to fix all of these problems, although that appears to have not come through from looking at the mailing list archive (is there an attachment size limit?). I've looked at a very large amount of the documentation with these styles, but not all of it, so there may be more issues I haven't yet witnessed. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 1 September 2010 09:36, Thom Brown <thom@linux.com> wrote: > On 31 August 2010 21:59, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> Thom Brown <thom@linux.com> wrote: >>> Bruce Momjian <bruce@momjian.us> wrote: >> >>>> I found some sample code the is supposed to work in all browers. >>>> I tested it in Firefox and it worked. It should work in Opera >>>> and IE as well. HTML/Javascript file attached. >>> >>> Thanks Bruce. I've implemented your recommended change. :) >> >> Looks good to me in both Firefox and Konqueror. > > I've just tested it at work in IE6/7/8 and looks fine (sans shadows > and rounded corners of course). So I think that's no longer a > problem. > > There are some changes that should be made to the docs to accommodate > style changes though. A good example can be seen on > http://pgweb.darkixion.com:8081/docs/8.4/static/xml2.html . The > functions and parameter tables don't have a header, and the functions > listed in the functions table are each written as a synopsis rather > than a function. > > Also take a look at > http://pgweb.darkixion.com:8081/docs/8.4/static/functions-aggregate.html > . Table 9-43 lists functions but the formatting changes for the last 3 > functions because the parameters weren't in the <function> element in > the SGML. This happens inconsistently throughout the documentation. > > I previously submitted a patch to fix all of these problems, although > that appears to have not come through from looking at the mailing list > archive (is there an attachment size limit?). I've looked at a very > large amount of the documentation with these styles, but not all of > it, so there may be more issues I haven't yet witnessed. I should also point out that someone I showed this to said that the blue text I've used for function names throughout could make the text be mistaken for a link. Comments? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
> I should also point out that someone I showed this to said that the
> blue text I've used for function names throughout could make the text
> be mistaken for a link. Comments?
Please, please, please, do NOT go there. Randomly coloring different
pieces of text is not unobtrusive.
regards, tom lane
On 1 September 2010 09:39, Thom Brown <thom@linux.com> wrote: > On 1 September 2010 09:36, Thom Brown <thom@linux.com> wrote: >> On 31 August 2010 21:59, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >>> Thom Brown <thom@linux.com> wrote: >>>> Bruce Momjian <bruce@momjian.us> wrote: >>> >>>>> I found some sample code the is supposed to work in all browers. >>>>> I tested it in Firefox and it worked. It should work in Opera >>>>> and IE as well. HTML/Javascript file attached. >>>> >>>> Thanks Bruce. I've implemented your recommended change. :) >>> >>> Looks good to me in both Firefox and Konqueror. >> >> I've just tested it at work in IE6/7/8 and looks fine (sans shadows >> and rounded corners of course). So I think that's no longer a >> problem. >> >> There are some changes that should be made to the docs to accommodate >> style changes though. A good example can be seen on >> http://pgweb.darkixion.com:8081/docs/8.4/static/xml2.html . The >> functions and parameter tables don't have a header, and the functions >> listed in the functions table are each written as a synopsis rather >> than a function. >> >> Also take a look at >> http://pgweb.darkixion.com:8081/docs/8.4/static/functions-aggregate.html >> . Table 9-43 lists functions but the formatting changes for the last 3 >> functions because the parameters weren't in the <function> element in >> the SGML. This happens inconsistently throughout the documentation. >> >> I previously submitted a patch to fix all of these problems, although >> that appears to have not come through from looking at the mailing list >> archive (is there an attachment size limit?). I've looked at a very >> large amount of the documentation with these styles, but not all of >> it, so there may be more issues I haven't yet witnessed. > > I should also point out that someone I showed this to said that the > blue text I've used for function names throughout could make the text > be mistaken for a link. Comments? I've added an experimental content navigation menu (appears in top-right-hand corner) which jumps to sections of the same page. It only appears on pages which have items to navigate to, including the main index. Example pages: http://pgweb.darkixion.com:8081/docs/8.4/static/sql-syntax-lexical.html http://pgweb.darkixion.com:8081/docs/8.4/static/bookindex.html http://pgweb.darkixion.com:8081/docs/8.4/static/datatype-geometric.html -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 1 September 2010 14:47, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> I should also point out that someone I showed this to said that the >> blue text I've used for function names throughout could make the text >> be mistaken for a link. Comments? > > Please, please, please, do NOT go there. Randomly coloring different > pieces of text is not unobtrusive. I'll remove that then. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> wrote: > I've added an experimental content navigation menu (appears in > top-right-hand corner) which jumps to sections of the same page. > It only appears on pages which have items to navigate to, > including the main index. I don't feel strongly about this feature one way or another. If it is added, I'll probably use it now and then. > http://pgweb.darkixion.com:8081/docs/8.4/static/sql-syntax-lexical.html The lower level of links in the pop-up don't work for me in either Firefox or Konqueror. The top level works fine. -Kevin
On 1 September 2010 15:00, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Thom Brown <thom@linux.com> wrote: > >> I've added an experimental content navigation menu (appears in >> top-right-hand corner) which jumps to sections of the same page. >> It only appears on pages which have items to navigate to, >> including the main index. > > I don't feel strongly about this feature one way or another. If it > is added, I'll probably use it now and then. > >> > http://pgweb.darkixion.com:8081/docs/8.4/static/sql-syntax-lexical.html > > The lower level of links in the pop-up don't work for me in either > Firefox or Konqueror. The top level works fine. I'd only bother fixing that if we wanted to keep it. If people deem it pointless, annoying, or just a terrible idea, I'll delete it. Thom
On 1 September 2010 15:06, Thom Brown <thom@linux.com> wrote: > On 1 September 2010 15:00, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> Thom Brown <thom@linux.com> wrote: >> >>> I've added an experimental content navigation menu (appears in >>> top-right-hand corner) which jumps to sections of the same page. >>> It only appears on pages which have items to navigate to, >>> including the main index. >> >> I don't feel strongly about this feature one way or another. If it >> is added, I'll probably use it now and then. >> >>> >> http://pgweb.darkixion.com:8081/docs/8.4/static/sql-syntax-lexical.html >> >> The lower level of links in the pop-up don't work for me in either >> Firefox or Konqueror. The top level works fine. > > I'd only bother fixing that if we wanted to keep it. If people deem > it pointless, annoying, or just a terrible idea, I'll delete it. I've gone and fixed that anyway. I personally use this in a Greasemonkey script. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
> I've added an experimental content navigation menu (appears in
> top-right-hand corner) which jumps to sections of the same page. It
> only appears on pages which have items to navigate to, including the
> main index.
Hmmm ... that's potentially useful, but I really really dislike the way
that the button hangs there despite scrolling. It's intrusive and it
absolutely screams "won't work in all browsers". Can't it just be a
button or menu at the top of the page?
regards, tom lane
On 1 September 2010 16:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> I've added an experimental content navigation menu (appears in >> top-right-hand corner) which jumps to sections of the same page. It >> only appears on pages which have items to navigate to, including the >> main index. > > Hmmm ... that's potentially useful, but I really really dislike the way > that the button hangs there despite scrolling. It's intrusive and it > absolutely screams "won't work in all browsers". Can't it just be a > button or menu at the top of the page? It works in Firefox, Opera, Chrome, Safari, and IE7/8. If the button doesnt hang there, it becomes inaccessible the moment you begin to scroll a bit. I guess it could still be useful if there's a collapsed content list available at the top. I'll experiment with doing that later. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
> On 1 September 2010 16:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmmm ... that's potentially useful, but I really really dislike the way
>> that the button hangs there despite scrolling. �It's intrusive and it
>> absolutely screams "won't work in all browsers". �Can't it just be a
>> button or menu at the top of the page?
> It works in Firefox, Opera, Chrome, Safari, and IE7/8.
The bane of the modern web is designers who think like that.
As an example, do you think that anyone trying to read one of these
pages on a cell-phone-sized screen is going to thank you for taking up
some of his screen with this?
regards, tom lane
On 1 September 2010 16:29, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 1 September 2010 16:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Hmmm ... that's potentially useful, but I really really dislike the way >>> that the button hangs there despite scrolling. It's intrusive and it >>> absolutely screams "won't work in all browsers". Can't it just be a >>> button or menu at the top of the page? > >> It works in Firefox, Opera, Chrome, Safari, and IE7/8. > > The bane of the modern web is designers who think like that. > > As an example, do you think that anyone trying to read one of these > pages on a cell-phone-sized screen is going to thank you for taking up > some of his screen with this? Tested on Palm Pre browser and works perfectly, but I can't test on anything else. I wasn't suggesting that marks the end of the test. I can't do all the testing by myself. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Wed, 2010-09-01 at 11:03 -0400, Tom Lane wrote: > Thom Brown <thom@linux.com> writes: > > I've added an experimental content navigation menu (appears in > > top-right-hand corner) which jumps to sections of the same page. It > > only appears on pages which have items to navigate to, including the > > main index. > > Hmmm ... that's potentially useful, but I really really dislike the way > that the button hangs there despite scrolling. It's intrusive and it > absolutely screams "won't work in all browsers". Can't it just be a > button or menu at the top of the page? It is going to work in any modern browser, which is what we *need* to be targeting and it won't hurt anyone that doesn't have one. It is a pretty stock thing to do in the current web design methodologies (even blip.tv does it). The one thing I would mention, is that I didn't see it. Part of that is my large screen (1080p, 24") but the other part is, people on this side of the world read left to right. If we are going to have this, I would recommend it be on the left hand side instead. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote: > Thom Brown <thom@linux.com> writes: > > On 1 September 2010 16:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Hmmm ... that's potentially useful, but I really really dislike the way > >> that the button hangs there despite scrolling. It's intrusive and it > >> absolutely screams "won't work in all browsers". Can't it just be a > >> button or menu at the top of the page? > > > It works in Firefox, Opera, Chrome, Safari, and IE7/8. > > The bane of the modern web is designers who think like that. > > As an example, do you think that anyone trying to read one of these > pages on a cell-phone-sized screen is going to thank you for taking up > some of his screen with this? Not anymore than all the other stuff on the screen (like the search box, header and excess space between the breadcrumb, the title and the fast forward links). I just looked at the page on my handy HTC Incredible (still no Froyo!) and it looks great. The content box doesn't hover like in chrome proper but the page looks good. JD > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 1 September 2010 17:16, Joshua D. Drake <jd@commandprompt.com> wrote: > On Wed, 2010-09-01 at 11:03 -0400, Tom Lane wrote: >> Thom Brown <thom@linux.com> writes: >> > I've added an experimental content navigation menu (appears in >> > top-right-hand corner) which jumps to sections of the same page. It >> > only appears on pages which have items to navigate to, including the >> > main index. >> >> Hmmm ... that's potentially useful, but I really really dislike the way >> that the button hangs there despite scrolling. It's intrusive and it >> absolutely screams "won't work in all browsers". Can't it just be a >> button or menu at the top of the page? > > It is going to work in any modern browser, which is what we *need* to be > targeting and it won't hurt anyone that doesn't have one. It is a pretty > stock thing to do in the current web design methodologies (even blip.tv > does it). > > The one thing I would mention, is that I didn't see it. Part of that is > my large screen (1080p, 24") but the other part is, people on this side > of the world read left to right. If we are going to have this, I would > recommend it be on the left hand side instead. I would have thought that would be even more obtrusive for those with small screens as it would overlap content on the left-hand side and constantly get in the way. If you consider that it can't be in the header on the left-hand-side as it would appear in front of the logo, then it would have to go further down, and as soon as you begin scrolling it looks odd being part-way down the page. I'm going to remove it anyway. Was just an idea. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote:
>> As an example, do you think that anyone trying to read one of these
>> pages on a cell-phone-sized screen is going to thank you for taking up
>> some of his screen with this?
> Not anymore than all the other stuff on the screen (like the search box,
> header and excess space between the breadcrumb, the title and the fast
> forward links).
Uh, no, because that stuff is just at the top of the page; it doesn't
stay there while you scroll down.
regards, tom lane
On Wed, 2010-09-01 at 13:04 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote: > >> As an example, do you think that anyone trying to read one of these > >> pages on a cell-phone-sized screen is going to thank you for taking up > >> some of his screen with this? > > > Not anymore than all the other stuff on the screen (like the search box, > > header and excess space between the breadcrumb, the title and the fast > > forward links). > > Uh, no, because that stuff is just at the top of the page; it doesn't > stay there while you scroll down. You may have missed the part where I said, it didn't move for me. :D Anyway, Thom is removing it so it doesn't really matter. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 1 September 2010 18:26, Joshua D. Drake <jd@commandprompt.com> wrote: > On Wed, 2010-09-01 at 13:04 -0400, Tom Lane wrote: >> "Joshua D. Drake" <jd@commandprompt.com> writes: >> > On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote: >> >> As an example, do you think that anyone trying to read one of these >> >> pages on a cell-phone-sized screen is going to thank you for taking up >> >> some of his screen with this? >> >> > Not anymore than all the other stuff on the screen (like the search box, >> > header and excess space between the breadcrumb, the title and the fast >> > forward links). >> >> Uh, no, because that stuff is just at the top of the page; it doesn't >> stay there while you scroll down. > > You may have missed the part where I said, it didn't move for me. :D > > Anyway, Thom is removing it so it doesn't really matter. > > JD I'm coming round to the idea that if we wanted such a table of contents, we'd generate it on the page when building the docs rather than running some ECMAScript. I've already got a basic contents thing showing on my version of the docs (see http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), but I'm not happy with it. It looks out of place and there doesn't seem to be any appropriate place to put the link to show it. So rather than attempting to do this, do you think we should produce a table of contents on pages containing 3rd and 4th-level chapter headings? This would be in the same style as we currently have for chapter introductions: http://pgweb.darkixion.com:8081/docs/9.0/static/typeconv.html with the only difference being that it would show the 3rd and 4th levels as opposed to the 2nd and 3rd levels currently on chapter start pages. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Wed, Sep 1, 2010 at 22:22, Thom Brown <thom@linux.com> wrote: > On 1 September 2010 18:26, Joshua D. Drake <jd@commandprompt.com> wrote: >> On Wed, 2010-09-01 at 13:04 -0400, Tom Lane wrote: >>> "Joshua D. Drake" <jd@commandprompt.com> writes: >>> > On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote: >>> >> As an example, do you think that anyone trying to read one of these >>> >> pages on a cell-phone-sized screen is going to thank you for taking up >>> >> some of his screen with this? >>> >>> > Not anymore than all the other stuff on the screen (like the search box, >>> > header and excess space between the breadcrumb, the title and the fast >>> > forward links). >>> >>> Uh, no, because that stuff is just at the top of the page; it doesn't >>> stay there while you scroll down. >> >> You may have missed the part where I said, it didn't move for me. :D >> >> Anyway, Thom is removing it so it doesn't really matter. >> >> JD > > I'm coming round to the idea that if we wanted such a table of > contents, we'd generate it on the page when building the docs rather > than running some ECMAScript. I've already got a basic contents thing Yes, definite +1 on that if you can make that work. > showing on my version of the docs (see > http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), > but I'm not happy with it. It looks out of place and there doesn't > seem to be any appropriate place to put the link to show it. (once you're happy with it, of course) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Excerpts from Thom Brown's message of mié sep 01 16:22:22 -0400 2010: > I'm coming round to the idea that if we wanted such a table of > contents, we'd generate it on the page when building the docs rather > than running some ECMAScript. I've already got a basic contents thing > showing on my version of the docs (see > http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), > but I'm not happy with it. It looks out of place and there doesn't > seem to be any appropriate place to put the link to show it. How does this effort relate to http://archives.postgresql.org/message-id/4B7EA23A.1000705@archonet.com ? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 1 September 2010 21:34, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Thom Brown's message of mié sep 01 16:22:22 -0400 2010: > >> I'm coming round to the idea that if we wanted such a table of >> contents, we'd generate it on the page when building the docs rather >> than running some ECMAScript. I've already got a basic contents thing >> showing on my version of the docs (see >> http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), >> but I'm not happy with it. It looks out of place and there doesn't >> seem to be any appropriate place to put the link to show it. > > How does this effort relate to > http://archives.postgresql.org/message-id/4B7EA23A.1000705@archonet.com ? I think the problem with that is that it doesn't seek to build the extra table of contents into the docs, but my script does appear to be a duplicate effort, so even more reason for me to abandon it ;) -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Excerpts from Thom Brown's message of mié sep 01 16:39:54 -0400 2010: > On 1 September 2010 21:34, Alvaro Herrera <alvherre@commandprompt.com> wrote: > > Excerpts from Thom Brown's message of mié sep 01 16:22:22 -0400 2010: > > > >> I'm coming round to the idea that if we wanted such a table of > >> contents, we'd generate it on the page when building the docs rather > >> than running some ECMAScript. I've already got a basic contents thing > >> showing on my version of the docs (see > >> http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), > >> but I'm not happy with it. It looks out of place and there doesn't > >> seem to be any appropriate place to put the link to show it. > > > > How does this effort relate to > > http://archives.postgresql.org/message-id/4B7EA23A.1000705@archonet.com ? > > I think the problem with that is that it doesn't seek to build the > extra table of contents into the docs, but my script does appear to be > a duplicate effort, so even more reason for me to abandon it ;) Well, at least get *something* out there and have it committed on the website and/or the PG CVS .css file, before moving on and fiddling with a floating TOC or whatnot. And if you're going there, by all means talk to Richard :-) -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, 2010-09-01 at 11:03 -0400, Tom Lane wrote: > Thom Brown <thom@linux.com> writes: > > I've added an experimental content navigation menu (appears in > > top-right-hand corner) which jumps to sections of the same page. It > > only appears on pages which have items to navigate to, including the > > main index. > > Hmmm ... that's potentially useful, but I really really dislike the way > that the button hangs there despite scrolling. It's intrusive and it > absolutely screams "won't work in all browsers". Can't it just be a > button or menu at the top of the page? It is going to work in any modern browser, which is what we *need* to be targeting and it won't hurt anyone that doesn't have one. It is a pretty stock thing to do in the current web design methodologies (even blip.tv does it). The one thing I would mention, is that I didn't see it. Part of that is my large screen (1080p, 24") but the other part is, people on this side of the world read left to right. If we are going to have this, I would recommend it be on the left hand side instead. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote: > Thom Brown <thom@linux.com> writes: > > On 1 September 2010 16:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Hmmm ... that's potentially useful, but I really really dislike the way > >> that the button hangs there despite scrolling. It's intrusive and it > >> absolutely screams "won't work in all browsers". Can't it just be a > >> button or menu at the top of the page? > > > It works in Firefox, Opera, Chrome, Safari, and IE7/8. > > The bane of the modern web is designers who think like that. > > As an example, do you think that anyone trying to read one of these > pages on a cell-phone-sized screen is going to thank you for taking up > some of his screen with this? Not anymore than all the other stuff on the screen (like the search box, header and excess space between the breadcrumb, the title and the fast forward links). I just looked at the page on my handy HTC Incredible (still no Froyo!) and it looks great. The content box doesn't hover like in chrome proper but the page looks good. JD > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Wed, 2010-09-01 at 13:04 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > On Wed, 2010-09-01 at 11:29 -0400, Tom Lane wrote: > >> As an example, do you think that anyone trying to read one of these > >> pages on a cell-phone-sized screen is going to thank you for taking up > >> some of his screen with this? > > > Not anymore than all the other stuff on the screen (like the search box, > > header and excess space between the breadcrumb, the title and the fast > > forward links). > > Uh, no, because that stuff is just at the top of the page; it doesn't > stay there while you scroll down. You may have missed the part where I said, it didn't move for me. :D Anyway, Thom is removing it so it doesn't really matter. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On 1 September 2010 21:46, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Thom Brown's message of mié sep 01 16:39:54 -0400 2010: >> On 1 September 2010 21:34, Alvaro Herrera <alvherre@commandprompt.com> wrote: >> > Excerpts from Thom Brown's message of mié sep 01 16:22:22 -0400 2010: >> > >> >> I'm coming round to the idea that if we wanted such a table of >> >> contents, we'd generate it on the page when building the docs rather >> >> than running some ECMAScript. I've already got a basic contents thing >> >> showing on my version of the docs (see >> >> http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), >> >> but I'm not happy with it. It looks out of place and there doesn't >> >> seem to be any appropriate place to put the link to show it. >> > >> > How does this effort relate to >> > http://archives.postgresql.org/message-id/4B7EA23A.1000705@archonet.com ? >> >> I think the problem with that is that it doesn't seek to build the >> extra table of contents into the docs, but my script does appear to be >> a duplicate effort, so even more reason for me to abandon it ;) > > Well, at least get *something* out there and have it committed on the > website and/or the PG CVS .css file, before moving on and fiddling with > a floating TOC or whatnot. And if you're going there, by all means talk > to Richard :-) Yes, I've committed changes to a forked git repository. :) Anymore feedback/suggestions? Anything not look right? Are we there yet? I was thinking the borders look a bit too bold, so might reduce them. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Mon, Sep 6, 2010 at 14:45, Thom Brown <thom@linux.com> wrote: > On 1 September 2010 21:46, Alvaro Herrera <alvherre@commandprompt.com> wrote: >> Excerpts from Thom Brown's message of mié sep 01 16:39:54 -0400 2010: >>> On 1 September 2010 21:34, Alvaro Herrera <alvherre@commandprompt.com> wrote: >>> > Excerpts from Thom Brown's message of mié sep 01 16:22:22 -0400 2010: >>> > >>> >> I'm coming round to the idea that if we wanted such a table of >>> >> contents, we'd generate it on the page when building the docs rather >>> >> than running some ECMAScript. I've already got a basic contents thing >>> >> showing on my version of the docs (see >>> >> http://pgweb.darkixion.com:8081/docs/9.0/static/functions-xml.html ), >>> >> but I'm not happy with it. It looks out of place and there doesn't >>> >> seem to be any appropriate place to put the link to show it. >>> > >>> > How does this effort relate to >>> > http://archives.postgresql.org/message-id/4B7EA23A.1000705@archonet.com ? >>> >>> I think the problem with that is that it doesn't seek to build the >>> extra table of contents into the docs, but my script does appear to be >>> a duplicate effort, so even more reason for me to abandon it ;) >> >> Well, at least get *something* out there and have it committed on the >> website and/or the PG CVS .css file, before moving on and fiddling with >> a floating TOC or whatnot. And if you're going there, by all means talk >> to Richard :-) > > Yes, I've committed changes to a forked git repository. :) And I've committed $self to merging these changes when we're done ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/