RE: Re: Parsing and Spewing CSS

An additional advantage to this method is that the browser will cache the style sheet locally and reduce the number of calls to your server. Of course, this could be a bad thing if you were planning on changing the style sheet frequently, but in my experience that's pretty rare.

Actually, I'd be interested in hearing about solutions to this as I've tackled this a completely different way in Mason:

/* keys %head */

% foreach (keys %head) {
<% $_ %> { font-size: <% $head{$_} %>pt; color: <% $colours{'head'} %>
+; \
%   if ($isNetscape) {
font-family: <% $font_family %>; padding-left: 10px; padding-top: 10px
+; \
%   } else {
margin-left: 10px; margin-top: 10px; \
%   }
}
% }

/* keys %text */

% foreach (keys %text) {
<% $_ %> { font-size: <% $text{$_} %>pt; \
%   if ($isNetscape) {
color: <% $colours{'text'} %>; font-family: <% $font_family %>; paddin
+g-left: 10px; \
%   }
%   if (($isIE) && ($_ eq 'P')) {
line-height: <% $line_height %>pt; margin-left: 10px; \
%   }
%   if ($_ eq 'UL') {
list-style-type: circle; \
%   }
}
% }
%head = (
    'H1'            => $font_size + 6,
    'H2'            => $font_size + 4,
    'H3'            => $font_size + 2,
    'H4'            => $font_size,
    'H5'            => $font_size
);

%colours = (
    'text'          => '#FFFFFF',
    'head'          => '#99CCFF',
    'link'          => '#CCCCCC',
    'vlink'         => '#999999',
    'alink'         => '#99CCFF',
    'list'          => '#99CCFF',
    'smalllist'     => '#99CCFF',
    'listheaders'   => '#99FFFF',
    'highlight'    => '#FFFFFF',
    'data'          => '#FF9933'
);
[download]

I need clean this up a lot, but it was the way that (kind of) made sense to me when I was trying to build a style sheet that would adapt according to browser support/os/individual preferences...

Comment on RE: Re: Parsing and Spewing CSS Download Code

Replies are listed 'Best First'.
RE: RE: Re: Parsing and Spewing CSS by Fastolfe (Vicar) on Nov 15, 2000 at 20:23 UTC
This brings up an interesting point. CGI scripts should never be cached by the browser. I believe most (all?) web servers, when serving up any CGI or dynamic (making use of SSI) content, will note a page with, like, an immediate Expires header, or some other mechanism to let the browser know that the page shouldn't be cached. What if you want data to be cached? Is the best way to accomplish this to emit an Expires header of our own? What about If-Modified-Since-qualified requests? Do we then have to process those, and emit the requisite 304 if no change has been made? In short, is there a module or better mechanism for scripts to participate in the expiration/caching process, or to at least override the server's default behavior of marking CGI-generated content as uncachable?	[reply]
RE: RE: RE: Re: Parsing and Spewing CSS by Hrunting (Pilgrim) on Nov 16, 2000 at 00:23 UTC
The best way to accomplish this is to find some documentation somewhere for whatever web browser(s) you are developing for an send the appropriate headers. Each browser has it's own way of specifically denying cachable information. It's a pain in the ass. Actually, the way that I'm leaning towards right now is to cache the information locally and send the cached information to the client. This works best under mod_perl, because you don't have to worry about the overhead of starting up a perl processor to handle the return of cached data (like you would normally). I've found that IE tends to cache based on what it's user settings are and tends to ignore the Expires: header. And even with the CGI module, you can return whatever headers (status and otherwise) you want.	[reply]


Think about Loose Coupling
	PerlMonks