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