Ah, i agree that that is usually a good heuristic. In our case it’s a bit different though.
We are currently using the Material-UI frontend framework, which is great on a really large set of dimensions, but does all of it’s styling in the form of inline CSS (the latest version is moving away from that, but that is currently only in prerelease).
In our case, the vast majority of the !important statements are there to override one specific lowest level material-UI inline style, and are not there to override any other styles in our own CSS files. This makes the impact of those statements significantly less bad than they would usually be. Still not happy about having to use the important tags that way, and it does definitely have some cost, but overall the cost is much lower than one would naively expect.
Because that would add a whole different level of complexity to our code, where now instead of just managing CSS styles, we would need to both manage css styles in one section of our page, and JS-inline styles in another section of the page. Since the interface by which you change the material-UI inline-styles is by passing style-objects to the relevant React components.
We tried this for a bit, but this made things much harder to maintain and keep clean than having important-statements in some parts of the CSS.
In the long-run I want to move towards a styled-components approach, where all styles live in the component files, which we can do after the current @next branch of material UI reaches maturity and feature parity with the current one.
Ah, i agree that that is usually a good heuristic. In our case it’s a bit different though.
We are currently using the Material-UI frontend framework, which is great on a really large set of dimensions, but does all of it’s styling in the form of inline CSS (the latest version is moving away from that, but that is currently only in prerelease).
In our case, the vast majority of the !important statements are there to override one specific lowest level material-UI inline style, and are not there to override any other styles in our own CSS files. This makes the impact of those statements significantly less bad than they would usually be. Still not happy about having to use the important tags that way, and it does definitely have some cost, but overall the cost is much lower than one would naively expect.
Why not remove/disable that one specific style?
Because that would add a whole different level of complexity to our code, where now instead of just managing CSS styles, we would need to both manage css styles in one section of our page, and JS-inline styles in another section of the page. Since the interface by which you change the material-UI inline-styles is by passing style-objects to the relevant React components.
We tried this for a bit, but this made things much harder to maintain and keep clean than having important-statements in some parts of the CSS.
In the long-run I want to move towards a styled-components approach, where all styles live in the component files, which we can do after the current @next branch of material UI reaches maturity and feature parity with the current one.