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

(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".

>>>  * 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.



Cheers,
Kenny

Received on Thursday, 5 July 2012 10:51:36 UTC