- From: Simetrical <simetrical@gmail.com>
- Date: Wed, 2 Jul 2008 09:33:27 -0400
- To: "Brad Kemper" <brkemper@comcast.net>
- Cc: fantasai <fantasai.lists@inkedblade.net>, "David Hyatt" <hyatt@apple.com>, "www-style@w3.org list" <www-style@w3.org>
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.
Received on Wednesday, 2 July 2008 13:34:03 UTC