Обсуждение: Large fixed-width text
When reading our web-based server documentation in Ubuntu Firefox, I
have always seen overly-large fixed-width text. In looking at our CSS
files, specifically text.css, I see:
#txtArchives pre { font-size:150%;}#txtArchives tt { font-size:150%;}
This certainly looks wrong, and explains what I am seeing. Does anyone
know why it is there?
The actual code that is causing a problem in my browser is in
geckofixes.css:
#docContainer tt, #docContainer pre, #docContainer code { font-size:1.4em;}
and below it is this contradicting code for multi-tag content:
#docContainer tt tt, #docContainer tt code, #docContainer tt pre { font-size: 1.0em;}#docContainer pre code,
#docContainerpre tt, #docContainer pre pre { font-size: 1.0em;}#docContainer code code, #docContainer code tt,
#docContainercode pre { font-size: 1.0em;}
Again, why is it there. There are no comments indicating its purpose,
and it is clearly causing problems on my Firefox/Ubuntu setup.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
> When reading our web-based server documentation in Ubuntu Firefox, I
> have always seen overly-large fixed-width text. In looking at our CSS
> files, specifically text.css, I see:
>
> #txtArchives pre {
> font-size:150%;
> }
> #txtArchives tt {
> font-size:150%;
> }
>
> This certainly looks wrong, and explains what I am seeing. Does anyone
> know why it is there?
>
> The actual code that is causing a problem in my browser is in
> geckofixes.css:
>
> #docContainer tt, #docContainer pre, #docContainer code {
> font-size:1.4em;
> }
>
I am not on www team but I bet it's because with 1em (100%) the text is
tiny in Firefox under Windows in those elements.
--
Regards
Petr Jelinek (PJMODOS)
Petr Jelinek wrote:
> Bruce Momjian wrote:
> > When reading our web-based server documentation in Ubuntu Firefox, I
> > have always seen overly-large fixed-width text. In looking at our CSS
> > files, specifically text.css, I see:
> >
> > #txtArchives pre {
> > font-size:150%;
> > }
> > #txtArchives tt {
> > font-size:150%;
> > }
> >
> > This certainly looks wrong, and explains what I am seeing. Does anyone
> > know why it is there?
> >
> > The actual code that is causing a problem in my browser is in
> > geckofixes.css:
> >
> > #docContainer tt, #docContainer pre, #docContainer code {
> > font-size:1.4em;
> > }
> >
>
> I am not on www team but I bet it's because with 1em (100%) the text is
> tiny in Firefox under Windows in those elements.
So why is that? Is this a known bug in Firefox? Is it documented? Can
we apply the fix only to broken Firefox versions? The lack of comments
in the CSS file makes this issue unclear to me.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Sat, Sep 26, 2009 at 8:21 PM, Bruce Momjian <bruce@momjian.us> wrote: >> I am not on www team but I bet it's because with 1em (100%) the text is >> tiny in Firefox under Windows in those elements. > > So why is that? Is this a known bug in Firefox? Is it documented? Can > we apply the fix only to broken Firefox versions? The lack of comments > in the CSS file makes this issue unclear to me. I believe it's s targeted as practical - that's why it's in geckofixes.css. As for the lack of comments, yes, that is a pain. That's what we got from the original designers. Unfortunately the CSS is complex, and I don't thank any of us really know the purpose of all of it. It would take some time to thoroughly review and document, and I doubt you'll find anyone with the time or inclination. FYI, the sizing looks fine to me on FF 3.5.3 on Mac and 3.0.4 on CentOS 5. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Bruce Momjian napsal(a): <blockquote cite="mid:200909261921.n8QJLJW08369@momjian.us" type="cite"><pre wrap="">Petr
Jelinekwrote: </pre><blockquote type="cite"><pre wrap="">Bruce Momjian wrote: </pre><blockquote type="cite"><pre
wrap="">Whenreading our web-based server documentation in Ubuntu Firefox, I
have always seen overly-large fixed-width text. In looking at our CSS
files, specifically text.css, I see:
#txtArchives pre { font-size:150%;}#txtArchives tt { font-size:150%;}
This certainly looks wrong, and explains what I am seeing. Does anyone
know why it is there?
The actual code that is causing a problem in my browser is in
geckofixes.css:
#docContainer tt, #docContainer pre, #docContainer code { font-size:1.4em;} </pre></blockquote><pre wrap="">I
amnot on www team but I bet it's because with 1em (100%) the text is
tiny in Firefox under Windows in those elements. </pre></blockquote><pre wrap="">
So why is that? Is this a known bug in Firefox? Is it documented? Can
we apply the fix only to broken Firefox versions? The lack of comments
in the CSS file makes this issue unclear to me. </pre></blockquote><br /> It's known behavior, not a bug.<br /> By
defaultFF on Windows (not sure about other OSes, but on Jaunty my FF does it too), Safari, Chrome all choose 13px font
sizefor monospace and 16px for everything else (so maybe you changed default font size for monospaced fonts in your
FF?).And since we have 76% (docs) and 69% (primary web) body font sizes, they get inherited and monospace text is too
small(76% of those default 13px) and obvious fix is to make it larger and that's what we do. There are other ways to
fixthis. One is specifying exact font family and not monospace generic font family, but that changes font for people
whohave different default monospace font from what we choose and also since we are not using the monospace generic font
family(see why below), people who don't have any of the fonts we specify the won't have monospaced text at all in those
elements.<br/> There is also Firefox specific "fix" for this (very ugly):<br /><pre>font-family : monospace, "";</pre>
Andremove all those font-size hacks. One more way to fix it in Firefox (3.0+) is to use font-size-adjust : 0.58 for
pre,tt, code. Other browsers don't support this propery.<br /> So the real problem is Safari (Webkit). It switches to
smallerfont size once you specify monospace generic font family anywhere in the font-family property and it does not
supportfont-size-adjust.<br /> Opera does it differently, it just uses internal default stylesheet to make font-size
smaller(0.81em IIRC) for those elements that are monospaced by default (pre, tt, ...) so setting font-size : 1em is
enoughthere. IE seems to do something similar since it behaves the same, so no problem in either of those two.<br /><br
/>As you can see every browser does something different and finding universal solution is not easy.<br /><br /> Anyway
those#txtArchives pre and #txtArchives tt do not affect documentation but they indeed seem to be plain wrong, they are
actuallyonly used by Opera (and maybe Chrome , I don't have that browser) and the text looks huge there. In FF and
Safarithey are overwritten by<br /><div class="cssRule insertInto editGroup" role="presentation" ruleid="#pgContainer
code,#pgContainer pre, #pgContainer tt/3"><pre>#pgContainer code, #pgContainer pre, #pgContainer tt { font-size:
1.2em;
}
</pre></div> in geckofixes.css (yes it loads for Safari too on my machine and it's a good thing) and in IE they're
overwrittenby <br /><pre>* html #txtArchives pre { font-size: 100%; }
</pre> in iefixes.css.<br /><br /><pre class="moz-signature" cols="72">--
Regards
Petr Jelinek (PJMODOS)</pre>
2009/9/27 Petr Jelinek <pjmodos@pjmodos.net>:
> It's known behavior, not a bug.
> By default FF on Windows (not sure about other OSes, but on Jaunty my FF
> does it too), Safari, Chrome all choose 13px font size for monospace and
> 16px for everything else (so maybe you changed default font size for
> monospaced fonts in your FF?). And since we have 76% (docs) and 69% (primary
> web) body font sizes, they get inherited and monospace text is too small
> (76% of those default 13px) and obvious fix is to make it larger and that's
> what we do. There are other ways to fix this. One is specifying exact font
> family and not monospace generic font family, but that changes font for
> people who have different default monospace font from what we choose and
> also since we are not using the monospace generic font family (see why
> below), people who don't have any of the fonts we specify the won't have
> monospaced text at all in those elements.
> There is also Firefox specific "fix" for this (very ugly):
>
> font-family : monospace, "";
>
> And remove all those font-size hacks. One more way to fix it in Firefox
> (3.0+) is to use font-size-adjust : 0.58 for pre, tt, code. Other browsers
> don't support this propery.
> So the real problem is Safari (Webkit). It switches to smaller font size
> once you specify monospace generic font family anywhere in the font-family
> property and it does not support font-size-adjust.
> Opera does it differently, it just uses internal default stylesheet to make
> font-size smaller (0.81em IIRC) for those elements that are monospaced by
> default (pre, tt, ...) so setting font-size : 1em is enough there. IE seems
> to do something similar since it behaves the same, so no problem in either
> of those two.
>
> As you can see every browser does something different and finding universal
> solution is not easy.
It almost sounds like you're volunteering to be our new in-house CSS
expert Petr :-)
> Anyway those #txtArchives pre and #txtArchives tt do not affect
> documentation but they indeed seem to be plain wrong, they are actually only
> used by Opera (and maybe Chrome , I don't have that browser) and the text
> looks huge there. In FF and Safari they are overwritten by
>
> #pgContainer code, #pgContainer pre, #pgContainer tt {
> font-size: 1.2em;
> }
>
> in geckofixes.css (yes it loads for Safari too on my machine and it's a good
> thing) and in IE they're overwritten by
>
> * html #txtArchives pre { font-size: 100%; }
>
> in iefixes.css.
txtArchives is used by archives.postgresql.org, not the docs.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
Dave Page napsal(a):<br /><blockquote cite="mid:937d27e10909270936l3c2f874frd39fb6311b1f7014@mail.gmail.com"
type="cite"><blockquotetype="cite"><pre wrap="">Anyway those #txtArchives pre and #txtArchives tt do not affect
documentation but they indeed seem to be plain wrong, they are actually only
used by Opera (and maybe Chrome , I don't have that browser) and the text
looks huge there. In FF and Safari they are overwritten by
#pgContainer code, #pgContainer pre, #pgContainer tt { font-size: 1.2em;
}
in geckofixes.css (yes it loads for Safari too on my machine and it's a good
thing) and in IE they're overwritten by
* html #txtArchives pre { font-size: 100%; }
in iefixes.css. </pre></blockquote><pre wrap="">
txtArchives is used by archives.postgresql.org, not the docs. </pre></blockquote><br /> Cite from the first sentence:
*Anywaythose #txtArchives pre and #txtArchives tt do not affect<br /> documentation*<br /><br /><pre
class="moz-signature"cols="72">--
Regards
Petr Jelinek (PJMODOS)</pre>
On 9/27/09, Petr Jelinek <pjmodos@pjmodos.net> wrote:
> Dave Page napsal(a):
>>> Anyway those #txtArchives pre and #txtArchives tt do not affect
>>> documentation but they indeed seem to be plain wrong, they are actually
>>> only
>>> used by Opera (and maybe Chrome , I don't have that browser) and the text
>>> looks huge there. In FF and Safari they are overwritten by
>>>
>>> #pgContainer code, #pgContainer pre, #pgContainer tt {
>>> font-size: 1.2em;
>>> }
>>>
>>> in geckofixes.css (yes it loads for Safari too on my machine and it's a
>>> good
>>> thing) and in IE they're overwritten by
>>>
>>> * html #txtArchives pre { font-size: 100%; }
>>>
>>> in iefixes.css.
>>>
>>
>> txtArchives is used by archives.postgresql.org, not the docs.
>>
>
> Cite from the first sentence: *Anyway those #txtArchives pre and
> #txtArchives tt do not affect
> documentation*
>
Yes, i did read what you wrote. I was pointing out what they do affect.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
Dave Page napsal(a): <blockquote cite="mid:937d27e10909271216l11e31934h354b1f5fc5609dbe@mail.gmail.com"
type="cite"><prewrap="">On 9/27/09, Petr Jelinek <a class="moz-txt-link-rfc2396E"
href="mailto:pjmodos@pjmodos.net"><pjmodos@pjmodos.net></a>wrote: </pre><blockquote type="cite"><pre wrap="">Dave
Pagenapsal(a): </pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Anyway those #txtArchives pre and
#txtArchivestt do not affect
documentation but they indeed seem to be plain wrong, they are actually
only
used by Opera (and maybe Chrome , I don't have that browser) and the text
looks huge there. In FF and Safari they are overwritten by
#pgContainer code, #pgContainer pre, #pgContainer tt { font-size: 1.2em;
}
in geckofixes.css (yes it loads for Safari too on my machine and it's a
good
thing) and in IE they're overwritten by
* html #txtArchives pre { font-size: 100%; }
in iefixes.css.
</pre></blockquote><pre wrap="">txtArchives is used by archives.postgresql.org, not the docs.
</pre></blockquote><pre wrap="">Cite from the first sentence: *Anyway those #txtArchives pre and
#txtArchives tt do not affect
documentation*
</pre></blockquote><pre wrap="">
Yes, i did read what you wrote. I was pointing out what they do affect. </pre></blockquote><br /> Oh, ok, I know they
affectmail body in archives and all I said is true - they are overwritten by other rules in most browsers and the text
ishuge in browsers where they're not overwritten. I think better default would be 120%, it may still look big somewhere
butnot as big as it does now and it compensates for that monospace vs normal font default size.<br /><br /><pre
class="moz-signature"cols="72">--
Regards
Petr Jelinek (PJMODOS)</pre>
On Mon, Sep 28, 2009 at 07:33, Petr Jelinek <pjmodos@pjmodos.net> wrote:
> Dave Page napsal(a):
>
> On 9/27/09, Petr Jelinek <pjmodos@pjmodos.net> wrote:
>
>
> Dave Page napsal(a):
>
>
> Anyway those #txtArchives pre and #txtArchives tt do not affect
> documentation but they indeed seem to be plain wrong, they are actually
> only
> used by Opera (and maybe Chrome , I don't have that browser) and the text
> looks huge there. In FF and Safari they are overwritten by
>
> #pgContainer code, #pgContainer pre, #pgContainer tt {
> font-size: 1.2em;
> }
>
> in geckofixes.css (yes it loads for Safari too on my machine and it's a
> good
> thing) and in IE they're overwritten by
>
> * html #txtArchives pre { font-size: 100%; }
>
> in iefixes.css.
>
>
>
> txtArchives is used by archives.postgresql.org, not the docs.
>
>
>
> Cite from the first sentence: *Anyway those #txtArchives pre and
> #txtArchives tt do not affect
> documentation*
>
>
>
> Yes, i did read what you wrote. I was pointing out what they do affect.
>
>
> Oh, ok, I know they affect mail body in archives and all I said is true -
> they are overwritten by other rules in most browsers and the text is huge in
> browsers where they're not overwritten. I think better default would be
> 120%, it may still look big somewhere but not as big as it does now and it
> compensates for that monospace vs normal font default size.
Just to take this off on a slight tangent... You seem pretty
well-versed in CSS, right? ;) Any chance we can convince you to try to
do some cleanup work on our CSS, structuring it nicer and also getting
some comments in there so us mere mortals can understand it? That
would be a *very* welcome piece of help!
If you are, please contact me off-list before you start actually
working, I have some partial pieces of work you'll be interested in
:-)
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Petr Jelinek wrote:
> >>> The actual code that is causing a problem in my browser is in
> >>> geckofixes.css:
> >>>
> >>> #docContainer tt, #docContainer pre, #docContainer code {
> >>> font-size:1.4em;
> >>> }
> >>>
> >>>
> >> I am not on www team but I bet it's because with 1em (100%) the text is
> >> tiny in Firefox under Windows in those elements.
> >>
> >
> > So why is that? Is this a known bug in Firefox? Is it documented? Can
> > we apply the fix only to broken Firefox versions? The lack of comments
> > in the CSS file makes this issue unclear to me.
> >
>
> It's known behavior, not a bug.
> By default FF on Windows (not sure about other OSes, but on Jaunty my FF
> does it too), Safari, Chrome all choose 13px font size for monospace and
> 16px for everything else (so maybe you changed default font size for
> monospaced fonts in your FF?). And since we have 76% (docs) and 69%
Yes, I did change my default font sizes in Firefox, which explains why
most people are not seeing the problem.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Magnus Hagander wrote: > > Oh, ok, I know they affect mail body in archives and all I said is true - > > they are overwritten by other rules in most browsers and the text is huge in > > browsers where they're not overwritten. I think better default would be > > 120%, it may still look big somewhere but not as big as it does now and it > > compensates for that monospace vs normal font default size. > > Just to take this off on a slight tangent... You seem pretty > well-versed in CSS, right? ;) Any chance we can convince you to try to > do some cleanup work on our CSS, structuring it nicer and also getting > some comments in there so us mere mortals can understand it? That > would be a *very* welcome piece of help! > > If you are, please contact me off-list before you start actually > working, I have some partial pieces of work you'll be interested in > :-) Yes, please. I just finished reading a book about CSS so I understand the syntax, but obviously not the historical quirks. I would like to be involved as well. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I would like to close out this issue. Can we get whatever improvements we can make implemented in our web site, even if it is only comment additions? --------------------------------------------------------------------------- Bruce Momjian wrote: > Magnus Hagander wrote: > > > Oh, ok, I know they affect mail body in archives and all I said is true - > > > they are overwritten by other rules in most browsers and the text is huge in > > > browsers where they're not overwritten. I think better default would be > > > 120%, it may still look big somewhere but not as big as it does now and it > > > compensates for that monospace vs normal font default size. > > > > Just to take this off on a slight tangent... You seem pretty > > well-versed in CSS, right? ;) Any chance we can convince you to try to > > do some cleanup work on our CSS, structuring it nicer and also getting > > some comments in there so us mere mortals can understand it? That > > would be a *very* welcome piece of help! > > > > If you are, please contact me off-list before you start actually > > working, I have some partial pieces of work you'll be interested in > > :-) > > Yes, please. I just finished reading a book about CSS so I understand > the syntax, but obviously not the historical quirks. I would like to be > involved as well. > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > -- > Sent via pgsql-www mailing list (pgsql-www@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-www -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
On Tue, Feb 23, 2010 at 2:09 AM, Bruce Momjian <bruce@momjian.us> wrote: > > I would like to close out this issue. Can we get whatever improvements > we can make implemented in our web site, even if it is only comment > additions? Given that we've been actively working to get it redesigned entirely (albeit that the effort is on hold atm largely due to 9.0), I for one have no desire to spend time trying to untangle the CSS just to add comments that virtually noone is likely to ever read. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Dave Page wrote: > On Tue, Feb 23, 2010 at 2:09 AM, Bruce Momjian <bruce@momjian.us> wrote: > > > > I would like to close out this issue. ?Can we get whatever improvements > > we can make implemented in our web site, even if it is only comment > > additions? > > Given that we've been actively working to get it redesigned entirely > (albeit that the effort is on hold atm largely due to 9.0), I for one > have no desire to spend time trying to untangle the CSS just to add > comments that virtually noone is likely to ever read. Oh, I wasn't aware we were moving forward with a redesign. I assume the redesign will have comments. ;-) Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
On Tue, Feb 23, 2010 at 2:36 PM, Bruce Momjian <bruce@momjian.us> wrote: > Dave Page wrote: >> On Tue, Feb 23, 2010 at 2:09 AM, Bruce Momjian <bruce@momjian.us> wrote: >> > >> > I would like to close out this issue. ?Can we get whatever improvements >> > we can make implemented in our web site, even if it is only comment >> > additions? >> >> Given that we've been actively working to get it redesigned entirely >> (albeit that the effort is on hold atm largely due to 9.0), I for one >> have no desire to spend time trying to untangle the CSS just to add >> comments that virtually noone is likely to ever read. > > Oh, I wasn't aware we were moving forward with a redesign. I did run it past -core before we started, and then publicly invite designers to submit proposals :-) > I assume the > redesign will have comments. ;-) Thanks. Yep. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do