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

[H. Fox]

On 2/17/06, Joachim Durchholz <jo at durchholz.org> wrote:
> 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.

I see what you mean, but I still think most people would prefer the
default style -- at the expense of some usability -- for purely
aesthetic reasons.

Maybe there's something in between, where links can be distinguished
from non-links in a more subtle fashion.

> >>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!

I became convinced a long time ago, but I can't remember the specific details.

At any rate, it'll be "0.9em" in the next iteration.  That shold be about right.

> 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).

That has implications for the entire stylesheet.

Hopefully someone out there with a Mac will report in.

> '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).

I've seen far more usage of 'em', and I've read things that convinced
me 'em' is better.

Anyone else know about this?

> > 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.

Good idea.

> >>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.

Well, not completely it turns out.  The space is one pixel narrower
immediately above and below a nested list.  This might be an adequate
fix for that:

#wikileft ul ul { padding-top:1px; padding-bottom:1px; }

> 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.

The <p class="vspace"> comes from <newline><newline> and that
(potentially) makes the page's appearance match the wiki markup;
producing more space with a blank line below a heading, less space
without.  I prefer it that way, but I can also understand the other
point of view.

The same issue exists for whitespace *above* headings, btw...

   Content
   !! Heading

can look different than

   Content

   !! Heading

> 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).

Good idea.  If authors are going to be denied control over whitespace
below headings, then that seems like the way to do it.

Hagan