Improve non-JSON verbose output.

[kezabelle]

Currently, when using csscss -v to output to STDOUT, the text comes out like:

{#x} AND {#y} share 7 rules
  - display: none
  - padding-left: 0.8em
  - padding-right: 0.8em
  [... and so on ...]

To assist with refactoring, it might be nicer if the following conditions were met:

• add semi-colons to the end of each rule (eg: - display: none;)
• remove the hyphen from being prefixed to each rule (eg: display: none)
• the final result would be a valid CSS rule (eg: display: none;)

Rationale: #x and #y are similar. To refactor them, it might be prudent to add a new class to both of them, call it .z - the easiest way of doing this would be to copy-paste the csscss output into a new class definition (or scss mixin/placeholder/whatever) and update the HTML. Currently that still involves tidying up each line, when the tool could basically do the work for us.

As I don't know if there's a specific reason for the formatting to be as it currently is, this may be best served as an additional flag to be passed to the cli csscss

[zmoazeni]

Fantastic suggestion. Thank you. The only reason for the dashes in front were to break up the blocks visually.

[zmoazeni]

@kezabelle I'm not going to change this with the next release, but I'd like to play around with some ideas first. My initial reaction is that without the hyphen in the front, it'll be tough to visually parse each "block" of data. That may be better with the color support. Not sure.

Thoughts?

[kezabelle]

Certainly the colourised output doesn't seem hard to parse, at least to me. It's definitely a bit harder with --no-color

Double-newlines before every {x} and {y} share N rules might help, or hyphens repeated (eg: ------...) for the column count of the terminal?

For my purposes, I've been piping the output to a file anyway, so that I can go through them without using the terminal scrollback, and that obviously lacks colour. It's not the easiest to parse visually, I agree, but as it's no longer transient (being in a file), it's less of an issue to spend the time doing so.

[kezabelle]

The other alternative is to completely change the output, to output actual CSS, which would be a bold step.

Where it currently says, {selector 1}, {selector 2}, {selector 3}, {selector 4} share N rules and there follows a list of said rules, it could feasibly be transformed into a real CSS target, eg:

selector 1,
selector 2,
selector 3,
selector 4 {
    shared-rule: 1;
    shared-rule-2: value;
}

[... next intersection ...]

The refactoring would then simply be a case of deciding on a shared class name to replace the comma separated list of existing selectors, and doing the same updating discussed in the original issue.

The workflow at this point would be something like:

• run csscss on your code;
• pipe the output to a new file whatever.css;
• choose new class names for everything in whatever.css;
• add classes to the appropriate places in HTML;
• remove shared rules from the original selectors.

[zmoazeni]

@kezabelle I'm not sure about that direction. Consolidating rules certainly is one way to solve it. Having awareness and refactoring styles other ways can be another.

One thing else we need to consider is being able to output file name and line numbers from #39