You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: Add a class to all SVG elements on a page #48
Additionally I need to add a class to all SVG elements. Obviously I could pass the same class every time I use inline-svg, but this feels like unnecessary repetition. I solved this by writing a transform that pulls a default class from config, but this would be a nice built-in config option.
@Undistraction I'm just being curious here, but do you need to add a class to every SVG? If you were trying to style every SVG couldn't you just style that base class accordingly?
At work we use a bastard mutation of SMACSS and ITCSS. The older I get, the more I realize the need for the styling of a reasonable number of base classes. Things like table for consistent tabular layouts, or h1 through h6 because I don't want to have to write heading heading--1 on every single h1 element, just to achieve a style that could easily be done in a base layer.
This is where my curiosity comes in... if you're interested in styling every SVG in some consistent way, what's the difference between:
@meowsus What happens when you use a third-party lib that does something different from what you're doing? You've now clobbered it by styling the base element. It does make sense to style base elements sometimes, but not with something as specific as dimensions. Some flexible defaults might make sense (for example width:100%; height:auto; for responsive images. If you look at ITCSS it does the bare minimum with the base classes. Just sets flexible, sensible defaults on top of normalisation.
Actually, even your h1 example is something I avoid. h1-6 have semantic meaning (the importance of the header) but this should be decoupled from the styling as otherwise you bake in the way the header looks with what it means. This might make sense in simple documents, but often not in a complex webpage or application and not on a responsive site where often on mobile, sizes are not indicative of importance.
It is also much easier to remove styles by removing a class than by overriding base styles - How can you remove a style on a base element?
There are numerous other arguments but I think these are the main ones.
I think the rule is that if you are normalising, resetting or setting
defaults, do it on the element (as long as they are genuinely defaults and
you don't end up overriding them everywhere) Otherwise functionality should
be added by classes. The classes should contain as few rules as possible
and you shouldn't be afraid to have many classes on an element.
Activity
Undistraction commentedon Feb 7, 2017
Sorry I missed this. Thanks for adding.
meowsus commentedon May 31, 2017
@Undistraction I'm just being curious here, but do you need to add a class to every SVG? If you were trying to style every SVG couldn't you just style that base class accordingly?
At work we use a bastard mutation of SMACSS and ITCSS. The older I get, the more I realize the need for the styling of a reasonable number of base classes. Things like
tablefor consistent tabular layouts, orh1throughh6because I don't want to have to writeheading heading--1on every singleh1element, just to achieve a style that could easily be done in a base layer.This is where my curiosity comes in... if you're interested in styling every SVG in some consistent way, what's the difference between:
and
Undistraction commentedon May 31, 2017
@meowsus What happens when you use a third-party lib that does something different from what you're doing? You've now clobbered it by styling the base element. It does make sense to style base elements sometimes, but not with something as specific as dimensions. Some flexible defaults might make sense (for example
width:100%; height:auto;for responsive images. If you look at ITCSS it does the bare minimum with the base classes. Just sets flexible, sensible defaults on top of normalisation.Actually, even your h1 example is something I avoid. h1-6 have semantic meaning (the importance of the header) but this should be decoupled from the styling as otherwise you bake in the way the header looks with what it means. This might make sense in simple documents, but often not in a complex webpage or application and not on a responsive site where often on mobile, sizes are not indicative of importance.
It is also much easier to remove styles by removing a class than by overriding base styles - How can you remove a style on a base element?
There are numerous other arguments but I think these are the main ones.
meowsus commentedon May 31, 2017
I see your point. Especially regarding the third-party library.
Undistraction commentedon May 31, 2017
elliottregan commentedon Jun 29, 2018
Extendable defaults for all options would be nice, actually. 'aria' and 'nocomment' are things that are generally a good idea to have everywhere.