Or my favorite: “If you don’t have time to do it right, when will you have time to do it over?”
1 Like
I don’t want to unnecessarily future-proof this approach and I wonder how many occurrences of needing to override these classes there are.
You’re right that most styles going forward should be either:
- From patternfly (and patternfly-react)
- Part of a component
One thing I can think of off-hand is the branding plugin. Not sure how that would override colors, etc.
Right now, in Foreman core we have about 350 lines of CSS to override patternfly defaults. There are most likely other places as well that we override default styling because for example in a certain context we want an element to be styled differently then its default styling for whatever reason. Bastion includes some styles as well that differ from core by overriding existing selectors. I didn’t look into it further, but I suspect other plugins carry some specific styling as well.
While our influence on patternfly is larger now than it was before, it is also effected by other project’s requirements and I wouldn’t want to lose the ability to use different styling than provided by them.
I’m concerned that components we create using this method will be moved to patternfly and we lose the ability to modify them. I also wouldn’t want to prevent plugins from having the ability to override the styles provided by us when needed.