We actually just cleaned up our CSS a bit, but agree that we probably want to make that part cleaner in the long run. Though I haven’t found making changes particularly difficult.
That’s good to hear, and I wish you success in your efforts to that end! Here is a very simple heuristic, which is very helpful in evaluating how clean your CSS is:
How many times does !important appear in your codebase?
The ideal number is very, very small. (There is a reasonable argument for using it on buttons, and similar utility classes with complex and very specific and universally immutable styling; doing a once-over of a typical LW 2.0 page, I see no cases that fit this profile.) “Zero” is a typical number of instances of !important in a well-maintained CSS codebase.
Currently, that number, for the CSS that goes into an ordinary LW 2.0 post, is 623.
(This is not the be-all and end-all of CSS code quality metrics! But it is, as I said, a very good heuristic.)
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.
We actually just cleaned up our CSS a bit, but agree that we probably want to make that part cleaner in the long run. Though I haven’t found making changes particularly difficult.
That’s good to hear, and I wish you success in your efforts to that end! Here is a very simple heuristic, which is very helpful in evaluating how clean your CSS is:
How many times does
!importantappear in your codebase?The ideal number is very, very small. (There is a reasonable argument for using it on buttons, and similar utility classes with complex and very specific and universally immutable styling; doing a once-over of a typical LW 2.0 page, I see no cases that fit this profile.) “Zero” is a typical number of instances of
!importantin a well-maintained CSS codebase.Currently, that number, for the CSS that goes into an ordinary LW 2.0 post, is 623.
(This is not the be-all and end-all of CSS code quality metrics! But it is, as I said, a very good heuristic.)
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.