Re: [css-variables] -- considered harmful

On Mon, Nov 2, 2015 at 4:57 AM, Daniel Glazman <
daniel.glazman@disruptive-innovations.com> wrote:

> Hi there,
>
> I just stumbled upon a set of slides authored by Wilson Page from
> Mozilla about WebComponents in Gaia. And in this set, I found the
> following slide (please note these great slides are just a live
> example of CSS Variables usage and I link to a screenshot of them here
> only as such):
>
>   http://pbs.twimg.com/media/CSyy2UGWcAA2lbh.png
>
> Reading this slide triggered many, many comments here.
> So I'd like this mailing-list to record my POV on the -- syntax:
>
> 1. I still find it our ugliest syntactic decision in 20 years
>

I disagree, I'm used to it already, but that's just bikeshedding I guess.
The reason I support it is that it fits CSS's forward compat rules so well
because CSS always allowed for -vendor- prefixes, so with one fell swoop it
sets a precedence and we can explain simply "there's no vendor" and authors
have only 1 new thing to learn that can be applied to custom-anythings, and
it kind of jumps out at you like I think it should.


> 2. I still find it incredibly error-prone
>

How?


> 3. it allows an author to write the perfectly valid
>
>    .two-columns {
>      column-count: var(--column-count);
>      -moz-column-count: var(--column-count);
>      -webkit-column-count: var(--column-count);
>      --column-count: 2;
>    }
>
>    and such a rule seems to me so awful I'm shaking my head in despair.
>
> is it terrible because there is a --column-count or because there are so
many? The later is hardly the fault of --.




> Custom Properties are - I did not change of opinion - a superb way
> of nicely adding variables to CSS. But first, if they are 'properties',
> I don't think we should be able to give the same name to a property and
> a custom property; one could argue the names will never be the same
> since -- is part of the custom property's name...I'm far from

accepting that argument as enough. I think we're making a very bad
> decision allowing things like 'background: var(--background)'.


But this is exactly one of the ways we can pass things into shadow dom
because it relies on a two way agreement.  If you set  -moz-border-radius,
it's not the border-radius, it's the -moz-border-radius.  It sounds to me
like there's two disagreements here, one that you particularly don't like
'--' and the other being that property names can't be used, but does that
mean that "background: $background" doesn't have the same criticism? If
not, why?


> I
> perfectly understand the technical details here, and I am replying it's
> also our duty to care about the non-technical details that matter
> to our main users, web agencies.
>
> Second, from a readability and maintainance point of view, even $foo
> would be better than --foo. Unfortunately, $foo is impossible to avoid
> collisions with CSS preprocessors. But that's probably not a good enough
> reason to pick up a double dash. If $foo is universally understood as a
> variable, --foo is universally understood as a decrement. A very bad
> choice again.
>

I think the "decrement" comment is the strongest argument I've seen, but I
don't think 'universal' is true, in lots of things $ is a token indicator
or a monetary unit - context matters.  I feel like it is pretty safe to say
that in CSS properties, selectors, functions, etc - for all times "-" is
'dash' not 'minus' so...  Still, anything that follows the same basic
pattern works for me,  -a- (for author) or -x- for extension or maybe even
-$- (because why not I guess) seem to have the same basic appeal of just
'fitting' - solving all the problems at once and being easy to explain.



> It's still time to offer better than what we have now.
> My 0.02€.
>
> </Daniel>
>
>


-- 
Brian Kardell :: @briankardell :: hitchjs.com