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 :-)
C
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 p
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 i
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
-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 persuad
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-plai
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 rep
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:
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
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
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
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 st
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 mod
13 matches
Mail list logo
