Block rules need to contend with single-multi line distinction

[davidtheclark]

I'm pretty sure that's not being considered yet.

[davidtheclark]

Agh. This single/multi-line stuff is running into some complications.

1. For each relevant rule we'll have to define what determines that its applicable CSS is single- or multi-line. For example, is this a\n{ color: pink; } a single- or a multi-line block? How about this a {\n color:pink; background: orange;\n}?
2. Then, we will run into the situation where certain permutations of standard options don't make sense. block-opening-brace-newline, for instance --- does it just not accept the single-line options for "after", because anytime a newline is present within the braces the block is multi-line? (Dependent on Rules #1)

[MoOx]

From what I know about eslint, single line is when the entire block (for eslint: object) on a single line: { ... }. As soon as there is a newline somewhere, we should switch to multilines.
I have to admit that the case of the selector is kind of tricky. I think we should only consider single/multi for the block it self (braces + content inside).

[davidtheclark]

Yeah, I was thinking that, too. So we're in agreement about 1 above.

After #73 changes are implemented I think that 2 above has a straightforward solution: the block-opening-brace-newline-after simply doesn't accept *-single-line or *-multi-line keywords, only accepts always|never.

[MoOx]

lgtm

[jeddy3]

The solutions to 1 and 2 both LGTM :)

[davidtheclark]

As of bbea328 this is finished for block-opening-brace-space-*. Newline needs to be done.