Re: Proposal for adding variable declaration blocks

On Jul 2, 2008, at 6:54 AM, Tab Atkins Jr. wrote:

>
>
> 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 (for greater cross-UA consistency, perhaps):
> >  @define {
> >    orange: #f60;
> >    green: #093;
> >  }
>
> Are there actual inconsistencies in how UA's implement colors, other
> than possibly some ancient ones that are never going to end up
> implementing the variables spec anyway?  Also, this means that there's
> now a practical difference between specifying "background: white;" and
> "background: #FFF;".

IIRC, "orange" was a little bit different on a couple different  
browsers I tried. And I fully expect that the CMYK values would vary  
for printing, if that has never been agreed upon. So it would also be  
nice to have a print style sheet in which they could be given a CMYK  
value.

Black and white are always black and white, and should be, so I am  
fine with those being frozen as is.

On the other hand, I suppose I could always use $orange, or  
var(orange), or whatever, instead of redefining the existing one. I'm  
not married to the idea of redefining color keywords, but it has been  
brought up before.

> That seems like a bad idea to me.  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, especially because you can't necessarily grep for it
> effectively.  And wouldn't these redefinitions affect user and UA
> stylesheets as well?

I was imagining that there would be a way for the user style sheets to  
override.

> On Wed, Jul 2, 2008 at 1:39 AM, Brad Kemper <brkemper@comcast.net>  
> wrote:
> > Meh. 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?  CSS comes out with new keywords a
> lot more frequently than most programming languages do, and already
> has far more than any programming language I can think of.

Well, that's a good point. Something would have priority, either the  
author's definition or the CSS keyword. I lean towards the new CSS  
keyword having priority, even though that would likely mean no  
redefinition of keywords as above.

Personally, my preference is that it should be the author's  
responsibility to pick a variable name that is not likely to conflict.  
For instance, if I used "BK-backgroundColor", then it is not only  
unlikely to conflict with future keywords, but is also unlikely to  
conflict with other author's style sheets that I might be loading.

> Also, it would make it impossible for someone new to the language to
> distinguish variables from keywords.  For that matter, I'm *not* new
> to the language, and I doubt I'd be able to recognize the permissible
> values for every single property on sight.  This, again, has the
> potential to be pretty confusing, for (I think) not a lot of benefit.
> 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 disagree that the functional notation is very CSS-y. It seems more  
JavaScripty to me. So far I haven't had to use it very much at all in  
my CSS (I know it is in clip and a couple of CSS3 properties). Plus it  
requires five extra characters each and every time it is used, two of  
which require the shift key. I would much rather just have one extra  
character to type. How about the equals sign? It can be typed quicker,  
plus it has a certain logic to it since it is often used for  
assignment in other languages:

background: =backgroundColor;

> Agreed.  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.  What if you  
> redefined auto?

I don't know what value you could use to redefine auto. I would limit  
it to color keywords and possibly others that might make sense, if at  
all. But as I say, I am not married to the idea, just throwing it in  
there because it has been part of previous proposals.

> How would you ever specify something was auto ever again, without  
> going back and just removing the original variable definition (which  
> defeats the purpose of having it at all)?
>
> It's best to have a clear way to disambiguate between keywords and  
> vars, so that we never have these collisions.   They have far too  
> much possibility of making an entire document an impossible mess  
> with almost zero benefit over the other proposals.
>
>
> >h1 {
> > use: headers;
> > background: backgroundColor;
> >}
>
> 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.
>
> ~TJ