Re: CSS Variables Draft Proposal

On Wed, Feb 16, 2011 at 10:58 PM, David Singer <> wrote:
> On Feb 17, 2011, at 13:59 , Tab Atkins Jr. wrote:
>> On Wed, Feb 16, 2011 at 8:15 PM, David Singer <> wrote:
>>> On Feb 17, 2011, at 9:11 , Tab Atkins Jr. wrote:
>>>> Something like what I called Modules in
>>>> <>.  That proposal is essentially
>>>> just brainstorming, as we don't have immediate plans to even try an
>>>> experimental implementation, but it roughly outlines our thinking on
>>>> this matter.
>>>> Scoped stylesheets may also be used to contain variables if you really
>>>> don't want to leak them out to the global scope.
>>> But if module names are global (as I suspect they have to be), it seems like you have swapped a potential problem of unintended clashes of variable names, into a potential problem of unintended clashes of module names.  Which is a smaller problem, to be sure, and to be a real problem, you'd have to have both the module name and a variable in that module unintentionally collide, which also reduces the likelihood. But it doesn't appear to close the door, as it were.
>> That doesn't appear to be a problem in languages like Python, so I
>> won't worry about it for CSS.  ^_^
> Maybe we don't need to be rat-holing on this now, but what's on your blog (admittedly brief, and I may be mis-reading) doesn't seem to match Python's modules, which don't have this problem.  That's because in any document (module in python terms, stylesheet in CSS terms) I choose what modules to import, under what names, and what items (variables) from them.  Under these circumstance I think the logo example would look something like this as:
> @import url('corporate.css')
> .logo { content: $corporate.logoURL; }
> you could even write
> @import url('corporate.css')
> @var $logo $corporate.logoURL
> .logo { content: $logo }
> which would be the similar action to 'from corporate import logoURL'.
> We would need to decide, if I wrote:
> @var $foo 10px
> @import url('inner.css')
> whether the variable $foo can be used in inner.css.  I suspect yes, because either
> a) inner.css says
> @var $foo red
> which will locally (within inner.css) shadow the definition of foo
> or
> b) inner.css uses $foo without defining it, whereupon it must have been written expecting a definition to come in from above, so it's not a surprise.

No, you're right.  The Modules proposal in my post is very bare-bones,
and hasn't been given serious thought yet.  I suspect a proper
proposal would indeed offer a few extra knobs and switches, like what
Python and similar languages can do.


Received on Thursday, 17 February 2011 18:10:50 UTC