Re: Proposal for adding variable declaration blocks

Tab Atkins Jr.:
> On Wed, Jul 2, 2008 at 8:33 AM, Simetrical <simetrical@gmail.com>  
> wrote:
>> On Wed, Jul 2, 2008 at 1:20 AM, Brad Kemper <brkemper@comcast.net>  
>> wrote:
>>> It would also work well if we were to allow re-assigning values  
>>> to existing color keywords (...):
>>>  @define {orange: #f60; green: #093;}

People wouldn't understand why they could only reassign color  
keywords but not others. If you want to allow others, there is need  
for scoping (consider 'normal'), e.g.:

   @define colors {orange: #f60; green: #093;}

   @keywords color {orange: #f60; green: #093;}

   @colors {orange: #f60; green: #093;}

Some keywords would be exempt from redefinition, for example because  
their meaning cannot be expressed by other means CSS provides.

>> Also, this means that there's now a practical difference between  
>> specifying "background: white;" and "background: #FFF;".

Yes, except in legacy UAs. That's why this solution provides the best  
backwards compatibility of all proposals. People won't provide  
explicit fallbacks for today's browsers after variables will have  
been implemented in certain browsers.

>> That seems like a bad idea to me.

It doesn't break anything. It may be strange to have e.g. a bluish  
colour called 'white' after a redesign, though.

>> Allowing "background: white;" to translate to "background:  
>> #423F69;" because of an obscure declaration hidden somewhere in 50  
>> KB of CSS seems pretty scary to me,

Like most proposals in this area, keyword redefinitions would have to  
be put at the top of a stylesheet file, probably before any |@import|s.

>> especially because you can't necessarily grep for it effectively.

How so? All 'white's in scope were bluish.

>> And wouldn't these redefinitions affect user and UA stylesheets as  
>> well?

   /*- only valid in this stylesheet: */
   @private colors {
     red: #E11;
   }
   /*# only valid in this stylesheet and in those it imports: */
   @protected font-sizes {
     x-large: 2em;
   }
   /*~ only valid in this stylesheet and in those it imports or is  
imported by;
       or in all stylesheets from this origin (author, user agent,  
user)?: */
   @package lengths { /* 'friend' and 'default' don't start with 'p' */
     small-length: 4mm;
   }
   /*+ available everywhere: */
   @public font-families {
     serif: "Egytienne", "Georgia";
   }

UAs may simply ignore @public for their own and their user's  
stylesheets.

>> On Wed, Jul 2, 2008 at 1:39 AM, Brad Kemper <brkemper@comcast.net>  
>> wrote:
>>> I like { background: $backgroundColor; } much more than I like  
>>> { background: var(backgroundColor); }, but I like { background:  
>>> backgroundColor; } the most. Keep it simple on the authors, even  
>>> if it is a tiny amount of extra work for the implementors. So my  
>>> version would look like this:
>>> h1 {use: headers; background: backgroundColor;}
>>
>> What happens if the author chooses a variable name that conflicts  
>> with a keyword that's later introduced?

I agree, real variable should be marked as such.

>> Also, it would make it impossible for someone new to the language  
>> to distinguish variables from keywords.

This is actually an advantage of overwritable keywords. Automatic  
syntax-highlighting is also easier.

>> var(backgroundColor) would be a self-explanatory and very CSS-y  
>> way to do it, and $backgroundColor is also quite intelligible and  
>> not ugly at all.

I agree, the functional notation is already best established in CSS.

> Allowing authors to redefine established keywords is a really bad  
> idea.  It only seems halfway decent in the case of colors, which  
> can be specified in alternate ways.

There are other types, e.g. font sizes. Other properties (or value  
types) could gain keywords, e.g. I proposed to add 7 absolute length  
keywords, based on the names of absolute font size keywords. (There's  
little backwards compatibility then, of course.)

> What if you redefined auto?

Not every keyword or kind of keywords is redefinable.

> It's best to have a clear way to disambiguate between keywords and  
> vars,

Sure, /if/ you may have both.

> They have far too much possibility of making an entire document an  
> impossible mess with almost zero benefit over the other proposals.

I consider graceful fallback quite a benefit.

>> h1 {
>> use: headers;
>> }
>
> However, I'm generally in agreement with liking the property:value  
> syntax
> for these things.  The consistency is very nice and easy to  
> understand, even
> if it is a slight hack on property syntax.

I don't like it at all, because I think its a bigger hack. It's a  
property of the ruleset, not of the selected items.

Received on Thursday, 3 July 2008 16:32:03 UTC