[pmwiki-users] Proposed Default Stylesheet (pmwiki.css)

[Joachim Durchholz]

H. Fox schrieb:
> On 2/16/06, Joachim Durchholz <jo at durchholz.org> wrote:
>>
>>1) Settings for "#wikileft a" were removed.
> 
> I think this was discussed when the skin was originally developed and
> the end result was arrived upon by consensus.

Hmm... I must have missed that discussion.
The current way to doing things is OK if everything in the sidebar is a 
link. Unfortunately, that breaks down horribly if the sidebar is a 
mixture of link and non-link stuff.

I have just installed the SkinChange recipe and added links to set the 
skins. Try navigating through the side bar on 
http://durchholz.org/jo/debian-install/Main/Debian?skin=pmwiki and 
you'll see how badly it works.

>>2) Removed the 10pt fontsize settings for "textarea, pre, tt, code".
>>Font sizes should be relative, so that people with poor vision can
>>increase font size everywhere. (I know, relative font sizes come with
>>their own sets of problems.)
> 
> This is a bug.  It was supposed to be only for "textarea", not the others.

I'm not even convinced that it should go into "textarea". After all, 
people with poor vision would like to see what they're typing, too!

Another reason to not give a fixed size is that it should look well on 
minority browsers, too. Window's idea of 10pt deviates considerably from 
what a Mac does (because they use different assumptions about screen 
resolution).

> Styling fixed-width fonts appears to be tricky business!

:-)

>>3) Also removed the bold font for "h1 code, h2 code, h3 code". Bold font
>>there is simply inappropriate if the heading is part <code>, part
>>normal. (See the "Get and run debootstrap" heading on my site.)
> 
> It was appropriate for the default monospaced font, but....

Seems as if switching fonts implies switching some sizing. Not news for 
typographers, I guess, but a lesson I relearn every time when doing 
typographic work, myself...

>>4) Added
>>   code, pre {
>>     color:#007f00;
>>     background-color:#eeeeee;
>>     font-family:Lucida Console,monospace;
>>   }
>>That Lucida Console font is just to make it easier to read on a Windows
>>platform.
> 
> I think this may be a case where tuning for one platform affects
> others negatively.  For example, from what I'm reading it turns out
> that using "monospace" nearly always hurts at least some platform. 
> (IIRC Safari in particular.)
> 
> Setting a font will potentially improve things significantly.  FWIW
> here's what seems to work best so far:
> 
>     pre, code { font-size:0.9em; font-family:'Lucida Console','Courier
> New',Courier; }
>     pre { line-height:1.2em; }

'ex' would probably be a better unit than 'em'. It's supposed to measure 
vertical space (this would differ for fonts with a different aspect ratio).
Unfortunately, the W3C seems to have made 'ex' a horizonal measure, too. 
Sometimes I'm wondering if they had *anybody* with at least some minimal 
typographic knowledge, such as from reading the TeXbook... :-( (the 
recommendations for heading sizes were an even more blatant error).

> The next release is forthcoming so it can be tested...

Will test that, thanks.

>>I use @@...@@ and [@...@] to mark server responses and text to type.
>>Colorcoding it makes it easier to select the right passages for
>>copy&paste. (That's something I've been wanting on pmwiki.org for a long
>>time. Just monospacing the text doesn't make it stand out well enough,
>>at least not for me. I think this kind of outlining monospaced text is
>>definitely appropriate for computer-related wikis;
> 
> It is.  Your site does a good job with fixed-width text.

Thanks.

> Maybe that should be a recipe when the default stylesheet is
> finalized...

Good idea.

> If something like this were enabled on pmwiki.org there would need to
> be a *bunch* of preformatted code fix-up.  :-)

pmwiki.org has the SetSkin recipe enabled, so PM could install a skin 
with such a change, and people with an interest in doing the fix-up 
could go through the site and check.

>>6) The vertical margins/paddings in <ul> and/or <li> are broken. If you
>>look at the side bar, you'll see that if there's a sequence of subitems,
>>the item heading them has less empty space above it than below. That's
>>just reverse of how it should be (if the empty space should be different
>>at all - I'd prefer if line distances were all equal, but would tolerate
>>slight differences).
>>This problem seems to be inherited from the 2.0 PmWiki stylesheet.
> 
> Actually, they aren't "broken" unless you remove the styling for links
> there (#1 above).  The visual effect that makes links /appear/ to have
> more whitespace above them is the underline.  To prove this out, try
> text-decoration:overline; on the links.

Awww... you're right.

 >>I just noticed that the same phenomenon applies to headings. The free
 >>space above them is less than the free space below them, and it should
 >>be just the other way round (they are logically associated with the
 >>following text after all).
 >
 > It should be the opposite.  See
 >
 > 
http://qdig.sourceforge.net/wiki-skins/sshots/Test/Archived/0060-HeadingsAndText-a.png
 >
 > Maybe it varies from browser to browser?  The solution may be to
 > explicitly set the margin above headings (which will take some tedious
 > testing).
 >
 > h1 { font-size:1.8em; margin-bottom:18px; }
 > h2 { font-size:1.4em; margin-bottom:16px; }
 > ...
 >
 > will become
 >
 > h1 { font-size:1.8em; margin-top:<something>; margin-bottom:18px; }
 > h2 { font-size:1.4em; margin-top:<something>; margin-bottom:16px; }
 > ...

Not 'px', that should be 'ex' or 'em'. After all, the margins should 
depend on font size.

 > Much fine-tuning was done with the margin-bottom values.  Note that
 >
 >     !! Heading
 >     Text
 >
 > and
 >
 >     !! Heading
 >
 >     Text
 >
 > display a slightly different amount of whitespace.  I originally had
 > even less space below heading but Pm commented that the above
 > difference...
 >
 > "is likely to be lost on many authors, meaning that same-level
 > headings on a page would likely end up with varying amounts of
 > whitespace between the heading and its subsequent text."

Indeed. I have been inserting blank lines below headings in the 
wikitext, simply because I perceive the heading as a separate paragraph. 
The heading lines don't stand out well enough if they are run into the 
next paragraph as in

--- snip ---
lorem ipsum blah aorh aoöweirhvgöerhv nhjva öeioruvhaöoeirhv aöoehv 
öldhvf aöidbeuraserhie aroöghea orhg aeöhgo3hr ladhv aiuhv aieulvhb 
laieuv aiuev laieurh vgieru haeisurh ae.

aöowih öaoeiruv hadkjhvaö kldjfhvöasld khfv asdbb.

aöorhvökd jhfk.hua .erkjhveio uvhkadjrvf hea. aöowh övoufhva ierughudv 
akdvh kajhrv aileughre7uv akjhv akjerhv iaegvriauehv ifgaeusrhviuae 
vgksdfhv aöskdvhö aslifz eruahiuvg haeruihawi fhawehaezvgadhgvkarhia 
hvkjshad vkjad hvaeraöwo rhaeohr ae.

!!blah
öoaerhg rglöawrk.

aeöorihv lödfhöas lrhawue rhoöaweh asdhiughawe lksagj lasgv klajdvrh 
akeluvg kaldjvh alkerv hae.

kajhrv aileughre7uv akjhv akjerhv iaegvriauehv ifgaeusrhviuae vgksdfhv 
aöskdvhö aslifz eruahiuvg haeruihawi fhawehaezvgadhgvkarhia hvkjshad 
vkjad hvaeraöwo rhaeohr ae. aöleghvöovfr hoöaeihrg ilöaeshra föawelrh 
vase vfawelöv.

aeöiorf oödshfvpawer ioöhgiawe urzwivaw
--- snip ---

 > so he Pm may prefer to take away the control in case some people can't
 > figure out how to use it.

The real problem here is that PmWiki generates a <p class="vspace"> 
after the <h2>...</h2>. That explains why there's too much whitespace 
below headings on my site: no browser difference, but PmWiki's 
translation to HTML.

PM routinely uses a blank line after each header line :-)
(as seen on http://pmwiki.org/wiki/PmWiki/ReleaseNotes)

Probably PmWiki should each any blank lines after headers.
Some rule like "If a line starts with !, eat any blank lines after it", 
before line splitting is done (yes it's ugly).
Or, even better, rework the HTML generation so that it isn't necessary 
to have vspace paragraphs. (That would probably be a *lot* of work 
though... but then empty paragraphs aren't How HTML/CSS Is Supposed To 
Be Done.)

Regards,
Jo