Re: [css3-values] bare parenthesis as calculation/grouping construct (was: Disposition of Comments, remaining issues, and moving to CR)

On Fri, Jul 6, 2012 at 4:36 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (12/07/06 15:42), Tab Atkins Jr. wrote:
>>>>>>  * 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.
>
> I've been wondering why you think about the bare parenthesis syntax as
> "you can do math in here". To me, it's as you said, just a general
> grouping construct. It's the '+', '-', '*' or '/' that does the math.
> The parenthesis, as with any other programming language, is just there
> to make values parseable.

I think that because that's what it means.  A declaration like "width:
5em + 20%;" is perfectly parseable and unambiguous, but you'll still
need parens around it to make it work.  Thus, it's the parens that
make the math happen, not the operators.  The operators just do the
math once you're inside the parens' math context.

> Now I start to see some potential issues.
>
> Issue:
>
>   '+' is overloaded to mean both "plus" and "next-sibling combinator".
> '/' is overloaded to mean both "divide" and "general value separator".
>
> But I need an example to illustrate that this is a real issue (see below).
>
>> 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.
>
> Calculation is about grouping values into a single value too. So, to see
> if there are real problems I think it would be better to examine
> specific examples to see if there are real conflicts.
>
> Example 1a:
>
>   border-radius: 1em (2em / 3em) 4em
>
> This is admittedly somewhat confusing, but I'd say it's fine to say it's
> invalid.

Why would you say this is invalid?  If parens are doing math, then
this simply defines three values.

> Example 2a:
>
>   var(foo, (bar1, bar2))
>
> There's no '+', '-', '/' or '*' here so you don't need to do calc()
> syntax checking here, and I also don't think the "bare parenthesis as
> calculation idea" asks you to do calc() syntax checking any time you see
> a bare parenthesis pair, or otherwise it just doesn't work with the
> Media Query syntax.

Are you trying to suggest that it's possible to use () anywhere you
want, and it simply doesn't do anything if there aren't math operators
inside of it?  Or are you suggesting this as a one-off for var(), such
that you must use parens if your fallback value includes commas?

> Example 2b:
>
>   var(foo, (bar1 + bar2, bar3))
>
> So, even if there's a "+" here, as far as I can tell, the proposed
> behavior of the default value var() syntax with the bare parenthesis
> extension is to feed the token stream "bar + bar2, bar 3" to downstream.
> It's up to the the downstream to do any checking with the token stream.

Actually, as currently defined it'll feed the parens too.  Yeah, no
syntax checking or processing.

Or did you intend that it eats the parens here, too?

> Example 2c:
>
>   width: (var(invalid-foo, (1em + 2em))
>
> This would work, just like
>
>   width: (1em + 2em)

Why are you using extra parens around the var reference?  More paren-eating?



Overall, your examples convince me further that bare parens creating a
math context are just weird.  Particularly in your 2.n examples, the
mixture of using parens for grouping and for math is just confusing
and weird.  All of those are simpler if parens mean grouping and
calc() means math.

As I argued previously, calc()'s only problem is that it's 4
characters heavier than bare parens, while bare parens have the
problem that they're future-hostile to using parens for grouping, and
it seems confusing that simply grouping things together for
disambiguation (which it looks like you're doing when you use parens)
also makes math work.

The balance of problems leans toward keeping calc() as it is.

~TJ

Received on Monday, 9 July 2012 23:18:50 UTC