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
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
