[Pmwiki-users] Modular configurable skin

[Patrick R. Michaud]

On Fri, Jan 14, 2005 at 11:34:47PM -0500, Bronwyn Boltwood wrote:
> > 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.

No, answer #1 wasn't intended to allow specification from a wikipage;
it was intended to be done the same way most other PmWiki configuration
is done.  For example, skin.php can contain:

    $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',
      );

and the admin can enable certain skin features simply by uncommenting
any of the lines above, which would then cause the corresponding
.css file to be loaded via a <link> element.

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

There's no substantial difference between a skin.php and a config.php, 
except that a skin.php file is loaded and executed when the skin is loaded
(and the variables in skin.php aren't global unless declared global).

> [...]  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.  [...] A table-based design will inconvenience unusual 
> browsers in order to cater to elderly browsers. 

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

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.

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

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.

None of this is intended to contradict or rebut anything you wrote;
I'm simply providing more perspectives and ideas on the topic.
And your approach has given me a few ideas for other ways to 
adjust the layout to avoid tables... :-)

Pm