[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