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

[Patrick R. Michaud]

On Mon, Oct 30, 2006 at 07:52:29PM -0000, marc wrote:
> Patrick R. Michaud said...
> > On Mon, Oct 30, 2006 at 12:20:51PM -0000, marc wrote:
> > > I suspect that this CSS file would be loaded by default - so as not to 
> > > break the default install [where it would be loaded in any case, in your 
> > > scenario] and not to break any existing skins. 
> > 
> > Having the CSS file "loaded by default" doesn't at all resolve the
> > original issue that started this thread.  The only ways that a 
> > pmwiki-core.css file can achieve the desired semantics (admin
> > overrides skin overrides core) is by one of the following:
> > 
> >   - All templates explicitly load pmwiki-core.css at an appropriate location.
> > 
> >   - The skin has a skin.php file that manipulates $HTMLHeaderFmt.
> > 
> >   - We define an "automatically loaded skin.css" rule that adds
> >     a link to a per-skin css file between the pmwiki core CSS and
> >     any site-specific (local) CSS files.
> > 
> > Currently PmWiki goes with the second option.
> 
> I understand #1 and #2, and why #1 is undesirable as things stand.  I'm
> clearly missing something with understanding #3. I thought that since
> existing skins already include <!--HTMLHeader-->, then this could be
> used to trigger the generation of the <link rel='stylesheet' for
> pmwiki-core.css - in other words, a replacement for the embedded PmWiki
> core styles.

This is effectively what Hans has been advocating, and as noted
in my previous message, it doesn't work, or at least isn't substantially
different from what we have now.

Suppose a skin has the following in its template:

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

It makes no difference if the styles are coming from $HTMLStylesFmt,
$HTMLHeaderFmt, or anything else that manipulates the <!--HTMLHeader-->
directive.  Anything that is inserted in the output via <!--HTMLHeader--> 
will end up coming after the skin.css file and overriding its settings.
This is true regardless of whether the settings are coming from 
an embedded stylesheet or an external one.

And, of course, if we reverse the above

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

then skin.css overrides anything in <!--HTMLHeader-->, including
the administrative styles.  What we ultimately want is this sequence:

    a. core PmWiki styles
    b. recipe styles
    c. skin styles
    d. local/admin styles

But since <!--HTMLHeader--> is responsible for a, b, and d, the only
way to get skin.css in the correct location--that is, after core and
recipe styles but before local/admin styles--is to either have the
skin manipulate $HTMLHeaderFmt via skin.php (#2 of my earlier
message) or for the core to define a "automatically load skin.css" 
rule to put the skin's css file in the appropriate location (#3
in my earlier message, the one you said you were missing something).

> Automatically generating pmwiki-core.css is
> easy enough, so that it can be updated between PmWiki releases, and I
> can null the embedded styles in skin.php with:
> 
>   global $HTMLStylesFmt;
>   $HTMLStylesFmt['pmwiki']	= '';
>   $HTMLStylesFmt['diff']		= '';
>   $HTMLStylesFmt['simuledit'] = '';
>   $HTMLStylesFmt['markup']	= '';
>   $HTMLStylesFmt['urlapprove']= '';
>   $HTMLStylesFmt['vardoc']	= '';
>   $HTMLStylesFmt['wikistyles']= '';

Hmm, I didn't quite realize there were seven sets of things to
be nulled out (I knew there were a few, but didn't know that
this many existed).  I might be able to come up with a shortcut
for this.

And as I indicated in my previous message to Hans, I don't have a 
problem with the distribution including a pmwiki-core.css file 
that skins can use (and that will be kept up-to-date), I only have 
a problem with breaking existing sites if we start automatically
including that file by default.

Pm