This is part of my Building Fluentic Style series, where I’m writing down the design decisions, tradeoffs, and small surprises from building Fluentic Style.
The feeling I keep having is that styling in component frameworks often asks components to fit back into the old HTML + CSS model, instead of asking what CSS composition should look like when components are the main unit.
That is not meant as a takedown of CSS.
I like CSS.
And the HTML + CSS model makes a lot of sense in its own world.
In that model, you write HTML, give elements class names, and use selectors when a nested part needs styling.
That model has problems.
Global CSS can leak.
Naming is hard.
Specificity can become painful.
Large stylesheets can become difficult to maintain.
But the basic mental model is easy to understand: Give the part a name, then style that named part.
Even when the ecosystem adds SCSS, BEM, naming conventions, CSS Modules, and other tools, a lot of the core idea stays familiar.
There is markup.
There are names.
There are selectors.
Styles reach elements through those names.
That world feels coherent because HTML and CSS are built around that relationship.
Then components change the shape of UI.
Components Change The Unit In React and other component frameworks, we usually stop thinking of UI as one big HTML document.
We think in components: That is a huge improvement.
A component owns its internal markup.
It receives props.
It composes with children.
It hides implementation details.
It can be typed.
It can be transformed by tooling.
It can become part of a design system.
But styling still has to answer a familiar question: How do I style the thing inside?
In HTML + CSS, if I want to style the title inside a card, I can write: In a component world, that assumes a lot: the component exposes a class the DOM structure stays the same outside CSS is allowed to reach inside the styling system is not isolating class names the component author intends that part to be customized Sometimes that is fine.
I still use selector-based styling in many places.
But the component boundary changes the feeling.
The component owns the inside.
Outside code still wants to customize it.
That is the tension.
The Usual Ways We Handle This Over time, frontend code has found many practical ways to handle this.
One common approach is more class props: This is explicit and easy to understand.
But the component API starts growing around styling needs.
Every public part needs a prop.
Every prop needs a name.
Every name becomes a contract.
A slightly more organized version is a per-part override object: This gives the consumer two common escape hatches: when they already have CSS somewhere when they want to pass a small direct override That is convenient.
Inside the component, though, every public part still becomes a merge point: This is not strange code.
I have written this kind of code a lot.
It is practical.
But it shows the repeated shape: every styleable part needs a name, a prop shape, and a merge point.
Variants are another common path: Variants are great when the design cases are known.
But when a variant affects many inner parts, the component starts carrying a small style matrix: Again, not wrong.
Sometimes this is exactly the right choice.
CSS variables are also useful: They are native, flexible, and they compose well with CSS.
But the component still needs to intentionally expose those variables: That is a good tool, but it is still a public styling surface the component author has to design.
So I do not see these approaches as wrong.
They are practical, and they exist because the problem is real.
The part that stays interesting to me is the repeated shape: Outside styles want to reach meaningful component parts, and component authors need a clean way to expose those parts without leaking the whole DOM.
That is the problem I want Fluentic to explore.
Co-Location Helps, But It Solves A Different Layer Tailwind and utility-first styling change the day-to-day feel