Re: [css-variables] ...let's change the syntax

Since they are called custom propeties is there any reason we can't do the
most obvious thing and use a prefix of 'custom'?

.foo {
  custom-kolanut: #BF1E43;
  background-color: var(kolanut);
}

The '_' and '-' prefixes look like code smells to me due to the way they
have been used in CSS (and in programming languages generally)









On 19 March 2014 00:06, Bruno Racineux <bruno@hexanet.net> wrote:

> On 3/17/14 1:22 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
> >On Mon, Mar 17, 2014 at 1:26 AM, Daniel Glazman
> ><daniel.glazman@disruptive-innovations.com> wrote:
> >> On 13/03/2014 04:38, Tab Atkins Jr. wrote:
> >>> I've been thinking.
> >>>
> >>> At the last f2f, I proposed custom MQs and pseudo-classes.  To
> >>> distinguish them from CSS-defined ones, I mandated that they had to
> >>> start with (or perhaps just contain) an underscore character, because
> >>> this is a valid character that CSS is nevertheless never going to use
> >>> in language-defined names.
> >>>
> >>> This, while a little ugly, seems to do the job pretty well.
> >>
> >> Yeah, and I was opposed to your underscore proposal because of that.
> >> I really found the "underscore anywhere" proposal totally opposed to
> >> anything we've done in the past in CSS but since there was a rather
> >> large consensus, I accepted it.
> >>
> >> If I understand correctly, we're only days from a shipping
> >> implementation. We've kept the variables topic on the radar for 14
> >> years and I am not comfortable with changing things at the last minute;
> >> it's highly time to deliver. Any syntactic change we make must be done
> >> quietly these days, because we have so much more on the radar than 6
> >> years ago; any change has many impacts.
> >>
> >> "--" looks ok but raised some concerns.
> >> "_" is ugly, and not "a little" bit, but we resolved on it :-/
> >
> >We didn't actually resolve on anything.  We accepted me pursing my
> >drafts, with provisional acceptance of what's in them.  They're early
> >enough that I don't think there's even an implicit acceptance of the
> >current syntax *itself*; we've only been really accepting that the
> >idea is worthwhile, and the current syntax is at least vaguely
> >acceptable.
> >
> >> To be honest, I don't think that's what framework authors or even web
> >> site designers were looking for. They were looking for -jquery-foo and
> >> -mywebsite-foo because prefixes are already well known. They don't
> >> care and don't want to care about our syntactic rules about idents
> >> starting with a hyphen or not. This has always had my preference; users
> >> first.
> >
> >--jquery-foo, --mywebsite-foo.  Looks fine to me.
>
> Could the var() keyword/function style be replaced by some sort of
> namespace definition?
>
> One reason I am thinking of this, is that custom property names use by
> widgets stylesheets could end up colliding if people are not careful about
> prefixing. And '_' is one way to emphasize that clearly, along with
> identifying the property as custom.
>
> Here is the idea:
>
> p {
>   my_company-color: green;
>   twitter_font-color: blue;
>
>   background-color: my(company-color);
>   color: twitter(font-color);
> }
>
> '_' implies a custom property, making the declaration quite nice to
> read IMO, instead of hyphen or underscore prefixes, and less verbose.
> A dot annotation could be nicer perhaps, but if dots can't be
> <ident-token>s then '_' seems the next best alternative in this context.
>
> Then for MQs: @media(my_company-color) etc..
>
> I don't oppose '--' but the above looks somehow better to me.
>
>
> And if the arbitrary getter() function name is impossible or problematic
> to implement,
> how about just a unnamed parenthesis?
>
> p {
>   my_company-color: green;
>   twitter_font-color: blue;
>
>   background-color: (my_company-color);
>   color: (twitter_font-color);
> }
>
> -Bruno
>
>
>
>
>
>
>
>


-- 
Pete Boere
Web Developer