Local styles plugin

[strarsis]

This PR adds the local styles plugin.
It is a complete rewrite of previous PR, to make the code simpler and more efficient.

[strarsis]

Hm, jshint fails with build using nodejs release v0.10.40, but with other plugins than this one.
Should I base off from a different commit than current master?

[GreLI]

It seems that recurseFn isn't actually used.

[GreLI]

Also, I'd like if styles were transfered just if there is only one match, not if two or more (non-adjanced, adjanced can be grouped). It seems it can be done easy enough in the current implementation.

[strarsis]

"Also, I'd like if styles were transfered just if there is only one match, not if two or more (non-adjanced, adjanced can be grouped). It seems it can be done easy enough in the current implementation."

So this means that when a CSS rule with multiple selectors
is selected because one selector matched /not all of them),
then the whole CSS rule should be cleaned?

Like for example using this rule in input:

.test1, test2 {
    color: blue;
}
.test3 {
    background: red;
}
[...]
<rect class="test1" [...]

The rule is cleaned up completely because .test1 matched?:

.test3 {
    background: red;
}
[...]
<rect class="test1" [...]

[strarsis]

The jshint fails with other files for this PR, should I base it off a different commit that passes the tests?
https://travis-ci.org/svg/svgo/jobs/91121264#L176

[GreLI]

No, I don't think it's required. Do it if you want.

It's odd that other builds including master branch passed it.

[strarsis]

OK, so the last thing that needs to be clarified is how matched CSS rules are handled.
So a CSS rule should be cleaned up when any of its selectors matched, right?

[GreLI]

I mean remove a rule only if there only one corresponding class in document. E.g.

<svg>
<style>
  .thick { stroke-width: 10px }
</style>
<path class="thick" d="..."/>
</svg>

but not then there are several classes here and there:

<svg>
<style>
  .thick { stroke-width: 10px }
</style>
...
<circle class="thick" .../>
...
<path class="thick" d="..."/>
...etc...
</svg>

[GreLI]

Why not just simple for loop?

for (var i = 0; i < items.content.length; i++) {

Modern engines optimize it, so there is no need in caching length = items.content.length.

[strarsis]

Yes, I fixed/changed the loop code now.

Preserving selectors/rules when they are used multiple times is a bit tricky,
the current (not pushed yet) implementation is a bit bloated, I have to simplify it a bit.
I also try to get rid of the global variables and add some further tests for edge cases.

[GreLI]

Don't forget to check with «CDATA», empty <style/> tag, complex selectors, etc. Just fixed a couple of issues: fc174aa.

[LeZuse]

Do you guys have any update on this?

[strarsis]

Yes, I rewrote the plugin so that it can use the svgo ast as cheerio ast and juice for cleaning up the styles.
cheerio ast back to svgo ast is not fully working yet, hence no new PR has been created yet.

Edit: The reason why I use juice now in this svgo plugin is that it already solved the quite complicated handling of style cascadation, selectors, etc and comes with tests included.

[strarsis]

OK, the rewrite has been finished: #592