- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 02 May 2014 09:00:30 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, 30 Apr 2014 19:06:21 +0200, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Apr 30, 2014 at 9:42 AM, Simon Pieters <simonp@opera.com> wrote: >> I'd like to reopen the issue of whitespace around + and - in calc(). I >> think >> the current situation is hostile for authors and we can do better. In my >> opinion, we should make things that look OK be OK and things that don't, >> aren't. >> >> Currently the following are valid: >> >> calc(1px + +1px) >> calc(1px + 1px) >> >> but this are not: >> >> calc(1px + + 1px); >> calc(1px +1px); >> >> (I wouldn't be able to explain it to a Web author keeping a straight >> face >> and avoid #WTFCSS tweets why it's like this.) > > The + and - operations need whitespace around them. Values can have > unary + or - prepended to them. > > Why would somebody do either of those invalid ones, anyway? They both > look wrong; it's pretty easy to argue that writing either of them is > an error. You should be arguing for the sensible ones that are > currently invalid: > > calc(1px-1px) > calc(1px+1px) > > ...which are both invalid for different reasons. Yes, I think we should make those two valid. But I think it would be silly to allow calc(1px+1px) and calc(1px + 1px) but not calc(1px +1px). We currently allow calc(2*2px) calc(2 * 2px) calc(2 *2px) etc. >> I propose that we make the following changes: >> >> * In css-syntax, while tokenizing a dimension, we exclude "-" from >> being a >> valid character in the unit. > > This would prevent vendor-prefixed units, which exist today. (I agree > that we probably won't ever introduce units with dashes in them > normally, for writeability concerns.) Not really -- such vendors could just special-case their vendor-specific units in their tokenizer. It doesn't matter that the tokens would be different since other UAs would drop the entire declaration anyway. >> * In css-syntax, we store whether "+" or "-" was used in the token. >> (This is >> technically already stored in the "representation".) >> * We remove all whitespace restrictions in calc() (currently calc(1px+ >> 1px) >> is not allowed but it parses OK). >> * We define that the "+" or "-" delim in calc() must be omitted if the >> next >> value is a <number-token>/<percentage-token>/<dimension-token> with >> "+"/"-" >> set. >> >> This would make it valid to use exactly one +/- with any whitespace >> around, >> as far as I can tell. > > This makes parsing much more complicated to define, as it results in > something like the pain we got into with An+B. Rather than a simple > rule of "<value> <op> <value>", we have to handle cases like "<value> > <value>" and "<value> <op> <op> <value>". Would we have to handle a > disconnected +- sign when dealing with other operations, too? I agree it's more complicated to define. But authors are higher in the priority of constituencies. :-) >> Previously stated concerns against: >> * This wouldn't help with keywords if we are going to add keywords in >> the >> future (e.g. calc(auto-1em)). >> - Rebuttal: I don't see why that has to cripple calc() with >> dimensions. >> Saying that keywords can contain dashes and so have to be followed by a >> space seems sane to me. > > This kind of inconsistency troubles me. I don't like authors having > to remember special-case rules based on divisions that are fairly > arbitrary to them. The distinction between a keyword and a dimension > isn't large - a dim just looks like a keyword with a number in front > of it. Why should the rules be different? Why should authors face > confusing and hard-to-find errors when they apply the same rules that > work between dimensions to a keyword/dimension pair? "auto-1em" > doesn't look wrong to my eyes; it would be very easy to skip over it > when looking for what was wrong in my code, because my brain has > enough contextual information to parse it easily. I don't disagree, but changing the parsing rules for idents in general seems really scary given classes and IDs. > CSS is big, and growing. I've been moving more strongly toward the > "keep things consistent, even if they're suboptimal in some cases" > camp for a while now. The current rules aren't consistent. >> Open issues: >> * Should calc(+ 1px) be valid? > > No, regardless. What about calc(+1px)? -- Simon Pieters Opera Software
Received on Friday, 2 May 2014 07:01:04 UTC