[Pmwiki-users] Modular configurable skin

[Bronwyn Boltwood]

On Mon, 10 Jan 2005 16:08:32 -0700, Patrick R. Michaud
<pmichaud at pobox.com> wrote:
> In my experience, most admins are pretty quick to create their
> own, or modify an existing skin .tmpl file in ways that cannot be
> done solely through CSS.

Maybe I underestimated the potential market. ;) I was under the
impression that there were a lot of new administrators unfamiliar with
CSS, but who'd like to make changes that are simple visually, but
whose CSS can be tricky.  Even dead-simple changes (like Neil's red
wikimessage question) can be foiled by specificity and the cascade, so
having a pile of examples with selectors that are known to *work* is a
huge asset, even if you do copy the directory and start editing.

Just about every skin in the cookbook is a two column job with header
and footer.  (Do a lot of PmWiki sites in the real world have
something substantially different?  If not, then we definitely have a
core layout.)  What goes in the sidebar column is the site's
responsibility.  The remainder consists of features enabled,
whitespace, borders, colours/backgrounds, and fonts, and this is where
most site designs differentiate themselves.  We can certainly achieve
one-size-fits-most.

> Second, it assumes that most of the CSS things an admin would be interested
> in are "toggleable".  But a lot of things -- widths, colors, etc.
> aren't on/off values (although I'll concede we could toggle palettes
> of these items).

I never meant this system to let people define their own values for
everything.  I meant to offer a small selection of choices for admins
new/busy enough to need some serious hand-holding.  I figured that
those whose sites are tools instead of toys would be happy to trade
some customizability for simplicity and convenience.  The power to
tweak to their hearts' content is available when they're ready for it.
 I do think, though, that our simple-and-convenient crowd might like
to set a background image or colour, both of which would need user
input beyond commenting or uncommenting a line.

> Answer #1:  If you want to toggle stylesheets in wiki pages, just do
> it directly from skin.php:

Correct me if I am wrong.  

1. Answer #1 requires the skin to have a skin.php with the code given,
and fetches the configuration from the wikipage specified, which can
of course be included in the skin package.  What is the correct
syntax, and how would I (un)comment lines?  All I can tell from
reading it is that it's replacing regular expressions with .css in
them, and putting them inside a link statement.
2.  Answer #2 creates a directive to apply a stylesheet per page or
per group.  Nifty.

I have another hurdle for you: certain stylesheets need to be hidden
from older browsers, because they can't render them correctly, or even
readably.  While I can guess how to hack the config.php method, I am
not sure how to do it for answers #1 and #2.  I think this is
important for compatibility, especially since I was designing this as
a replacement for the default skin.  It should at least be readable in
*everything*.  Somebody is probably thinking "why not just use a table
layout instead?".  A tableless design is much more semantic, and
therefore more accessible for *all* kinds of user agents: visual
browsers, text-based browsers, screen readers, handhelds, cellphones,
and so on.  Depending on your site's audience, the percentage of
people using these could be close to, or even beyond the percentage of
people using browsers from 1999 or before.  I can design in "skip to
navigation", "back to top" and "back to content" links that shouldn't
show in browsers that don't need them.  A table-based design will
inconvenience unusual browsers in order to cater to elderly browsers. 
I don't think that's such a good tradeoff.

> But the key to making *any* of this work would be to first come up
> with an HTML template file that could adequately abstract out all of
> the desired options into CSS -- somehow I don't think that's likely.
> That's not to say it isn't worth trying.  :-)

I couldn't resist trying.  While it hasn't had much real-world
debugging, I've already abstracted out the following:
-core layout -- variations on two columns plus header and footer:
	-layout-fixed56em-leftsb-14em.css -- fixed-width centered, left
sidebar 14em wide, proportions: 1/4 sidebar, 3/4 body
	-layout-fixed56em-rightsb-14em.css -- fixed-width centered, right
sidebar 14em wide, proportions: 1/4 sidebar, 3/4 body
	-layout-fixed72em-leftsb-24em.css -- fixed-width centered, left
sidebar 24em wide, proportions: 1/3 sidebar, 2/3 body
	-layout-fixed72em-rightsb-24em.css -- fixed-width centered, right
sidebar 24em wide, proportions: 1/3 sidebar, 2/3 body
	-layout-liquid-leftsb-14em.css -- liquid full-screen, left sidebar 14em wide
	-layout-liquid-leftsb-27em.css -- liquid full-screen, left sidebar 27em wide
	-layout-liquid-rightsb-14em.css -- liquid full-screen, right sidebar 14em wide
	-layout-liquid-rightsb-27em.css -- liquid full-screen, right sidebar 27em wide
-navigation list layout (CSS tabs)
-special features:
	-feature-attr-off.css -- no "change attributes" links
	-feature-author-off.css -- no authoring links
	-feature-feed-off.css -- no RSS-related stuff
	-feature-navlink_underlines-off.css -- no underlines on navigation links
	-feature-upload-off.css -- no upload links
-base font size (76%, 85%, 100%, or 115%)
-font combinations (14 so far, all using common web fonts), set in
these groups: body text, navigation text, headers, and titles.
-font proportions -- stuff like how big is a header compared to a
navigation link
-whitespace and decor -- this is the difficult part; tiny changes to
whitespace and borders can break the layout.  I'm not making any more
decors because of that; I have real work to do too.
-colour schemes (though it's a bit tricky)

So, what else would need abstracting out?  I couldn't make the core
layout attributes as mix 'n' match as I wanted to; too much of it
interlocked.  I was able, however, to provide a range of options that
should suit a lot of people.

Setting properties for the active tab *per colour scheme* might make
me pull my hair out, though.  Previous experience showed that the
magic selector had to live in the .tmpl file to work...

> or content.  This is especially true of those designs that use CSS to
> load in graphic images of the headings and text.

You can get similar dynamic effects with SIFr
(http://www.mikeindustries.com/blog/archive/2004/08/sifr), though I
have not tried combining it with PmWiki.

> it's possible to globally modify the structure and organization of
> pages without also having to edit the content portion of the pages.

Why do you think I like using PmWiki to run my personal site?  I can
hand-code, but for more than one page, it's much easier on me to have
presentation, site structure, navigation, page structure (what divs
where), and content all separated from each other. :)

Bronwyn