Problems faced by Grab UI
- Not possible to have project specific overrides of variables
- CSS modules not specific enough to override Grab UI (Semantic UI) classes as CSS modules only apply one class where Semantic UI applies two classes (.ui.) and has higher specificity.
- Import theme variables from Grab UI theme configs to use in project-specific components
- No build requirements
- Small and lightweight
- Supports global CSS
- Supports entirety of CSS
- Easy to override
- No wrapper components
Case for CSS in JS:
React inline styles solve the following problem:
- Global namespace
- Dead code elimination
- Sharing constants
Problems with (React) inline styles:
- No property fallbacks such as when vendor prefixes are needed. Can't declare two
displaystyles in a JS object.
- No media queries or element queries.
- If you render on server, you can't find out window/element size and initial styling sent to clients is likely to be wrong.
- No cascading styles
- Debuggin is a pain. Impossible to see changes made to one component affect all other similar components.
- Inline styles have the highest specificity and you can't override styles on those elements.
- Huge payload for server-side rendered markup with inline-styles for repeated components.
- Browsers need to parse all the inline styles which is slower as compared to parsing a stylesheet.
- Loading CSS in can be parallelized and doesn't necessitate downloading duplicate markup for (potentially many) similarly styled elements.
- Scoped selectors:
- Unique class names are generated and ensures no collision.
- Rules isolation:
- Prevents elements from inheriting properties from parent elements.
- Fast selectors
- Non-nested selectors are faster than deeply nested ones.
- Rules Sharing
- CSS rules can be shared for a list of items.
- All CSS features included.
- Faster performance than inline styles.
- CSS is, as Mark Dalgleish points out, “a model clearly designed in the age of documents, now struggling to offer a sane working environment for today’s modern web applications.”
- If your stylesheets are well organized and written with best practices, there is no bi-directional dependency between them and the HTML. So we do not need to solve the same problem with our CSS that we had to solve with our markup. — Keith J. Grant
- The foundational issue with CSS is fear of change. "You must have an intimate knowledge of both in order to safely make any substantive changes to either."
- That said, I like to minimize cognitive effort whenever possible. Things like naming strategies require a lot of discipline and “are hard to enforce and easy to break.”
- Smart people on great teams cede to the fact that they are afraid of their own CSS. You can’t just delete things as it’s so hard to know if it’s absolutely safe to do that. So, they don’t, they only add. I’ve seen a graph charting the size of production CSS over five years show that size grow steadily, despite the company’s focus on performance. ~ Chris Coyier
- You only include CSS classes that are actually used because your build system / module bundler can statically analyze your style dependencies.
- You don’t worry about the global namespace. The class “default” in the example above is turned into something guaranteed to be globally unique. It treats CSS files as isolated namespaces.
- You are more confident of exactly where given styles apply.
- Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability.
- We’ve worked around the issues of global scope with a series of naming conventions like OOCSS, SMACSS, BEM and SUIT, each providing a way for us to avoid naming collisions and emulate sane scoping rules.
- Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention, but by style encapsulation during development.
- If your stylesheets are well organized and written with best practices, there is no bi-directional dependency between them and the HTML. So we do not need to solve the same problem with our CSS that we had to solve with our markup.
- We had better have a damn good reason before we go down that road. Christopher Chedeau, in the original slidedeck that introduced this idea, outlines seven “problems” with CSS. The thing is, they are solvable problems. If we as web developers just understand CSS better, and take the time to learn modern best-practices like SMACSS and BEM, these issues almost entirely dissolve, especially at the scale most of us work at.
- CSS hasn’t been designed to fit into components based architecture.
Contrast this to your visual output - if each and every component is completely isolated visually from one another, your site or application will be a disastrous mess! Certainly every component has unique properties, and those properties should be isolated so as not to leak, but there is also a tremendous need for visual consistency across your site. This is one of the core reasons for the CSS cascade, and while a misunderstood and uncontrolled cascade can be disastrous, used properly it is an incredibly powerful tool.
This means that if every component is itself responsible for its own styling, you will end up with tremendous amounts of duplication!