Re: [css3-values] bare parenthesis as calculation/grouping construct

(12/07/10 7:18), Tab Atkins Jr. wrote:
> On Fri, Jul 6, 2012 at 4:36 AM, Kang-Hao (Kenny) Lu
> <kennyluck@csail.mit.edu> wrote:
>> 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.

We shouldn't accept "margin: 1em 1em + 1em" because in general
juxtaposition is stronger than any other binary operators. For an
example, see[1]. And, I think we shouldn't make "margin-left: 5em + 20%"
parseable because we shouldn't break the invariant that you can compose
values of longhand properties to the value of a shorthand (this is
arguable, though). We should not accept "width: 5em + 20%" not only for
consistency but also because we don't know whether "width" will in the
future become a longhand of a shorthand property and breaks the
invariant above.

That's just the fate of parenthesis-as-grouping-construct in a language
that uses juxtaposition a lot, like Perl/Ruby/F#. There's no notion of
"math context" in these languages.

[1] http://dev.w3.org/csswg/css3-values/#component-combinators

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

You can't have a value with a unit on the right hand side of '/', per
css3-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?

The latter.

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

I must be missing something. I thought the use case here is like

  background-image: var(foo, (url(bar1), url(bar2));

=>

  background-image: url(bar1), url(bar2);

How does it work if the parens are fed?

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

That's how I imagine your future parenthesis-for-grouping-arguments idea
is. What am I missing?

>> 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?

Yes.

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

Before I understand what "parens mean grouping" means, I can't quite
comment on this. But if there's no new parentheis-for-grouping-arguments
proposal, then I don't think bare-parenthesis-as-calculation has any
conflict with other proposals, and in that case Example 2c simply
becomes "width: var(invalid-foo, (1em + 2em)" without the outer
parenthesis, which is of course less confusing.

> 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, 

I really need an example to understand why it's future-hostile. Example
2c just doesn't work with you, it seems.

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


Cheers,
Kenny

Received on Tuesday, 10 July 2012 01:52:31 UTC