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

[Patrick R. Michaud]

On Mon, Oct 30, 2006 at 10:17:32PM +0000, Hans wrote:
> I just tried to create this sequence, but found that I needed to have
> some core skin layout styles already loaded first, thus:
> 
>   a. skin layout styles
>   b. core pmwiki styles
>   c. recipe styles/admin styles via HTMLStylesFmt
>   d. further skin styles (styling, colors, fonts, print styles)
>   e. local.css and other localisation styles
> 
> To add all skin styling late did not work. 

Hmmm, why is that?  If there's not a conflict, it shouldn't
matter; if there is a conflict, then we generally want the skin 
to be last anyway.

> Also a skin template may
> use conditional branching to inject browser specific css, all this is
> better done in the template.

Of course it can also be done in the skin.php.

> To get the pmwiki-core.css file loaded at second place I had to load
> it from within pmwiki.php, as outlined in a previous mail. Only that
> way will it be the first inserted after HTMLHeader. 

Why not load pmwiki-core.css from the template file?

    <link href='$FarmPubDirUrl/css/pmwiki-core.css' ... />
    <link href='$SkinDirUrl/skin.css' ... />
    <!--HTMLHeader-->

This, coupled with $HTMLStylesFmt['pmwiki'] = '' in skin.php,
gives exactly the desired sequence.

> > 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.
> 
> I fully understand your concern about breaking existing sites, as you
> also detailed in your previous post. And I am not in a position to
> judge how big a problem this may be. It may be good to hear from
> others about how how much of a problem it may be for them.

I don't think we'll hear from many others until/unless we change
the default, at which point we'll get a lot of "I upgraded and it
broke my site" comments (which is what I'd like to avoid).

> And if loading it from pmwiki.php
> via HTMLHeaderFmt is the best way to load it early, then we are left
> with an upgrade problem with some possible problems for existing
> sites, I agree. But perhaps not such a big problem, or less then the
> skins breaking now when upgrading to 2.2.0 without upgrading the
> skins, because of relative page variables (different issue I know!).

I disagree that the hassle for this is less than the relative page 
variable issue.  First, relative page variables should be an issue 
only for sites that turn on $EnableRelativePageVars -- the default 
is still the 2.1 behavior.  Second, in the overall scheme of things,
relatively few skins provide their own versions of pages/page content
that make use of relative page variables (triad, gemini, and fixflow
are the obvious standouts here, however).

Pm