Conversation
|
Just wanted to propose the exact same change. Thanks! |
|
@mfeckie sorry for the late reply, I completely missed your PR. I'm just wondering why you want to style the SVG after generation. Can you provide a small example of that?
|
|
The primary reason is that the height/width properties set by the library are based on a scaling integer. This means it's not easy to set a very specific size. One of our use cases is to produce a grid of 'login cards' that are used by young students to sign in to an app. So we want to be able to tightly control the height and width. Setting the viewbox allows us to easily scale them after the fact with CSS classes. This is why I suggested viewbox + class (because we need to apply the class to the SVG directly, not a wrapping element). Begin able to style SVG's by class makes them very flexible, while changing nothing for most people. We use tailwind and so setting the styling directly as you suggest would be outside our normal usage of CSS. It's fine if you don't find the change helpful, we're using the fork now and are very happy 😄 |
|
Hey @ondrej-tucek , we would also like to style the resulting SVG with tailwind classes. Would you please consider merging this in? Otherwise I'll also have to make a fork. Right now we are using a "hack" which involves changing the resulting svg with JS |
You can not expect people to apply SVG styles to all their SVGs, especially since some may come from external sources. Using a wrapper element is a workaround that ignores the crux of this issue. It would be much better to let "users" add any HTML attributes they want to the SVG. |
The current implementation makes it challenging to style the SVG after generation.
This PR
viewBox, which makes subsequent CSS based styling easierclassproperty to the SVG settings struct, allowing direct application of CSS classes tooIt does remove the presence of
widthandheightfrom the generated SVG, so if accepted this might be considered a breaking change