- From: Christoph Päper <christoph.paeper@crissov.de>
- Date: Thu, 3 Jul 2008 18:31:56 +0200
- To: "www-style@w3.org list" <www-style@w3.org>
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