-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add inlineStyles plugin (rewrite of localStyles plugin) #592
Conversation
1 similar comment
1 similar comment
package.json
Outdated
"colors": "~1.1.2", | ||
"whet.extend": "~0.9.9", | ||
"css": "^2.2.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CSSO also has a parser (but probably with a bit different AST), so it could be reused without adding dependency.
Coming back from discussion in #447. Should this plugin now remove all classes that Or should this go into a separate plugin just for this task, |
test/plugins/inlineStyles.02.svg
Outdated
|
||
<svg id="test" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"> | ||
<style> | ||
.st2 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this class be removed?
I think the pugin should remove inlined classes (as well as emptied If the plugin will allways inline classes, I don't think it's a good idea to make it run by default. |
OK, so I will adjust the plugin to use csso ast instead and modify the css class removal logic. |
1 similar comment
@alexjlockwood: A Pull Request for |
SVGO v1.0.0 with this change has been released now. |
Not working correctly for the following SVG: Running with:
|
@moltar: I just tried this input svg with svgo version 1.0.5 and found no issues, |
@strarsis But it had no effect... The From
|
@moltar: You need to set the |
@strarsis I see, thank you for pointing that out! |
I followed the discussion here for a while and have been using the plugin a few times already. Great work! But from my point of view the default value should be |
Yup, agreed. I totally expected it to inline everything, that is why I didn't even look for options as my paradigm of thinking was different. The reason I needed to inline everything, is because |
you can't always inline everything without loss, example with Else for your question, I don't really know, I didn't try this plugin yet great work! |
@caub: Correct. Non-inlineable styles aren't inlined anyway by the plugin. With |
@strarsis Did you mean setting it to |
I guess it depends whether the flag will result in an optimized file or not. On one hand, not inlining everything can save bytes by keeping common code in the style block. On the other hand, not inlining the style can have a big impact on plugins that will be run later on (i.e. you won't be able to merge paths or collapse groups if the elements declare classes). |
I agree with @alexjlockwood. The other plugins have to rely on the declarations of There may be even the case that an hypothetical extra plugin can "outline" all the styles in |
Yeah, I dreaming about that for years, but it's far from the current state. Massive rewriting is needed. |
@alexjlockwood right, I think it depends on what you see as optimization. My use case for this plugin is to prepare SVG files for embedding in HTML source. If you do that, CSS classes on multiple SVG elements override each other if they have the same class names. For example Illustrator always uses the same CSS class names st0, st1 and so on for each file. This plugin solves that problem. |
I think @caub has intended to do something like that. |
Yes, I may try to start a branch on svgo for it, and we could tag it as @next on npm, for a future major version. It takes times because most plugins should be rewritten https://github.com/jsdom/jsdom has improved a lot its SVG support, but getComputedStyle is not working as well as browsers yet https://repl.it/@caub/jsdom-getcomputedstyle, we would need to fix it for svgo We could make a custom DOM impl for svgo, lighter than jsdom, from the current one on svgo jsdom basically use http://npm.im/nwmatcher (will replaced by http://npm.im/nwsapi soon) for querySelector(All) and matches UpdateCurrently stuck on dperini/nwsapi#14 (comment), once it's working, we can integrate nwsapi in a light custom DOM for svg, add | |
TODO: Line 91 in e7b8a6c
|
This pull request adds the inlineStyles plugin for inlining styles,
also correctly handling selector specificity, cascading,
advanced selectors, etc and intelligently cleaning up matched selectors.
Additionally, direct CSS selector support (powered by css-select, csstree and csso) is added to svgo which
is used by this plugin (
querySelectorAll(selector)
,querySelector(selector)
,matches(selector)
).Furthermore, the CSSStyleDeclaration interface is added to svgo jsAPI for handling element styles.
As latest addition, Element.classList property is added to svgo JSAPI for proper cleaning up class attributes.
As little extra, the last unnecessary semicolon of inline styles declarationList is cleaned up.