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

marc 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 
is 
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 
acceptance.

> > 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' />
  <!--HTMLHeader-->
  </head>

PmWiki comes in last (ignoring local customization), but in this case 
coming in last means that it wins. But, as we established before, by 
using:

  <!--HTMLHeader-->
  </head>

and adding the following to skin.php

  global $HTMLHeaderFmt;
  $HTMLHeaderFmt['skin'] = 
  "<link rel='stylesheet' href='\$SkinDirUrl/skin.css' 
     type='text/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 
customizations.
 
> 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' />
>     <!--HTMLHeaderFmt-->
> 
> 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.

-- 
Best,
Marc





More information about the pmwiki-users mailing list