[pmwiki-users] CSS in HTML pages

[Patrick R. Michaud]

On Thu, Jun 15, 2006 at 11:54:45PM +0200, Joachim Durchholz wrote:
> Patrick R. Michaud schrieb:
> > Sure, there are at least two easy ways to do it:
> > 
> > 1.  In pub/css/local.css
> > 
> >     .indent { margin-left:1.5em; }
> 
> I haven't tested this, but the CSS specs say that in cases of identical 
> specifity, the later style will win. In PmWiki, this means the 
> HTML-based CSS takes priority, i.e. the styles from pmwiki.css will be 
> of lower precedence.

Note that I said "pub/css/local.css", not "pmwiki.css".
The <link .../> tag for pub/css/local.css is guaranteed to appear
in the output *after* the setting of $HTMLStylesFmt, therefore
anything places in pub/css/local.css will occur later than
PmWiki's defaults and will "win".

> Hmm... I'd probably have to reverse the order in the skin: 
> <!--HeaderText--> first, then <link rel='stylesheet'...>.

This is generally expected.  In fact, I should change the pmwiki
skin to follow this model as well, so as not to throw off new
skin designers.

> I'm not 100% sure whether all browsers will honor the changed order 
> though. They might handle pulled-in CSS differently from inline CSS 
> (that would be contrary to the W3C specs as I understand them, but that 
> doesn't mean that IE will stick with that interpretation).

All of the browsers I've tested (including IE) understand that
the later definition wins, regardless of where it comes from.

> > 2.  Create a new $HTMLStylesFmt setting in config.php:
> > 
> >     $HTMLStylesFmt[] = ' .indent { margin-left:1.5em; } ';
> 
> Ah - I didn't know that the 'pmwiki' in $HTMLSTylesFmt['pmwiki'] was 
> essentially commentary.

It's not just commentary -- it's an easy handle by which people
can quickly replace or remove all of PmWiki's defaults if desired.  
Any key can go in the brackets, or if no key is there it's just
added on to the end of the current array.

> The downside of this solution is that it won't work with skins.

Sure it will -- a skin can add entries to $HTMLStylesFmt[]
from its skin.php file.  (Of course, a skin doesn't normally
have to do that, since it can directly override the styles
directly in either the .tmpl file or from an external stylesheet
loaded via a <link .../> tag.

> In general, I'm a bit confused about PmWiki's distribution of CSS over 
> pmwiki.css and $HTMLStylesFmt. I think $HTMLStylesFmt should cover only 
> those things that are part of PmWiki's semantics, i.e.
>    code { white-space: nowrap; }
>    .vspace { margin-top:1.33em; }
> [...]

.indent and .outdent are considered part of PmWiki's semantics --
i.e., people expect the -> and -< markups to visually indent, thus
it's defined programmatically in $HTMLStylesFmt as opposed to 
relying on every skin to set it.  (Of course, a skin can easily
override PmWiki's default, as described above.)

In the general case, .indent, .outdent, .createlink, etc. are
treated the same as any CSS settings that might come from a
markup recipe or other special-purpose recipe.  A recipe cannot
expect every skin to provide all of the CSS settings it might need,
so $HTMLStylesFmt[] is an easy programmatic way for a recipe
to provide CSS defaults while still making it easy for a skin
or wiki administrator to override those defaults.  (Conversely,
we don't want to burden a skin designer with having to specify
every possible CSS class for every recipe.)

So, the CSS settings that PmWiki puts into $HTMLStylesFmt[]
are in the same general category; there are some built-in markups
that expect things to be rendered in a certain style, and the
CSS associated with those is placed in $HTMLStylesFmt.

> (Some of that visual appearance is important, of course, so there's 
> justification to put some of that in $HTMLStyleFmt anyway. But not 
> everything, at least IMHO.)

Well, not everything is in $HTMLStylesFmt, there are quite
a few CSS classes and settings that are left to the skin's
stylesheets.  See pmwiki.css for an example.

Pm