- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Tue, 10 Jul 2012 09:51:55 +0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "L. David Baron" <dbaron@dbaron.org>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, 史绪胜 <xushengs@gmail.com>
(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