Has anyone had a go at building a new templating language for CSS files? I can really see the need as the current prefered way of using DTML has the disadvantage that the css is no longer valid once templated. ZPT of course would be the solution if CSS was XML, but alas :( I was thinking that there must be some way of reusing TAL and/or metal to put expressions in CSS comments. My current need for this is being able to put set correct absolute urls for background images in a css file such that I can still use dreamweaver to do visual editing. Speaking of which, absolute urls are a real pain. There must be a better way of being able to edit files on a file system and have the server use absolute urls without having to write expressions for every single reference? Isn't there some equivilent to the html base tag to specify what "/" means? Dylan Jay --- http://www.meetmemap.com - makes giving directions easy http://www.pretaweb.com - Update-it-yourself, low cost websites http://www.eatmanifesto.com - against all dumbing down of food http://www.idartatravelimages.com/mySearchResults.aspx?query=Virginia%20Choy...
Dylan Jay wrote:
Has anyone had a go at building a new templating language for CSS files?
No, because it isn't needed. 99.9% of the time a style sheet is static.
My current need for this is being able to put set correct absolute urls for background images in a css file such that I can still use dreamweaver to do visual editing.
How do you do this with a normal <img>? Describe the process. Then we'll tell you how to use that very same process with a style sheet.
Speaking of which, absolute urls are a real pain. There must be a better way of being able to edit files on a file system and have the server use absolute urls without having to write expressions for every single reference? Isn't there some equivilent to the html base tag to specify what "/" means?
Why are you bent on using absolute URLs for images in the first place? -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Dylan Jay wrote:
disadvantage that the css is no longer valid once templated. ZPT of course would be the solution if CSS was XML, but alas :(
I think ZPT is just fine for generating CSS. It coudl do with a plan text mode, like it has an HTML and XML mode, but apart fro mthat, it rocks :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Dylan Jay wrote:
disadvantage that the css is no longer valid once templated. ZPT of course would be the solution if CSS was XML, but alas :(
I think ZPT is just fine for generating CSS. It coudl do with a plan text mode, like it has an HTML and XML mode, but apart fro mthat, it rocks :-)
Stylesheets should always be static documents, a dynamic stylesheet defeats browser caching and destroys the advantages over just inlining all the presentation markup. If you want to have dynamic style, you should use dynamic cascading & inclusion instructions, but the stylesheets themselves should remain static. As such, generating style in ZPT is a complete waste of time and effort. The File object is a much better fit. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
----- Original Message ----- From: "Jamie Heilman" <jamie@audible.transient.net> To: "Chris Withers" <lists@simplistix.co.uk> Cc: "Dylan Jay" <me@dylanjay.com>; <zope-dev@zope.org> Sent: Tuesday, March 30, 2004 8:13 PM Subject: Re: [Zope-dev] ZPT for CSS, anyone?
Chris Withers wrote:
Dylan Jay wrote:
disadvantage that the css is no longer valid once templated. ZPT of course would be the solution if CSS was XML, but alas :(
I think ZPT is just fine for generating CSS. It coudl do with a plan text mode, like it has an HTML and XML mode, but apart fro mthat, it rocks :-)
Stylesheets should always be static documents, a dynamic stylesheet defeats browser caching and destroys the advantages over just inlining all the presentation markup. If you want to have dynamic style, you should use dynamic cascading & inclusion instructions, but the stylesheets themselves should remain static. As such, generating style in ZPT is a complete waste of time and effort. The File object is a much better fit.
Actually my use case isn't really for dynamic stylesheets but for absolute urls. I want to be able to edit say a filesystem site using dreamweaver and have relative urls like background-image: url(back.jpg) work, and then when this is used in a zope site such as a plone site then have it use something like background-image: url(http://site.com/back.jpg) to save on repeated requests. The other possible use case might what plone does with dtml in it's skins which is to define a color/font once and use it in many places. I'm not that fussed about that one, but neither of them are really dynamic. What if there was a CSSFile that when loaded changes all urls to absolute urls? That might be too specific but at least it does open the dynamisim flood gates. Dylan Jay --- http://www.meetmemap.com - makes giving directions easy http://www.pretaweb.com - Update-it-yourself, low cost websites http://www.eatmanifesto.com - against all dumbing down of food http://www.idartatravelimages.com/mySearchResults.aspx?query=Virginia%20Choy...
Dylan Jay wrote:
Actually my use case isn't really for dynamic stylesheets but for absolute urls. I want to be able to edit say a filesystem site using dreamweaver and have relative urls like background-image: url(back.jpg) work, and then when this is used in a zope site such as a plone site then have it use something like background-image: url(http://site.com/back.jpg) to save on repeated requests.
If the zope hierarchy matches your filesystem hierarchy, you shouldn't need to use absolute URIs.
The other possible use case might what plone does with dtml in it's skins which is to define a color/font once and use it in many places. I'm not that fussed about that one, but neither of them are really dynamic.
I don't use plone, so I couldn't speak to this.
What if there was a CSSFile that when loaded changes all urls to absolute urls? That might be too specific but at least it does open the dynamisim flood gates.
Thats doing the work in the wrong place. If you have a one-time translation job, which is basically what you're asking for, then you should do it once before the object is placed into the zodb. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Jamie Heilman wrote at 2004-3-30 02:13 -0800:
... Stylesheets should always be static documents, a dynamic stylesheet defeats browser caching and destroys the advantages over just inlining all the presentation markup.
We just converted some stylesheets from static to dynamic. Some parts of the stylesheet need to be different dependent on the virtual host it is used for. Furthermore, stylesheets often contain customization "variables", e.g. for a color scheme. I think, this is useful. -- Dieter
On Tuesday 30 March 2004 01:40 pm, Dieter Maurer wrote:
Furthermore, stylesheets often contain customization "variables", e.g. for a color scheme. I think, this is useful.
This is one of the most painful warts in CSS that would have been really easy to do right, I think. Being able to name colors for parts of pages and then reuse those names would make a lot of this sort of problem go away for style sheets where the colors are the only difference. CSS 3 might include this, but I've not tracked it closely. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Jamie Heilman wrote:
Chris Withers wrote:
Dylan Jay wrote:
disadvantage that the css is no longer valid once templated. ZPT of course would be the solution if CSS was XML, but alas :(
I think ZPT is just fine for generating CSS. It coudl do with a plan text mode, like it has an HTML and XML mode, but apart fro mthat, it rocks :-)
Stylesheets should always be static documents, a dynamic stylesheet defeats browser caching
Not if the dynamism is based on user preferences, and if the cache-control headers are set appropriately; in that case, the browser (but not intermediate proxies) will still be able to cache the page.
and destroys the advantages over just inlining all the presentation markup. If you want to have dynamic style, you should use dynamic cascading & inclusion instructions, but the stylesheets themselves should remain static. As such, generating style in ZPT is a complete waste of time and effort. The File object is a much better fit.
Overall, I agree with you that stylesheets are best kept static. However, consider what happens to cacheability when the URLs of of images referenced in a document are relative; the same problem can afflict stylesheets, particularly in a setup where virtual hosting is in play. I strongly favor DTML over ZPT for those cases where you need to generate dynamic "plain" text (mail, CSS, Javascript, etc.) Neither will be "transparent" to tools like Dreamweaver, but then again I can't imagine *any* markup that would be transparent; it would pretty much have to be embedded in whatever "comment" syntax the underlying language defines. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Tres Seaver wrote:
Stylesheets should always be static documents, a dynamic stylesheet defeats browser caching
Not if the dynamism is based on user preferences, and if the cache-control headers are set appropriately; in that case, the browser (but not intermediate proxies) will still be able to cache the page.
Yes, even if dynamism is based on user preferences. Stylesheets are a combinatory tool, thats what cascading is all about. Create seperate stylesheets for every preference value and combine them to achieve the desired presentation. Let ZPT and <link> directives handle the user preference logic, you'll blow less energy on the back-end processing and your server-side caching will be that much more effective.
However, consider what happens to cacheability when the URLs of of images referenced in a document are relative; the same problem can afflict stylesheets, particularly in a setup where virtual hosting is in play.
Nothing happens to cacheability based on URI relativity. I fail to see how virtual hosting has anything to do with this either. If you're talking about object acquisition, thats a manufactured problem that Zope enables, but is avoidable by attention to the context your URIs will appear in. Just because acquisition lets an object be addressable by multiple URIs doesn't mean its a good idea to do so.
I strongly favor DTML over ZPT for those cases where you need to generate dynamic "plain" text (mail, CSS, Javascript, etc.)
Python Scripts are better for dynamic plain text, simply because they're less magical and don't have all the stupid namespace problems that DTML does. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
On 31/03/2004, at 7:31 AM, Tres Seaver wrote:
Overall, I agree with you that stylesheets are best kept static. However, consider what happens to cacheability when the URLs of of images referenced in a document are relative; the same problem can afflict stylesheets, particularly in a setup where virtual hosting is in play.
I strongly favor DTML over ZPT for those cases where you need to generate dynamic "plain" text (mail, CSS, Javascript, etc.) Neither will be "transparent" to tools like Dreamweaver, but then again I can't imagine *any* markup that would be transparent; it would pretty much have to be embedded in whatever "comment" syntax the underlying language defines.
hmmm... would a similar idea to TAL ease the pain? A sprinkling of new CSS properties along the lines of... p { padding: 1.5em; foo-property: "padding context/padding"; } Could even apply similar ideas for i18n for properties such as "content". Michael
On 03/30/04 14:31, Tres Seaver wrote:
I strongly favor DTML over ZPT for those cases where you need to generate dynamic "plain" text (mail, CSS, Javascript, etc.) Neither will be "transparent" to tools like Dreamweaver, but then again I can't imagine *any* markup that would be transparent; it would pretty much have to be embedded in whatever "comment" syntax the underlying language defines.
Here is a fairly transparent syntax to consider. p { color: gray; background-color: white; -tal-define: preferences context/preferences; -tal-attribute-color: preferences/foreground; -tal-attribute-background-color: preferences/background; } That would be pretty neat. It wouldn't be as expressive as ZPT, but that might be an asset. Shane
On 03/30/04 22:14, Shane Hathaway wrote:
Here is a fairly transparent syntax to consider.
p { color: gray; background-color: white; -tal-define: preferences context/preferences; -tal-attribute-color: preferences/foreground; -tal-attribute-background-color: preferences/background; }
That would be pretty neat. It wouldn't be as expressive as ZPT, but that might be an asset.
BTW instead of TAL, it should be called SAL, Style Attribute Language. TAL needs a sister. :-) Shane
Shane Hathaway wrote:
BTW instead of TAL, it should be called SAL, Style Attribute Language. TAL needs a sister. :-)
Arg! No more languages! :'( Still, maybe a TALES-in-plain-text thing has some merits, but then you want defines, a repeats, and you end up with TAL. *grunt* still, I suppose: template=""" p { color: %(color)s; background-color: %(bgcolor)s; } """ preferences = context.getProperty('preferences',{}) dict = { 'color':preferences.get('color','gray'), 'bgcolor':preferences.get('bgcolor'white'), } return template % dict ...does the job in the correct fashion... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Shane Hathaway wrote:
BTW instead of TAL, it should be called SAL, Style Attribute Language. TAL needs a sister. :-)
Arg! No more languages! :'(
I think it would be pretty neat. :-)
Still, maybe a TALES-in-plain-text thing has some merits, but then you want defines, a repeats, and you end up with TAL.
Repeats wouldn't make sense in this language. Conditions would, but they would apply to the whole rule, not individual attributes.
template=""" p { color: %(color)s; background-color: %(bgcolor)s; } """ preferences = context.getProperty('preferences',{}) dict = { 'color':preferences.get('color','gray'), 'bgcolor':preferences.get('bgcolor'white'), } return template % dict
That's a mess. Shane
Shane Hathaway wrote:
I think it would be pretty neat. :-)
And YET ANOTHER thing the poor Zope user has to learn when they start: Python ZConfig ZCML ZPT (this thing) ...and that's assuming (this thing) totally replaces DTMhelL, which you and i both know it won't :-(
Still, maybe a TALES-in-plain-text thing has some merits, but then you want defines, a repeats, and you end up with TAL.
Repeats wouldn't make sense in this language.
Yeah they would, every language needs repeats in the end...
Conditions would, but they would apply to the whole rule, not individual attributes.
Ah, okay, I think building something purely for CSS would REALLY suck. Something which could generically build SQL, CSS, Emails I would be less lielyl to vomit about...
template=""" p { color: %(color)s; background-color: %(bgcolor)s; } """ preferences = context.getProperty('preferences',{}) dict = { 'color':preferences.get('color','gray'), 'bgcolor':preferences.get('bgcolor'white'), } return template % dict
That's a mess.
So persuade the Python guys to make string interpolation as powerful as you need it to be ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 02 Apr 2004 18:44, Chris Withers wrote:
Ah, okay, I think building something purely for CSS would REALLY suck.
Something which could generically build SQL, CSS, Emails I would be less lielyl to vomit about...
[snip]
So persuade the Python guys to make string interpolation as powerful as you need it to be ;-)
Why don't we have a good, long look at: http://www.python.org/cgi-bin/moinmoin/WebProgramming under the "Templating Systems" heading and make sure that someone else hasn't already come up with a good system that templates SQL, CSS, email, etc nicely. There's an awful lot of templating systems there... Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbTr0rGisBEHG6TARApGiAJ4z7ZTRh/hsg87UnUP1yaoePpil0ACfTtrH tAkw1jDdFJfaE9sjkI5Ri5I= =0Ked -----END PGP SIGNATURE-----
Here is one option I happen to like: generate CSS via XSLT from an XML dialect It has the following pre-requisite: make XSLT available as part of the Zope framework. Once you can rely on having XSLT as part of your framework (it really should be part of "batteries included" IMHO), you can do interesting things like providing a transformer for creating CSS files out of some sort of XML dialect. Here is a snippet of one we created at Ariel: <CascadingStyleSheet> <FileName>ariel-letter</FileName> <Comment> Special style sheet to support printed Ariel Partners Letterhead </Comment> <CssElement> <ElementName>#header</ElementName> <Style> <StyleName>height</StyleName> <StyleValue>5 cm</StyleValue> </Style> <Style> <StyleName>right</StyleName> <StyleValue>1.0in</StyleValue> </Style> </CssElement> ... If someone does not like the XSLT transformer that Zope would (in my proposal) provide out of the box, they are free to substitute their own. Since it would be integrated with ZPT, you could use ZPT expressions to create the XML dynamically out of pieces and parts. If the XSLT capability were integrated into ZPT somehow, it could be made cache aware for greatest efficiency. Of course, not everyone likes this kind of "generative programming" approach. I find that code generation tends to simplify alot of problems. Just my 2c, --Craeg Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 02 Apr 2004 18:44, Chris Withers wrote:
Ah, okay, I think building something purely for CSS would REALLY suck.
Something which could generically build SQL, CSS, Emails I would be less lielyl to vomit about...
[snip]
So persuade the Python guys to make string interpolation as powerful as you need it to be ;-)
Why don't we have a good, long look at:
http://www.python.org/cgi-bin/moinmoin/WebProgramming
under the "Templating Systems" heading and make sure that someone else hasn't already come up with a good system that templates SQL, CSS, email, etc nicely.
There's an awful lot of templating systems there...
On Fri, 2 Apr 2004, Chris Withers wrote:
Shane Hathaway wrote:
I think it would be pretty neat. :-)
And YET ANOTHER thing the poor Zope user has to learn when they start:
Hardly. You're confusing a fun little project with the Zope core platform. Please don't put down people's ideas so quickly. Shane
Shane Hathaway wrote:
On Fri, 2 Apr 2004, Chris Withers wrote:
Shane Hathaway wrote:
I think it would be pretty neat. :-)
And YET ANOTHER thing the poor Zope user has to learn when they start:
Hardly. You're confusing a fun little project with the Zope core platform. Please don't put down people's ideas so quickly.
Exactly. Chris, note that *most* users don't want or need dynamic CSS; this feature won't affect them. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Shane Hathaway wrote:
I think it would be pretty neat. :-)
And YET ANOTHER thing the poor Zope user has to learn when they start:
Hardly. You're confusing a fun little project with the Zope core platform. Please don't put down people's ideas so quickly.
Indeed, my mistake, I do apologise :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (11)
-
Chris Withers -
Craeg K Strong -
Dieter Maurer -
Dylan Jay -
Dylan Jay -
Fred Drake -
Jamie Heilman -
Michael Dunstan -
Richard Jones -
Shane Hathaway -
Tres Seaver