Re: [css3-values] Disposition of Comments, remaining issues, and moving to CR

On Thu, Jul 5, 2012 at 3:51 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (12/07/05 15:52), Tab Atkins Jr. wrote:
>> On Wed, Jul 4, 2012 at 8:23 PM, Kang-Hao (Kenny) Lu
>> <kennyluck@csail.mit.edu> wrote:
>>> (12/07/05 11:06), L. David Baron wrote:
>>>> Bare parens have the following two serious disadvantages:
>>>>  * it's harder for somebody reading and trying to understand CSS to
>>>>    search for documentation on them since there's no name to search
>>>>    for (unlike with a functional syntax that allows an author
>>>>    encountering it for the first time to search Google for "CSS
>>>>    calc()"
>>>
>>> This seems like a marketing issue and we have a precedent. We have no
>>> problem calling the bare parenthesis after @media "Media Query" and so
>>> we can as well invent a term here that can be used to search for
>>> documentation and such.
>>
>> The examples aren't really parallel.  A media query starts with
>> "@media", which you can go look up to see what the syntax is.  There's
>> no such prefix for bare parentheses showing up in some arbitrary
>> property's value.
>
> A good tutorial about 'width'/'height', which has a good chance to be
> where you use bare parenthesis as calculation, would talk about this
> syntax too.
>
> Also, what about var() vs. $? Goggling "CSS $" doesn't direct me to
> LESS, potentially because Google ignores special characters. I would
> hope we don't use this as an argument against $ as I really think this
> argument is just lame. At least, it is certainly not something I would
> consider a "serious disadvantage".

This actually is one of the arguments against using $.  It's less
strong, though, because "$foo" is exactly how you denote a variable in
PHP, the most popular server-side language, and shows up in several
other languages (including JS - it's a somewhat-common pattern to name
jQuery vars with a leading $ to distinguish them from normal DOM
elements).

On the other hand, no language in existence has parentheses mean "you
can do math in here".


>>>>  * they'd prevent the working group from using parentheses in any
>>>>    other contexts in CSS property syntax (though the first point is
>>>>    also an argument against most other possible uses)
>>>
>>> My bet is that this is not likely to happen. It's not like CSS is a
>>> fast-changing language so worrying too much about "reserving for the
>>> future" doesn't make much sense to me, and if you want grouping
>>> constructs in the future, we still have [] and <>.
>>
>> One must always worry about being future-friendly, or else you'll make
>> mistakes that are really annoying later.  (You'll probably make them
>> anyway, but hopefully less often if you're watching out for them.)
>
> I agree, but I'd be curious what we might want to use parentheses for.
> And, is it not possible to overload the meaning of parentheses just like
> how it is overloaded in other programming languages (e.g. in JS bare
> parenthesis is used after a control flow keyword and it is also used to
> mean a function call)?
>
> It seems that we have extensive experience about this in other languages
> so we can just learn from them.

The main thing I expect to use parens for in the future is their
primary purpose - grouping things.  For example, currently, if we want
a function to take a general selector as an argument, we have to make
it the last argument and have no optional args, because the comma in
selectors clashes with commas between arguments.  Requiring people to
wrap the selector in parens if they use commas in it would help.

Variables have a very similar problem in the default values of the
var() and parent-var() functions.  If I ever convince the group to do
Mixins, we'll have the same problem there.  Parens could be useful in
both of these circumstances for grouping values into a single
argument.

~TJ

Received on Friday, 6 July 2012 07:43:18 UTC