[pmwiki-users] Problems with the embedded CSS in pmwiki.php
Patrick R. Michaud
pmichaud at pobox.com
Mon Oct 30 22:41:22 CST 2006
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
More information about the pmwiki-users
mailing list