[pmwiki-users] problem with @import css rules when going through php

Bronwyn Boltwood arndis at gmail.com
Sat Aug 6 16:24:35 CDT 2005


On 8/6/05, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Fri, Aug 05, 2005 at 05:40:15PM -0400, Bronwyn Boltwood wrote:
> The CSS syntax says that any @import rules must appear at the
> very beginning of a style sheet, before any other rules.
> See http://www.w3.org/TR/CSS21/cascade.html#at-import .
> 
> The stitching above combines .css files into a single style sheet,
> so if layout-abpos-sb28pct.css has any non- at import rules in it
> then layout-abpos-leftsb.css cannot have any @import rules.

I did read the relevant chunks of the spec earlier, and made sure that
the *component* stylesheets complied, but had not figured out the
implication that you just did.

> Does this help?

Yes, and it's yet another incentive to change how Pukka handles the
css and configuration info. I'm trying to split it into a core-code
directory, and saved-config directories, so that you can use different
configs as if they were different skins.  I should be able to set one
field to use config A, and another field to use config B, at the same
time.  Right now I can only do this if I copy the entire directory,
which makes maintenance suck, and is a waste of disk besides.  I also
want the different configs to be usable in the normal way, through
$Skin and the skinchange recipe.

But I'm having trouble getting the stitch_foo.php files to work in
this setup, and this @import problem has hammered another dozen nails
in their coffins.

I have idea for a different method, where each saved config folder
contains a skin.php, and skin.php
(1) declares some variables, 
(2) tells PmWiki to load the centrally-stored template, and 
(3) configures css components.  

I'd put (1) and (2) into its own file and include() that, if I could
only see how to tell all the skin.phps where to get it.

Let's expand on (3), the css configuration section.  There should be a
list of lo-fi components, and a list of hi-fi components.  The wiki
admin configuring the skin needs to be able to comment out the options
she doesn't want.  I'm not sure what data structure that entails, but
I suspect it's an array.  For each list, I want to generate a file
that contains an @import rule for each desired css component.  (The
@import syntax used in the lo-fi and hi-fi lists must be different,
because that's how I keep the older browsers from seeing too-advanced
css.)  Ideally, PHP should not rewrite the file if it already exists
and has not changed.  (That might be too tricky a problem for me to
solve, though.)  Finally, skin.php should insert the necessary link
tags or @import rules (I haven't decided which is best, yet) into the
HTML headers for the page, one for lo-fi and one for hi-fi.  I know
there are functions or variables for doing that already.  I saw the
documentation in passing, but now that I want it, I can't find it
again.

The benefits of this approach would be rather large:
- only one config file
- dramatically improves CSS's cachability
- works on any webserver, unlike the first trick I tried
- could improve performance instead of lessening it
- allows @import rules in the component files to work properly

Damn, this is going to be difficult, but if it works, it will be so
worth it.  I already untangled the font and layout css, so that now I
can set all these things independently of eachother:
- headers and titles font
- body and navigation font
- bold headings
- italic headings
- layout rigidity (liquid, fixed, or elastic)
- layout mechanism (positioned or floated)
- left or right sidebar
- sidebar width
- total width (for fixed-width layouts)

We're not just talking about icing here, but icing plus one or more
extra layers of cake.  I'm off to the PHP docs for iterators and
arrays for a while...

Bronwyn




More information about the pmwiki-users mailing list