- From: Bruno Racineux <bruno@hexanet.net>
- Date: Tue, 18 Mar 2014 17:06:46 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: www-style list <www-style@w3.org>
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
Received on Wednesday, 19 March 2014 00:07:16 UTC