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

[Joachim Durchholz]

H. Fox schrieb:
> 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.

They could be color-coded. (With the obvious disadvantage that the links 
might be hard to tell apart for the color-blind. Reducing the color 
palette to two colors might help testing for that... unfortunately, 
Windows usually doesn't give that option.)

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

That's OK with me. I'm adverse to absolute font sizes, not to specifying 
no font size at all!

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

I'm not sure how the various Unix desktops interpret font sizes. They 
might have yet another idea of what 10pt is. (IIRC font sizes are 
interpreted by X; if that's the case, checking a single browser on a 
Unixoid box should suffice to judge this kind of stuff.)

>>>>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; }

I don't think that's a good idea. This looks like just the kind of fix 
that will work in some browsers, and introduce problems in others.

If this annoys me enough, I'll fire up Firefox and look at the specified 
and computed margins, and check what's interfering how. I'd have to be 
*very* annoyed though, and with some time to spare on hand...

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

Argh...

But then we're back with a glitch. I get more whitespace below than 
above a heading if I do

   Content

   !! Heading

   Content

Regards,
Jo