[pmwiki-users] pmwiki skin

Petko Yotov 5ko at 5ko.fr
Mon Aug 27 10:22:18 CDT 2012


Keep in mind that such a change in the "default" skin will have consequences  
not only on new wikis, but also on any wiki which is upgraded and has some  
recipes. Which may change the appearance of the site without the user having  
asked for anything.

If we don't have a way to enable this kind of disruptive changes only on new  
wikis, even if the pros are more than the cons, we shouldn't force them.

In the case of pmwiki.css before the HTMLHeader, there is one feature that  
wasn't mentioned, the local files pub/css/local.css, pub/css/Group.css and  
pub/css/Group.Page.css that are loaded after the css file of the skin.  
Having it after pmwiki.css (or anyskin.css) allows a wiki to adapt the  
appearance of the skin more easily.

The current order seems to me very good, even if we didn't have existing  
wikis that would break when we change it. The current order is:

- pmwiki.css (or anyskin.css, if the skin author respected the order)
- $HTMLStylesFmt from the core and from recipes, in a <style> block
- from pub/css/ : local.css, Group.css and Group.Page.css in that order if  
they exist

So, we are unlikely to change that order for the default skin. Skin authors  
may select a different way if they have reasons for it.

Petko

V.Krishn writes:
> On Sunday, August 26, 2012 11:18:13 PM Carlos AB wrote:
> > There is just one thing I don't fully agree with, that is to change
> > the position of pmwiki.css, as I believe the <style>...</style> area
> > is really good, because it gives recipe writers a dynamic space and a
> > chance to override permanently or eventualy a css rule defined within
> > pmwiki.css .
>
> A. pmwiki.css BEFORE <!--HTMLHeader-->
> ---------------------------------------------------
> Pros:
> 1. Various methods of overrides available.
> Cons:
> 1. All overrides should take care that the basic essence or structural
> integrity of the skin is not broken, hence mostly resort to styling via
> specific Class or Id.
>
> B. pmwiki.css AFTER <!--HTMLHeader-->
> ---------------------------------------------------
> Pros:
> 1. Since most overrides are styled using specific Class or Id, this placing  
> of
> pmwiki.css should rather help in preserving the basic essence or structural
> integrity of the skin. Hence, to make best of this setting, recipe writers
> should refrain from generic styling for overriding.
> Cons:
> 1. Only generic styling should(recommended) be used in pmwiki.css.
> 2. Ensuring generic overrides not be used in recipes.
>
> >
> > But either before or after a new css rule can replace another trough
> > it's specificity, but I believe the current way is just more
> > convenient.
>
> Yes, this setting works for recipes I used so far.
>
> No usage or scenario has been given for the requested change.
> If preserving the design intent(theme) of the skin is a concern,
> css guidelines can be written for recipe writers.
>
> >
> > Since the dynamic area is not accessible to users (just if trough a
> > recipe) there are no major dangers for the wiki site and while doing
> > that makes things simple for the user, the admin and recipe writer.
> >
> > If you want to impose a hard restriction, even for recipes, just load
> > another file bellow the dynamic section and make the selector very
> > specific.
> >
> > CarlosAB




More information about the pmwiki-users mailing list