Ability to have variables in CSS code is one of the common desires of web developers that I come across. To address the problem, I'm working on a CSS preprocessor that will use C-like syntax:
You write:
$define _TEXTCOLOR rgb(20,123,43)
$define _THINBORDER solid blue 1px
$define _THICKBORDER solid black 0.3em
#mydiv
{ color: _TEXTCOLOR;
border: _THINBORDER;
}
#myotherdiv
{ color: _TEXTCOLOR;
border: _THICKBORDER;
}
Preprocessor produces:
#mydiv
{ color: _rgb(20,123,43);
border: solid blue 1px;
}
#myotherdiv
{ color: rgb(20,123,43);
border: solid black 0.3em;
}
Besides the ability to define constants as shown above, I plan to add conditional statements to branch code and have processing options to go with them. For example the script can be called as:
<link rel="stylesheet" href=http://www.webdeveloper.com/forum/archive/index.php/"csspp.asp?file=styles/stylesheet.xcss&options=_BLUESCHEME" />
so the stylesheet.xcss can have something like:
body
{
$ifdef _BLUESCHEME
background: blue;
$endif
$ifdef _GREENSCHEME
background: green;
$endif
}
so that it can be used for an easy layout/scheme switching or layout debugging:
$ifdef _DEBUG
div
{ border: solid red 1px;
}
$endif
Finally, my most ambisious goal is to have UA dependent branching. Something like:
$if _CLIENT(NN:0-5.0)
$end
$endif
#mydiv
{
$if _CLIENT(IE)
background: url('bg.gif');
$else
background: url('bg.png');
$endif
}
I'd like to hear your thoughts, suggestions and more feature ideas.Very interesting Vladdy... I'm exited to see how it turns out. One question though: Won't having it be preproccessed kill its ability to be easily cached? Perhaps I'm mistaken, but if this is the case, it would kind of defeat one of the key bonuses to css-based design.That's an excellent idea, Vladdy. Though, it is ASP, and not everyone has it... Perhaps it could later be translated to other languages.
Sam, since it's an external file, so long as the output result is text/css, it will cache it. At least, from my understanding, that is. Often I use a PHP file instead of a CSS one, and do browser validation before setting the content-type to text/css and outputting the final CSS code. I also include different files based on variables, which is how I do styleswitching. It seems to cache just fine for me...can it reliably detect the browser? That would be a very useful script (especially in ASP)Thanks for replies.
On caching.
Server side script, does not make file uncachable. Such impression comes from the fact that in the vast majority of cases you do not want the dynamicly generated page to be cached. All you need to have is correct set of headers that control caching. The stylesheet on my site is generated server side and I do not experience problems with caching it. In order to make the browser branching work, the CacheControl header is set to private - this way it prohibits proxy caching, but allows caching the page on local hard drive. Even if you have both IE and Mozilla on your computer (tested on Windows OS) you will get two different versions of the file cached, because the browsers keep their cache separate.
On the same topic.
I can see such script being used in two ways. One, when all features are utilized, is preprocessing upon request. Second, when there is no browser-dependent branching it can simply be used as a development tool. You write the stylesheet using the extra features it provides and then run it through the preprocessor, before publising it on the web.
On implementation.
I started putting some concepts together using client side javascript. It was faster to go from one textarea to another and debug things in the process, rather than having to go through the server. Now that I have most of the basic algorithms down, it is simpler to convert from client side javascript to ASP's JScript and figure out the rest of the logic. Once that finished I will translate it to PHP. If anyone is interested in translating it to Perl after - let me know
On browser detection
Browser detection is as reliable as UA String, which of course is not 100%. However, if the code structured properly it should not be a problem, meaning if browser is not recognized as the one requiring "special treatment" you send it compliant code. Of course that leaves the case of bad browser pretending to be good..... but I do not see gun manufacturers designing their product so that if an owner puts it in his/her mouth and pulls the trigger, they won't fire ... or in other words "if you won't help me help you, why should I bother?"Do you think you could include session/cookie support, for style switching, as well?Jona, I like that idea and I will work on it.
So far I got the $define implemented and $ifdef $ifndef branching. I made two "envelopes" for the code. One is a test page that allows you to play with and test preprocessor behaviour:
<!-- m --><a class="postlink" href="http://www.vladdy.net/klcsspp/klcssppcompile.asp">http://www.vladdy.net/klcsspp/klcssppcompile.asp</a><!-- m -->
Another one is an actual preprocessor that can take a file and return processed CSS
<!-- m --><a class="postlink" href="http://www.vladdy.net/klcsspp/klcsspp.asp?file=test.xcss&define=_TEST">http://www.vladdy.net/klcsspp/klcsspp.a ... fine=_TEST</a><!-- m -->
where file can be any valid URL, so you can actualy hook it up to a real web page.
I should have browser specific branching done in a day or two...Sounds awesome!
OK, I got the browser detection logic working. Right now I got RegExps setup for IE and Gecko, but will add more...I put some documentation together <!-- w --><a class="postlink" href="http://www.vladdy.net/klcsspp/aboutklcsspp.asp">www.vladdy.net/klcsspp/aboutklcsspp.asp</a><!-- w --> , so it is in a testable condition now.Hey Vladdy, you might want to take a look at using the browscap.ini (<!-- m --><a class="postlink" href="http://www.garykeith.com/browsers/index.asp">http://www.garykeith.com/browsers/index.asp</a><!-- m -->) file to determine the browser.Im very interested in how this is going, have you made any further advancementsCurrently I have all the features I was thinking about implemented, except inclusion of files. I'm doing a facelift of a customer site using the preprocessor and putting it through the paces in real application, fixing minor bugs as they come up.
I'm not sure at what stage I will implement the file inclusion, so far I do not really see much need for the feature - maybe the first release will be without it.
Right now the ASP version in pretty stable. You can play with it using the links I provided. I will be converting it to PHP next few weeks, and hopefully release it in a month or so.
If you are interesed in ASP version beta-tester discount - e-mail me.PHP translation is done, working on presentation page and manual. Should have the release soon ...
I tested the PHP version by using it on my site. You can see the original file with preprocessor instructions at:
<!-- m --><a class="postlink" href="http://www.klproductions.com/styles/screen.xcss">http://www.klproductions.com/styles/screen.xcss</a><!-- m -->
The result of preprocessing can be viewed at: <!-- m --><a class="postlink" href="http://www.klproductions.com/klcsspp/klcsspp.php?file=../styles/screen.xcss">http://www.klproductions.com/klcsspp/kl ... creen.xcss</a><!-- m -->
and would depend on the browser used. At the top of the resulting CSS output there is profiling information, whivh will be optional in the final release. As you can see the preprocessing is pretty fast and does not add any noticable delay.That's awesome, Vladdy! Now you need one of those cute li'l 88x31 buttons.
You write:
$define _TEXTCOLOR rgb(20,123,43)
$define _THINBORDER solid blue 1px
$define _THICKBORDER solid black 0.3em
#mydiv
{ color: _TEXTCOLOR;
border: _THINBORDER;
}
#myotherdiv
{ color: _TEXTCOLOR;
border: _THICKBORDER;
}
Preprocessor produces:
#mydiv
{ color: _rgb(20,123,43);
border: solid blue 1px;
}
#myotherdiv
{ color: rgb(20,123,43);
border: solid black 0.3em;
}
Besides the ability to define constants as shown above, I plan to add conditional statements to branch code and have processing options to go with them. For example the script can be called as:
<link rel="stylesheet" href=http://www.webdeveloper.com/forum/archive/index.php/"csspp.asp?file=styles/stylesheet.xcss&options=_BLUESCHEME" />
so the stylesheet.xcss can have something like:
body
{
$ifdef _BLUESCHEME
background: blue;
$endif
$ifdef _GREENSCHEME
background: green;
$endif
}
so that it can be used for an easy layout/scheme switching or layout debugging:
$ifdef _DEBUG
div
{ border: solid red 1px;
}
$endif
Finally, my most ambisious goal is to have UA dependent branching. Something like:
$if _CLIENT(NN:0-5.0)
$end
$endif
#mydiv
{
$if _CLIENT(IE)
background: url('bg.gif');
$else
background: url('bg.png');
$endif
}
I'd like to hear your thoughts, suggestions and more feature ideas.Very interesting Vladdy... I'm exited to see how it turns out. One question though: Won't having it be preproccessed kill its ability to be easily cached? Perhaps I'm mistaken, but if this is the case, it would kind of defeat one of the key bonuses to css-based design.That's an excellent idea, Vladdy. Though, it is ASP, and not everyone has it... Perhaps it could later be translated to other languages.
Sam, since it's an external file, so long as the output result is text/css, it will cache it. At least, from my understanding, that is. Often I use a PHP file instead of a CSS one, and do browser validation before setting the content-type to text/css and outputting the final CSS code. I also include different files based on variables, which is how I do styleswitching. It seems to cache just fine for me...can it reliably detect the browser? That would be a very useful script (especially in ASP)Thanks for replies.
On caching.
Server side script, does not make file uncachable. Such impression comes from the fact that in the vast majority of cases you do not want the dynamicly generated page to be cached. All you need to have is correct set of headers that control caching. The stylesheet on my site is generated server side and I do not experience problems with caching it. In order to make the browser branching work, the CacheControl header is set to private - this way it prohibits proxy caching, but allows caching the page on local hard drive. Even if you have both IE and Mozilla on your computer (tested on Windows OS) you will get two different versions of the file cached, because the browsers keep their cache separate.
On the same topic.
I can see such script being used in two ways. One, when all features are utilized, is preprocessing upon request. Second, when there is no browser-dependent branching it can simply be used as a development tool. You write the stylesheet using the extra features it provides and then run it through the preprocessor, before publising it on the web.
On implementation.
I started putting some concepts together using client side javascript. It was faster to go from one textarea to another and debug things in the process, rather than having to go through the server. Now that I have most of the basic algorithms down, it is simpler to convert from client side javascript to ASP's JScript and figure out the rest of the logic. Once that finished I will translate it to PHP. If anyone is interested in translating it to Perl after - let me know
On browser detection
Browser detection is as reliable as UA String, which of course is not 100%. However, if the code structured properly it should not be a problem, meaning if browser is not recognized as the one requiring "special treatment" you send it compliant code. Of course that leaves the case of bad browser pretending to be good..... but I do not see gun manufacturers designing their product so that if an owner puts it in his/her mouth and pulls the trigger, they won't fire
... or in other words "if you won't help me help you, why should I bother?"Do you think you could include session/cookie support, for style switching, as well?Jona, I like that idea and I will work on it.So far I got the $define implemented and $ifdef $ifndef branching. I made two "envelopes" for the code. One is a test page that allows you to play with and test preprocessor behaviour:
<!-- m --><a class="postlink" href="http://www.vladdy.net/klcsspp/klcssppcompile.asp">http://www.vladdy.net/klcsspp/klcssppcompile.asp</a><!-- m -->
Another one is an actual preprocessor that can take a file and return processed CSS
<!-- m --><a class="postlink" href="http://www.vladdy.net/klcsspp/klcsspp.asp?file=test.xcss&define=_TEST">http://www.vladdy.net/klcsspp/klcsspp.a ... fine=_TEST</a><!-- m -->
where file can be any valid URL, so you can actualy hook it up to a real web page.
I should have browser specific branching done in a day or two...Sounds awesome!
OK, I got the browser detection logic working. Right now I got RegExps setup for IE and Gecko, but will add more...I put some documentation together <!-- w --><a class="postlink" href="http://www.vladdy.net/klcsspp/aboutklcsspp.asp">www.vladdy.net/klcsspp/aboutklcsspp.asp</a><!-- w --> , so it is in a testable condition now.Hey Vladdy, you might want to take a look at using the browscap.ini (<!-- m --><a class="postlink" href="http://www.garykeith.com/browsers/index.asp">http://www.garykeith.com/browsers/index.asp</a><!-- m -->) file to determine the browser.Im very interested in how this is going, have you made any further advancementsCurrently I have all the features I was thinking about implemented, except inclusion of files. I'm doing a facelift of a customer site using the preprocessor and putting it through the paces in real application, fixing minor bugs as they come up. I'm not sure at what stage I will implement the file inclusion, so far I do not really see much need for the feature - maybe the first release will be without it.
Right now the ASP version in pretty stable. You can play with it using the links I provided. I will be converting it to PHP next few weeks, and hopefully release it in a month or so.
If you are interesed in ASP version beta-tester discount - e-mail me.PHP translation is done, working on presentation page and manual. Should have the release soon ...
I tested the PHP version by using it on my site. You can see the original file with preprocessor instructions at:
<!-- m --><a class="postlink" href="http://www.klproductions.com/styles/screen.xcss">http://www.klproductions.com/styles/screen.xcss</a><!-- m -->
The result of preprocessing can be viewed at: <!-- m --><a class="postlink" href="http://www.klproductions.com/klcsspp/klcsspp.php?file=../styles/screen.xcss">http://www.klproductions.com/klcsspp/kl ... creen.xcss</a><!-- m -->
and would depend on the browser used. At the top of the resulting CSS output there is profiling information, whivh will be optional in the final release. As you can see the preprocessing is pretty fast and does not add any noticable delay.That's awesome, Vladdy! Now you need one of those cute li'l 88x31 buttons.