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

[Hans]

Tuesday, October 31, 2006, 4:41:22 AM, Patrick wrote:

> On Mon, Oct 30, 2006 at 10:17:32PM +0000, Hans wrote:
>> 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.

I resolved this now. The conflict was with the skin's loading sequence
of css modules.

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

I will try to test this when I work on FixFlow, since it is used
there. Right now I got Triad to load all css late.

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

Oh yes, direct and simple...!

For the skin development I think I will use a variable in the
template, and some mechanism to check the pmwiki version, so a new
version, which distributes the pmwiki-core.css file, will use this,
whereas older versions can fall back on a core.css file within the
skin/css/ directory.

Do you think admins want an option to use the default pmwiki core
styles (via HTMLStylesFmt) instead of a core.css file. I could add a
variable to the skin: SDV($EnablePmWikiCoreCss, 1); to facilitate a
switch.

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

Okay.

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

Okay. It appears I had my own set of troubles with the upgrade because
I had not upgraded a recipe and it introduced all kinds of weird
behaviour. Since $EnableRelativePageVars is still off by default the
old skin versions still work, I only realise this now.

Thank you for this for me very fruitful discusion, which gave me many
ideas for improving css handling in the skin!


Hans