[pmwiki-users] Problems with the embedded CSS in pmwiki.php
gmane at auxbuss.com
Sun Oct 29 12:21:22 CST 2006
Patrick R. Michaud said...
> Unfortunately, I only have time for quick responses at the moment
> (but will post more detailed items later)...
> On Sun, Oct 29, 2006 at 04:00:10PM -0000, marc wrote:
> > This means that the skin template is always overridden by PmWiki's
> > embedded styles. This wouldn't be a problem were PmWiki's embedded
> > styles restricted to classes or ids, but they include ul, ol, pre, dl
> > and p. [...]
> > This presents a problem where the "design" task is performed by someone
> > other than a PmWiki admin, since it means that the output produced by
> > the template might be other than as defined in the template. (I know
> > that all of us here can deal with, but that's not the general case.)
> Ummm, I don't understand. If all of us can deal with it, isn't
> *that* the general case? Put another way, I don't understand what
> is meant by "the 'design' task is performed by someone other than
> a PmWiki admin".
I'm playing devil's advocate here for users that lack PmWiki experience.
Many places I go, there are those responsible for the "design" - which
frequently based on a Dreamweaver template and the use of Photoshop -
and the admins/coders. When introducing PmWiki - or similar - that
delineation is firmly embedded. "Management" usually see the benefits of
dynamic page generation, the ease of editing their site, and other
benefits that PmWiki can bring them, which will depend on their
circumstances and requirements, but the web team usually have the power
of veto, and encroaching on their established domains is likely to be
sufficient for them to exercise it. Hence, the separation of CSS and
code - as they perceive it - would present one less barrier to
> > What I suggest is that the skin template should always "win". Now, that
> > probably means that it should come after all styles and JS, but before
> > local customizations.
> The admin always wins, but the skin template comes in second. PmWiki
> comes in last.
In the recommended case:
<link rel='stylesheet' title="Skinname"
href='$SkinDirUrl/Skinname.css' type='text/css' />
PmWiki comes in last (ignoring local customization), but in this case
coming in last means that it wins. But, as we established before, by
and adding the following to skin.php
"<link rel='stylesheet' href='\$SkinDirUrl/skin.css'
the skin template wins by coming last.
> > > As one might expect with PmWiki, there are other options... :-)
> > >
> > > Short answer: The short answer is that a skin that wants to
> > > override the pmwiki.php embedded styles can do the following
> > > in skin.php:
> > >
> > > global $HTMLStylesFmt;
> > > $HTMLStylesFmt['skin'] = "...css overrides here...";
> > Yes, but then the skin CSS is in two locations. It's not the end of the
> > world, of course, but it is an inelegant solution and it's a little
> > error prone. And the embedded styles are still there.
> The skin CSS doesn't _have_ to be split in two locations -- all of
> the skin's CSS can go in $HTMLStylesFmt['skin'].
I dislike this personally because it has the effect of embedding the CSS
into the HTML page. But that's just me. Playing devil's advocate again,
the CSS file no longer exists (as a CSS file) and the designers would
resist. They will likely perceive that it breaks their tools, since they
are used to clicking on a .css file in their file manager and for it to
open in their tool of choice, or right-click and select a tool. Now, I
could leave the CSS in place and write the code to include the CSS file
in $HTMLStylesFmt['skin']... But this is moot since the earlier example
is a better solution. As you say:
> Or it can all
> go into a skin-specific css file that is loaded between the PmWiki
> default and the local customizations.
> > > A skin that wants to completely replace the pmwiki.php defaults
> > > with its own can do the following in skin.php:
> > >
> > > global $HTMLStylesFmt;
> > > $HTMLStylesFmt['pmwiki'] = '';
> > This method has the problem that future addition or amendments to
> > PmWiki's embedded styles are lost. I started down this route and
> > disliked it because odd embedded styles would pop up from time to time;
> > say, with the FAQ. The problem being that PmWiki's embedded styles
> > aren't in a single location, and can't easily be listed.
> > If all the PmWiki styles were in a single CSS, then it would be easy to
> > check for clashes and make adjustments.
> What exactly do you mean by "all the PmWiki styles"? Are you saying
> that we should include styles defined by modules that aren't even
> being loaded?
Yes. Well, I'm suggesting examining the idea; the idea that all
currently embedded PmWiki styles are included in a single CSS file that
is loaded prior to the skin template, followed by the local
> And where (in the distribution) should the single CSS be located?
> (Has to be somewhere under pub/ , but where?)
It could live alongside pub/css/local.php. Perhaps there's a case for it
being alongside pmwiki.php. I think that you are a far better judge of
that decision than me.
> > > In the past many have indicated that we should "dis-embed" the CSS
> > > from pmwiki.php, and require every skin author to include these
> > > minimal definitions (possibly modified) in the skin's .css file.
> > Would it not be better to do as you've noted above and simply add a
> > <link rel='stylesheet'> for the proposed "core" CSS file to, say,
> > $HTMLStylesFmt? That way there is no onus on the skin author to do
> > anything.
> $HTMLStylesFmt can only contain CSS properties, it can't contain
> HTML. I suspect you mean $HTMLHeaderFmt here.
> But even if it's in $HTMLHeaderFmt, we're still left with the
> problem that using
> <link rel='stylesheet' href='$SkinDirUrl/skin.css' type='text/css' />
> still causes the core CSS definitions to override the skin's definitions.
Sorry, I was probably getting confused. But you saw what I was getting
at. And yes, $HTMLStylesFmt['skin'] is too late in this case.
> > Absolutely. I wholeheartedly support that statement. Indeed, what I have
> > suggested increases the decoupling.
> I haven't had a chance to thoroughly think about what you've written,
> but so far to me it seems like exactly the same amount of decoupling.
I humbly submit that I am not in a position to fully understand the
repercussions of the suggestion. However, I do see the decoupling of
PmWiki styles from within the code to a regular CSS file as beneficial.
> > I hope I have made a decent case for an alternative approach that
> > retains this ideal and provides more visibility of what comprises the
> > core styles, and is, imo, a lot easier to manage. (It is also a little
> > more efficient - less code generated per page, CSS cached client-side -
> > and diff'ing PmWiki's embedded style changes from version to version is
> > simplified.)
> It may be a slightly less efficient in that we're then including styles
> that may not be needed. (I agree that this may be insignificant or
> a wash in the final analysis.)
I think so :-) One is cached vs. repeated sends of embedded styles.
Swings and roundabouts as we say over here.
More information about the pmwiki-users