Re: Proposal for adding variable declaration blocks

I agree too.

Using var(varName) is the best way to implements variables avoiding conflicts and problems
(Re)defining keywords is a bad idea because it's too dangerous. And it can cause a lot of bugs.

Fremy

  From: Tab Atkins Jr. 
  Sent: Wednesday, July 02, 2008 3:54 PM
  To: Simetrical 
  Cc: Brad Kemper ; fantasai ; David Hyatt ; www-style@w3.org list 
  Subject: Re: Proposal for adding variable declaration blocks





  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;".  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?



    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.

    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.




  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?  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