W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: CSS Variables Draft Proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 17 Feb 2011 10:09:56 -0800
Message-ID: <AANLkTimXyh3p7aCdbV4xS5ShAZ_kMzdwWALwjp8fE6of@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: www-style list <www-style@w3.org>
On Wed, Feb 16, 2011 at 10:58 PM, David Singer <singer@apple.com> wrote:
> On Feb 17, 2011, at 13:59 , Tab Atkins Jr. wrote:
>> On Wed, Feb 16, 2011 at 8:15 PM, David Singer <singer@apple.com> wrote:
>>> On Feb 17, 2011, at 9:11 , Tab Atkins Jr. wrote:
>>>> Something like what I called Modules in
>>>> <http://www.xanthir.com/blog/b49w0>.  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.

~TJ
Received on Thursday, 17 February 2011 18:10:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT