New rule: function-opening-parenthesis-space

[davidtheclark]

Typical whitespace, probably.

[davidtheclark]

Should this be paired with function-closing-parenthesis-space?

Or should we assume that users would always want to enforce the same rules for opening and closing parentheses so combine them into function-parentheses-space?

[davidtheclark]

Also, if we were to make that assumption, we could simplify other rules along the same lines --- e.g. function-operator-space could have just "always"|"never" as the option, instead of doing all the before/after business, if we assume that people will always want the same whitespace on either side of the operator. Same goes for selector-combinator-space.

[MoOx]

I think function-opening-parenthesis-space and close are different according to the purpose.

Or should we assume that users would always want to enforce the same rules for opening and closing parentheses so combine them into function-parentheses-space?

I don't think it a good idea. Enforcing something like calc (...) seems different than calc( ... ).
If we do one rules, it might have 2 options (open/close) with 2 sub options for each (after/before) right ?

But for function-operator-space it's a bit more tricky since you can have +10% value (see color function spec).

[davidtheclark]

Also: @MoOx you probably know this from your other postcss plugins, just want to verify that functions in CSS can have spaces between the keyword and the opening parenthesis?

[MoOx]

You mean is something like rgb( 0,0,0, .2 ) working ?

[MoOx]

Oh sorry. You mean is calc () working ?

[MoOx]

For now it's not for var & calc. I need to double check if this works in browsers.

[MoOx]

calc () doesn't work in firefox. Good point :)
So that especially interesting to report that has an error :)

[davidtheclark]

So according to the spec it is supposed to work with whitespace between keyword and parenthesis?

[MoOx]

I don't think so.

[davidtheclark]

See http://www.w3.org/TR/css3-syntax/#rule-defs --- looks to me like there's no whitespace allowed between function name and (.

With that in mind I'd propose maybe we change this rule to function-parentheses-space-inside (always/never), enforcing padding: calc( 1px + 2px ) or padding: calc(1px + 2px); and create another rule for function-space-after which would enforce transform: translateX(1%) translateY(2%); or transform: translateX(1%)translateY(2%); (and would have to accept semicolons are the space)

What do you think?

[MoOx]

Since we are a linter, we might want to not just yell on code quality "issue" but also on potential error. So maybe we can create a rule to prevent this kind of issue (space between keyword and parenthesis) ?

[davidtheclark]

OK, yeah. If PostCSS doesn't already throw a syntax error for that, we should, makes sense.

function-token-no-space?

(In spec "function-token" = name + ( I think)

[MoOx]

It doesn't I just checked on cssnext playground.

function-token-no-space

why not :)

[davidtheclark]

Ok ... so just to clarify the plan after that discussion: we'll do away with this rule and create three:

• function-parentheses-inside
• function-space-after
• function-token-no-space

Everybody good with that?

[MoOx]

lgtm

[jeddy3]

One thing..did you mean:

function-parentheses-inside-space and instead of function-parentheses-inside?

Otherwise, the breakdown of rules LGTM :)

[davidtheclark]

Yep, thanks. I will change #1.