- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 4 Jun 2012 17:58:49 -0700
- To: "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>
- Cc: François REMY <fremycompany_pub@yahoo.fr>, www-style list <www-style@w3.org>
- Message-ID: <CAAWBYDDcAHY2tvy69JWv=4Ymb1r=fPTe_vWr8y60K61v2AxySA@mail.gmail.com>
On Mon, Jun 4, 2012 at 5:01 PM, Marat Tanalin | tanalin.com < mtanalin@yandex.ru> wrote: > 05.06.2012, 03:02, "Tab Atkins Jr." <jackalmage@gmail.com>: >> On Mon, Jun 4, 2012 at 2:58 PM, Marat Tanalin | tanalin.com >> <mtanalin@yandex.ru> wrote: >>> I tend to consider repeating prefix (be it `my-` or any other) when using a variable somewhat redundant. >> >> That redundancy often makes it easier to see relationships. > > How does the redundancy makes it easier than nonredundancy? Consistency in syntax means your brain has to work less to parse and understand things at a glance. This is generally a good thing. >> That @variables rule is exactly identical to a normal style rule in >> mechanics. You avoid the need to put a prefix on your var names, but >> in return are forced to put a prefix on your selector (the @variables >> token and the parens), and probably have to repeat selectors that >> you're already using to apply normal styling properties. > > We are forced to repeat selectors multiple, multiple times again and again everyday for more than 10 years, so apparently it's not considered a serious issue by CSS WG. And repeating selector in @variables rule is not something that could make situation any worse. > > For the rest, it may (or may not) make sense to consider using @variables at-rule inside regular rules: > > .example { > @variables { > link-color: red; > } > } > > .example A {color: $link-color; } That would be a larger change to the Core Grammar, and is still unlikely to actually save any characters over a prefix. >> In order for >> this to result in less typing you have to define at least 4 (or more, >> depending on the size of the repeated selector) variable properties >> per block (if you're measuring against the "var-" prefix) or 15+ per >> block (if you're measuring against the "$" prefix). > > Less typing in general is not the point of my proposal at all. My proposal's goal is to avoid prefix when defining variable and avoid ambiguity/nonextensibility if it will be decided (undesirably) to use $ token for defining variables too (not just for using variable's value). There's no ambiguity, and I believe quite strongly that we'll never have property names controlled by variables. The use case is very weak, and the behavioral complications are pretty bad. >> It also makes it less clear that variables act like every other >> property, because their definitions now live in a special at-rule >> instead of a normal style rule alongside the other properties. > > It's questionable what is less clear: `var-` (or `my-`, `x-`, etc.) prefix or `variable: value` pair inside @-rule. Latter is much more intuitive IMO. (Please try to not answer _immediately_ after reading.) It's expected that you find your own suggestion intuitive. ^_^ I disagree that its more intuitive to most people, since it no longer lives alongside other properties. >>> Also, using value in the my proposal has $ token-mark while defining value does not have $ (in the same way as recent François's proposal, but with no prefix). This clearly separates defining variable and its using. >> >> The separation is implicit already on whether the var names is on the >> left or the right of the colon. > > An explicit thing is generally more clear then an implicit one. That depends. The general rule, of which your statement is a derivation, is that you want to minimize the number of things that an author has to think about at the same time. I believe its generally true that we humans are pretty good with context-sensitivity if you don't go overboard with it. Inconsistency in naming, though, is much harder to deal with. ~TJ
Received on Tuesday, 5 June 2012 00:59:18 UTC