W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css-variables] Putting it all toegether (syntax)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 4 Jun 2012 17:58:49 -0700
Message-ID: <CAAWBYDDcAHY2tvy69JWv=4Ymb1r=fPTe_vWr8y60K61v2AxySA@mail.gmail.com>
To: "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>
Cc: Fran├žois REMY <fremycompany_pub@yahoo.fr>, www-style list <www-style@w3.org>
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.

Received on Tuesday, 5 June 2012 00:59:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC