[pmwiki-users] Problems with the embedded CSS in pmwiki.php

Patrick R. Michaud pmichaud at pobox.com
Sun Oct 29 10:28:19 CST 2006


Unfortunately, I only have time for quick responses at the moment
(but will post more detailed items later)...

On Sun, Oct 29, 2006 at 04:00:10PM -0000, marc wrote:
> This means that the skin template is always overridden by PmWiki's
> embedded styles. This wouldn't be a problem were PmWiki's embedded
> styles restricted to classes or ids, but they include ul, ol, pre, dl
> and p. [...]
> 
> This presents a problem where the "design" task is performed by someone
> other than a PmWiki admin, since it means that the output produced by
> the template might be other than as defined in the template. (I know
> that all of us here can deal with, but that's not the general case.)

Ummm, I don't understand.  If all of us can deal with it, isn't
*that* the general case?  Put another way, I don't understand what
is meant by "the 'design' task is performed by someone other than
a PmWiki admin".

> What I suggest is that the skin template should always "win". Now, that
> probably means that it should come after all styles and JS, but before
> local customizations.

The admin always wins, but the skin template comes in second.  PmWiki
comes in last.  

> Can PmWiki facilitate this? As you point out below, it can.

Exactly.

> > As one might expect with PmWiki, there are other options... :-)
> > 
> > Short answer:  The short answer is that a skin that wants to 
> > override the pmwiki.php embedded styles can do the following 
> > in skin.php:
> > 
> >     global $HTMLStylesFmt;
> >     $HTMLStylesFmt['skin'] = "...css overrides here...";
> 
> Yes, but then the skin CSS is in two locations. It's not the end of the
> world, of course, but it is an inelegant solution and it's a little 
> error prone. And the embedded styles are still there.

The skin CSS doesn't _have_ to be split in two locations -- all of
the skin's CSS can go in $HTMLStylesFmt['skin'].  Or it can all
go into a skin-specific css file that is loaded between the PmWiki
default and the local customizations.

> > A skin that wants to completely replace the pmwiki.php defaults
> > with its own can do the following in skin.php:
> > 
> >     global $HTMLStylesFmt;
> >     $HTMLStylesFmt['pmwiki'] = '';
> 
> This method has the problem that future addition or amendments to
> PmWiki's embedded styles are lost. I started down this route and
> disliked it because odd embedded styles would pop up from time to time;
> say, with the FAQ. The problem being that PmWiki's embedded styles
> aren't in a single location, and can't easily be listed.
> 
> If all the PmWiki styles were in a single CSS, then it would be easy to
> check for clashes and make adjustments. 

What exactly do you mean by "all the PmWiki styles"?  Are you saying
that we should include styles defined by modules that aren't even
being loaded?

And where (in the distribution) should the single CSS be located?
(Has to be somewhere under pub/ , but where?)

> > In the past many have indicated that we should "dis-embed" the CSS
> > from pmwiki.php, and require every skin author to include these
> > minimal definitions (possibly modified) in the skin's .css file.
> 
> Would it not be better to do as you've noted above and simply add a
> <link rel='stylesheet'> for the proposed "core" CSS file to, say,
> $HTMLStylesFmt? That way there is no onus on the skin author to do
> anything.

$HTMLStylesFmt can only contain CSS properties, it can't contain
HTML.  I suspect you mean $HTMLHeaderFmt here.

But even if it's in $HTMLHeaderFmt, we're still left with the
problem that using

    <link rel='stylesheet' href='$SkinDirUrl/skin.css' type='text/css' />
    <!--HTMLHeaderFmt-->

still causes the core CSS definitions to override the skin's definitions.

> Absolutely. I wholeheartedly support that statement. Indeed, what I have
> suggested increases the decoupling.

I haven't had a chance to thoroughly think about what you've written,
but so far to me it seems like exactly the same amount of decoupling.

> I hope I have made a decent case for an alternative approach that
> retains this ideal and provides more visibility of what comprises the
> core styles, and is, imo, a lot easier to manage. (It is also a little
> more efficient - less code generated per page, CSS cached client-side -
> and diff'ing PmWiki's embedded style changes from version to version is
> simplified.) 

It may be a slightly less efficient in that we're then including styles
that may not be needed.  (I agree that this may be insignificant or
a wash in the final analysis.)

> > In fact, in this sense pmwiki.php uses $HTMLStylesFmt[] in exactly the
> > same way that recipes do.  [...]
>
> Yes, but I, and I suspect other, have no compunction about hacking a
> recipe to fit, but simply don't want to do that with the core - it's 
> too much work to maintain, especially with multiple sites.

I don't understand the meaning of "hacking the core" here; to me,
using local customizations to change the value of PmWiki defaults
isn't "hacking the core", it's part of the PmWiki design.

Pm




More information about the pmwiki-users mailing list