[Pmwiki-users] Modular configurable skin

[Bronwyn Boltwood]

On Sat, 15 Jan 2005 07:25:23 -0700, Patrick R. Michaud
<pmichaud at pobox.com> wrote:
>     $CSSToggles[] = array(
>       # uncomment any of the below to enable
>       # 'font-face-verdana.css',
>       # 'font-face-times_new_roman.css',
>       # 'font-face-h_georgia-b_verdana.css',
>       # 'sidebar-orientation-left.css',
>       # 'sidebar-orientation-right.css',
>       );

So I can put the above into either config.php or skin.php as I please.
 But what exactly does this chunk do and how do I use it?

   global $HTMLHeadersFmt;

  $spage = ReadPage('Skin.StyleConfig');
  preg_match_all('/^link "(.*?\.css)"/m', $spage['text'], $m);
  foreach($m[1] as $css)
    $HTMLHeadersFmt[] =
      "<link rel='stylesheet' type='text/css' href='\$SkinDirUrl/$css' />";

I guess we're getting mixed up because not all the examples are
numbered!  I've been using answer #1 and answer #2 to denote the
chunks that you labelled as such in your mail, whereas the $CSSToggles
solution wasn't given a number at all.

> I don't disagree with your first point, but there are in fact reasons
> for using a table-based design besides simply catering to older
> browsers.  Tables can often handle things (such as dynamic columns)
> much more simply and straightforwardly than CSS can, because CSS
> really doesn't understand things like "variable numbers of columns" or
> "vertical positioning relative to the bottoms of other elements on the page".

Turning off a column is one of those interlocking problems where you
need to know the code well to get it right.  Thanks for reminding me
that I need to write feature-sidebar-off.css.  BTW, I found a tip on
vertical positioning:
http://www.positioniseverything.net/articles/top-prop.html.

I have been banging my head against the problem of multi-columned
liquid design for some time now.  Between the bugs and the rounding
errors, CSS layouts can be fragile enough to make you cry, especially
when using percentage widths.  We need a flexible yet forgiving way to
define a page grid without changing the HTML or adding nonsemantic
elements to avoid layout breakage.  Currently, CSS is way flexible,
but not forgiving.  If it had a layout mode that left more margin for
error and browser window resizing, and knew that all the boxes should
stick together and fit in a rectangle unless specifically told not to,
we'd all be a lot happier.

> Also, does the skin you're working on make much use of floating elements
> to create various components?  I've found that floats in the outer layout
> really run into problems when authors want to add floating elements of
> their own (images, tables) into the page content.

Static full-width masthead, two floated columns, and a footer that
clears them.  Now that I found the fix for the unscrollable content
bug, I could probably switch to absolute positioning, since I don't
insist on a full-width footer.  Would that be worthwhile in
development time?

Floats have bugs in any browser.  In Internet Explorer, they have
*lots* of bugs.  If the most common float bugs don't vary by skin, and
can be fixed by some inline hack on the float, then maybe the wiki can
add it automagically.  We'd probably have to get some examples to know
exactly which we're running into, but here are some materials that
might help to diagnose and fix them:
	http://www.positioniseverything.net/explorer/floatmodel.html
	http://www.positioniseverything.net/articles/float-bugs-1.html
	http://www.positioniseverything.net/articles/common.html
	http://www.positioniseverything.net/explorer/doubled-margin.html
	http://www.positioniseverything.net/explorer/threepxtest.html
	http://www.positioniseverything.net/explorer/escape-floats.html

> It's not only a matter of providing the options that would suit a lot of
> people, the PmWiki default layout needs to be simple enough that if a
> particular option isn't already built-in to the skin, someone (without
> a lot of HTML or CSS experience) could sort of have an idea where they
> might start changing things so they could begin adding it.

That's the other reason why I wrote up a range of options (especially
the core layout options!) -- to be built-in examples, divided up by
function.  While it's more trouble to write them that way, I've found
it's less trouble to modify and maintain.  E.g. if you want to write
your own colour scheme, ALL the colour selectors being used are in the
colour-something.css file, instead of scattered all over the place.

> And your approach has given me a few ideas for other ways to
> adjust the layout to avoid tables... :-)

Ah, good.  :)  I've added internal navigation links (skip to nav, back
to top, back to content), but am not yet sure how to hide them safely,
because -- guess what -- you can't just use display:none, or
visibility:hidden, or aural stylesheets, because the freakin' screen
readers don't support aural stylesheets, and ignore the hidden links! 
Similarly, many mobile browsers don't support the handheld media type,
but instead fetch the desktop stylesheets.  I think there'd be more
accessible sites out there if the software for the people that
need/want them didn't foil our efforts to render them accessible.  My
current plan is this:
	-going by some recent reading, browsers for mobile devices and the
disabled need single-column liquid layouts that put content first, and
styles which above all do no harm.
	-any layout I come up with will probably break in older browsers anyway.
	-so I'll apply the simple styles like fonts and colours, which
shouldn't cause any serious trouble, because I use relative units and
medium to strong contrast.
	-then I'll use high- and/or mid-pass filters to feed the advanced css
to the browsers that *should* be able to handle it.
	-as a backup, I'll probably create a second, no-frills template that
is pure unstyled html with internal navigation links and content-first
source order, and add a sidebar link to it, just in case none of the
rest bloody worked.

Anyway, to use both CSS-based layouts and configurable stylesheets,
the way I'd like to, I need a way to put a certain list of stylesheets
in as links, and a different list in as @import rules, or surrounded
by the appropriate hack or what have you.  I can probably edit the
$CSSToggles solution to do that (or at least get close), but I don't
know enough about PHP to figure out the other two.

Bronwyn