Re: CSS Variables Draft Proposal

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.

(see, I bottom-posted for you :-))

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 17 February 2011 06:59:50 UTC