Unified Styles Please.

[jeremy-coleman]

Describe the feature that you would like added

Generally, I would like to see better integration with the existing ecosystem of design systems. A few observations as background: It seems like every Microsoft project is just doing its own thing. Microsoft teams literally just wrapped typestyle and calls it MSTeamsContext, fast DNA is using Jss and some absurd type system. The office ui design system is really well designed, but you guys are not going to attract designers with yet another offshoot of css in jss. No design kit will provide 100% coverage of design needs, which means your customers are going to have to write their entire project using merge-styles (not likely going to happen), or use two or three different solutions. Enter the inefficiency.

The problem I am addressing is how the underlying css is created and the syntax/types used to create it, not the design system, or anything visual , and in general just annoyed at the perpetual divergence from standards. It's like jss fatigue is going to be the next cool thing.

There is an easy fix to the problem though, and that is to just what has become the community standard of css in js theming. Styled components, emotion, jss (and mui) , rebass, the new release of grommet, etc etc are all compatible. see: https://github.com/cssinjs/theming .

I tested the theme context provider with jss, react jss jss-styled, styled-components, mui's jss, and emotion simultaneously in a single app with all libraries receiving the theme context passed from from a single top level theme provider.

My recommendation / request is to use emotion. It's crazy fast, even faster than merge styles. Paypal recently depreciated glamorous in favor of it. It supports ssr, caching , and uses css vars where it can. It supports both tagged template literals and objects. It's also effortless to over ride styles of existing libraries. It would also be pretty much directly compatible with the fast-dna team's efforts. https://github.com/emotion-js/emotion

What component or utility would this be added to Everything Have you discussed this feature with our team, and if so, who No Additional context/screenshots Best

[dzearing]

Thanks for the suggestions. I want to comment on the points you have:

1. Try using cssinjs/theming

I'm not sure exactly what this gains us, so I would certainly be interested in your thoughts here. I do see a usefulness in abstracting themability patterns! But this library doesn't seem to provide any guidance on theming; it uses the legacy, deprecated React context to expose non-type-safe theme objects that can have anything in them, which isn't that much different than what we have today with theming. Am I missing something? Sorry if so! Perhaps you could elaborate on how this would make the library better.

We do already have a theming API, and we're currently doing work to refine theming even more to enable robust customization. It's one of the top 3 things we're improving right now.

Our theming documentation is not good. We will fix this; as we wrap up our conversion to css in js, which enables a lot of the theming support (e.g. working in ssr, theme in a box scenarios, accessibility testing, etc.)

You ARE absolutely right that no design system will cover all the bases. One thing we're planning on doing is to abstract some of the core styling concept in React components. E.g. Text element, Box element, etc. These will have semantic flags on them that imply purpose. The theme itself can define the styling for those elements as a function of those flags. We NEED to invest deeply in enabling you to define your design system in a theme, and have that reflected in the app. Totally agree on that point.

2. Switch from merge-styles to emotion

You suggested it's faster than merge-styles. Do you have a proto that suggests this? merge-styles is already pretty fast, and we have a branch to move to atomic css to improve perf even more.

If you look at this: https://github.com/tkh44/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

You will see that merge-styles is faster than emotion for this particular scenario, with the exception of the "emotion-css-mode" test, which basically cheats the test by preloading the class names at bundle load time, and then exports the Table which uses injected strings, rather than any sort of re-evaluation at runtime like you normally would do. You can look for yourself at the code here:

https://github.com/tkh44/CSS-IN-JS-Benchmarks/blob/master/packages/benchmarks/emotion/css-mode/client/Table.js

That all said, I want to say that we'd LOVE to use another css library, if there was one that met our needs. It is a bit of a distraction to invent yet another mechanism. However, it's a critical core piece of component library and we absolutely must hit all of these bullets:

• Small bundle size
• No performance regressions, only improvement :)
• Super fast (e.g. creates new style elements for style batches)
• Auto prefixing (numbers to units)
• Auto rtl flipping
• Can translate classnames to objects (e.g. create a class, inject it, and it can be mixed.)
• Type safety
• SSR
• Supports "hover parent, style child" scenarios

And most importantly, we can get a fix in immediately when needed. Without this one, all downstream consumers pay a penalty when we can't fix things fast. We experienced this when we moved to glamor initially.

But just some other questions; why emotion? Why not fela? Or jss?

Fela does have atomic css which is very interesting. One thing I think I am unsure of is TypeScript type safety with these libraries. For example, how do you define an object that can take in both css properties but also selectors, without throwing typesafety out the window?

emotion or glamor:

{
  background: 'red',
  ':hover': {
     background: 'green'
  }
}

The typing for this would basically need to be { [key: string]: string } ... which means you can pass in all sorts of garbage, and get no errors. (Not the end of the world, but it certainly would be nicer to have some typesafety.) This is why we moved selectors to its own property:

{
  background: 'red',
  selectors: {
    ':hover': {
      background: 'green'
    }
  }
}

Now we can ensure that style objects can break when you throw garbage (deprecated css properties for example) into them.

[jeremy-coleman]

I put up a playground repo to aid in the discussion

https://github.com/jeremy-coleman/fabric-playground

I provided a typed version of the emotion theme config using just the IPalette definition.

I also provided examples with styled components and jss, just to kind of show what I'm on about.

For selectors: (straight from the read me) import * as CSS from 'csstype';

const pseudos: { [P in CSS.SimplePseudos]?: CSS.Properties } = { ':hover': { display: 'flex', }, };

but honestly I don't see the point in this if its going to end up as IWhateverCssInterface | string. maybe something like

 ':hover': ReturnType<typeof myStyleFunction>

[jeremy-coleman]

Following up a bit more,

I should have been more clear in my initial post, but emotion is just my recommendation - they all use the same interface though. For ex, I can import CssProperties from glamorous, use React.CssProperties, or whatever else i want, and they're all the same bc they use csstype.

For your requirements: demo from the emotion docs of unit conversion and composition https://emotion.sh/docs/object-styles

For this benchmark https://github.com/tkh44/CSS-IN-JS-Benchmarks , the only takeaway from that you should just use static css for repeating elements, but that's a no brainer. check this out, its much more relevant https://tuchk4.github.io/css-in-js-app/#/ (note how slow the react-jss is AND the considerable improvement of styled-jss)

for selectors, something facepaint should meet the requirements https://github.com/emotion-js/facepaint#pseudo-selectors

It's also noteworthy to show how easy it is to convert from one implementation to another, as long as you're sharing a common interface. literally just npm install the target conversion lib and rollup -c, which means you aren't really coupled to the implementation you choose , as long as you conform to the generally accepted community interface. https://github.com/emotion-js/rebass-emotion/blob/master/rollup.config.js

Also, tools like this, which I successfully ran yesterday to convert an multipage app https://github.com/TejasQ/babel-plugin-glamorous-to-emotion

Why not fela or jss? or cxs or any of the other options.

Fela is nice and fast and also has especially small merged bundle sizes. I forgot where I saw the benchmark, but the fela pre-rendered css bundles were about 1/4th the size of jss. No real downside, besides the much smaller community.

jss (standalone) is ok and has a nice plugin system, but i've found it really terrible to use. mainly because you have this global classes object that is a reference to the generated classes in the head, and I honestly don't understand the process at all or how the classes get merged, a similar feeling i have abut merge-styles. Specifically how you have a styles object whose top level is root, which is supposed to be the top-level style for that element, but I personally find it extremely unclear of what to expect when combining elements or sharing styling. IMO it's much better practice to not use root and to name the top level style as something like mycomponentStyleBase so the hierarchy is always clear. *styled-jss would be a good choice for jss, while keeping the benefits of the jss plugin eco system, it's plenty fast and supports object styles. It would especially be good if you needed to use something like jss-compose to integrate with an existing css lib (which part of my code base i've used to mix with pure css)

there are other considerations that don't show in benchmarks also, especially for libraries that generate styles on first use like styled-components and some jss implementations. Although the benchmark might be fast, the user is still going to get some weird flash or browser stutters the first time they open a drawer because the css was created onClick and the browser hasn't had time to parse it yet. you may consider memory use from memoization important, etc. although I'm guilty of it, saying 'fast' really doesn't mean anything.

Back to the first topic, and what I attempted to show in the repo i put up, is that emotion , jss, or whatever implementation isn't really important, because they can be easily changed. It's the interface of the underlying styles that is crucial in order to be inter-operable. Creating typedefs like IRawStyle and ICssRule , and moving selectors to its own field are sources of conflict that I believe to be unnecessary and will probably lead to more unexpected behaviors and developer frustration than it prevents.

Also +1 for the loadTheme function, which i recently discovered.

import {loadTheme} from 'office-ui-fabric-react'
let theme = loadTheme({})

ReactDOM.render(
    <Fabric>
    <ThemeProvider theme={theme}>
   <app..

for me, doing something like ..

let t1 = createMuiTheme(primary: red)
let t2 = loadTheme({primaryTheme: red})
let t3 = createMyCustomTheme({main: red})

let combinedTheme = merge(t1, t2, t3)
...multiple libs with same theme now, using 1 theme context and 1 css generation utility

there are also many community tools that allow you to do something like this, perhaps augmenting a fabric auto-gen theme:

import {lighten, darken, getLuminance, opacify} from 'polished'

function contrast(baseColor, amount) {
  const luminance = getLuminance(baseColor)
  if (luminance >= 0.5) {
    return darken(amount, baseColor)
  }
  return lighten(amount * (luminance + 0.3), baseColor)
}

export function build(accentColor, baseColor) {
  const backgroundColor = baseColor
  const textColor = contrast(baseColor, 0.75)
  const textMutedColor = opacify(0.6, textColor)

  const borderColor = contrast(backgroundColor, 0.1)
  const accentBackground = `linear-gradient(to bottom, ${lighten(0.1, accentColor )}, ${accentColor})`
  const accentTextColor = contrast(accentColor, 0.75)
  const accentTextMutedColor = opacify(0.6, accentTextColor)

etc..

or tools like this https://github.com/jxnblk/palx

and couple community demos of functionality https://github.com/eugenkiss/7guis-React-TypeScript-MobX/blob/master/src/app/basic.tsx https://github.com/llyys/emotion-tsxstyle/blob/master/src/index.tsx

[dzearing]

Thank you a ton for your well written writeup!

There are a few things you're asking;

Better theme-ability! We do have this in the plan. We actually have a lot of the logic you're describing (color tooling for creating themes, etc) but it's not well organized and documented. We are absolutely tackling this.

I think there are potentially others here; for example, normalize styling. Use some other library such as emotion or jss or glamor which seem to have some standard conventions about css in js. I can say from experience, if I had to choose between type safety and standards, I'd still want type safety. Like I mentioned we started with glamor. Moving to type safe styling caught numerous bugs in the conversion where devs simply had typos, referenced deprecated styling, and didn't realize their intent wasn't being met.

I wonder if there is some compromise here; e.g. like what you're suggesting, provide an interface for you to bring your own css injection system. I'd like to make the library as robust as possible. One possibility we have is to provide the "css provider" through context. I love decoupling. E.g. expose fela provider, use fela for rule registration. It's possible we could even provide a transform which demotes "selectors" a level up, to make it compatible with other providers. I don't know, just an idea.

I took a look at https://tuchk4.github.io/css-in-js-app and made a change to compare merge-styles against emotion, fela, etc. I modified the config to render 1000 different components. Results on my macbook in chrome:

If you test in Edge, you'll see Emotion starts really lagging. We have even more perf improvements to make in merge-styles, but it's clearly already faster than others.

I also realized I left the wrong perf link earlier, you can look at css in js benchmarks here:

https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

So, I think while we do want to support brining your own css injection mechanisms, I want to also be clear that you'd probably take a performance hit and a type safety hit if you do that. We want both of those things and more.

[dzearing]

FWIW I submitted a PR to that benchmark example here: https://github.com/tuchk4/css-in-js-app/pull/12

Feel free to pull the branch.

[dzearing]

Also wrt naming conventions, in merge-styles, you can provide names that make sense by using 'displayName':

mergeStyles({
  displayName: 'foo',
  background: 'red'
}); // generates "foo-0"

If you use mergeStyleSets, it will use the part name in the classname:

mergeStyleSets({
  a: { background: 'red' },
  b: { background: 'green' },
});  // { a: "a-0", b: "b-1" }

Merge styles also allows you to mix in string classnames that it doesn't recognize:

mergeStyles('foo', 'bar', 'baz', { background: 'red' }); // generates "foo bar baz css-0"

If you merge a classname that was generated by mergeStyles, it will ensure specificity is kept as well!

mergeStyles({ background: 'red' }); // css-0
mergeStyles({ background: 'blue' }); // css-1
mergeStyles('css-0', 'css-1'); // css-1

[dzearing]

But I also asked about fela, because we're considering it as one of the candidates we'd support. It's close to perf of merge-styles, but it supports atomic css, which we're a fan of as it means as your app loads more code, you end up registering less and less styles and having greater cache hits.

[jeremy-coleman]

Nice I will check it out, I was working on updating that repo myself to compare, as the dependencies are pretty far out of date. I think most of the 'styled' libs are using the insertRule api now https://medium.com/styled-components/v3-1-0-such-perf-wow-many-streams-c45c434dbd03

I read this article the other day. 1) its hilarious but 2) I thought it could be especially relevant to css

https://itnext.io/how-i-wrote-the-worlds-fastest-react-memoization-library-535f89fc4a17 TLDR on that, it has very high performance for large objects, but less so for small objects (when it doesn't matter in the first place)

[jeremy-coleman]

https://github.com/jeremy-coleman/mui-fab-demo

i put up another demo using just create react app for ease of use

it uses a merged context of loadTheme and createMuiTheme with the ability to change, updating for both under a shared context from the 'theming' package

[jeremy-coleman]

a follow up thought on using Css variables instead of a JSS solution (the primary benefit being the implementation is framework agnostic - notice the theme related functions have to relation to react props at all)

import { flex, horizontal } from 'csstips';
import { observer } from 'mobx-react';
import * as React from 'react';
import { classes, style } from 'typestyle';

let insertBodyBarTwo = async () => void await document.body.style.setProperty("--primary", 'green');
let setPrimaryThemeVariables = async (color) => void await document.body.style.setProperty("--primary", color);
let setInnerPrimaryThemeVariables = async (elementQuery, color) => void await document.querySelector<any>(`${elementQuery}`).style.setProperty("--primary", color);
let pickRandomColor = () => "#"+((1<<24)*Math.random()|0).toString(16);

//this won't be duplicated - thanks typestyle (freestyle in production)
// typestyle has an overhead of ~15kb which is kind of alot if you don't need much insert-css 
// 

let THEME = {
 backgroundColor: style({backgroundColor: 'var(--primary)'})
}

const ThemeButton = observer(() => 
<button onClick={() => {setPrimaryThemeVariables(pickRandomColor())}}>
RNG Color(--primary)
</button>
)

const ThemeButtonInner = observer(() => 
<button onClick={() => setInnerPrimaryThemeVariables('#main-content-body-child', pickRandomColor())}>
RNG Color child(--primary)
</button>
)

const ThemeButtonInnerChild = observer(() => 
<button onClick={() => setInnerPrimaryThemeVariables('#main-content-body-child-of-child', pickRandomColor())}>
RNG Color child of child(--primary)
</button>
)

const ThemeButtonTwo = observer(() => 
<button onClick={() => {insertBodyBarTwo()}}>reset body</button>
);

export let AboutPage = observer(() =>
<div style={{display: 'flex', flex: '1 1 auto', flexDirection: 'column', justifyContent: 'center', textAlign: 'center'}}>
  <div style={{height: 50, background: 'skyblue'}}>
    <div style={{display: 'flex', flexDirection: 'column', justifyContent: 'center', textAlign: 'center'}}>
    Css variables demo
    <div style={{display: 'flex', flexDirection: 'row', justifyContent: 'center'}}>
    <ThemeButton/>
    <ThemeButtonTwo/>
    <ThemeButtonInner/>
    <ThemeButtonInnerChild/>
    </div>
    </div>

  </div>
  <div className={style(flex, horizontal)}>
    <div className={classes(style(flex), THEME.backgroundColor)}>
      Body
      <div className={THEME.backgroundColor} id='main-content-body-child'>
        using same variable as parent
          <div className={THEME.backgroundColor}>
          and it continues to nest
                    <div id='main-content-body-child-of-child' style={{backgroundColor: 'var(--primary)'}}>
                      child of child
                          <div style={{backgroundColor: 'var(--primary)'}}>
                        child of child of child - see code comments for reverting to main theme
                          </div>
                    </div>
          </div>
      </div>

      <div style={{backgroundColor: 'var(--primary)'}}>
      back to primary scope
      </div>
    </div>
  </div>
</div>
)

// in practice, the nested children would be consumers of a library wishing to over-ride the default theme
// :root {
  /* colors */
  // --primary: #607d8b;
  // --primary-dark: #34515e;
  // --primary-light: #8eacbb;
  // --secondary: #3f51b5;
  // --secondary-dark: #002984;
  // --secondary-light: #757de8;

// there is an issue when there is a multi-tiered consumer hierarchy though
// Case: a tertiary consumer may use the default ux vendor theme, which was not over-riding the tier 1 vendor theme at design time
//  however, if a secondary layer provider later changes its design system, the tertiary will be effected 
// the tertiary can easily revert back to the vendor theme with a simple theme definition on their root component, however
// as long as they wrap their application in the equivalent of a JssThemeProvider that just defines whatever  css --vars of their initial design,
// they will be protected

[arniebradfo]

+1 for using css vars.

[dzearing]

CSS variables on my mind as well. They solve a number of problems:

• theming in a box scenarios
• overriding key things without knowing the right selectors

IE11 support is a concern. Not sure how to start using them without saying we don't support IE11.

[jeremy-coleman]

Theres actually nothing stopping you from using css vars in the theme definition. Ie: dont actually use any color definitions, only make the javascript vars point to cssvar strings, then define those in the head. You can easy make bootstrap, material, and fabric all use the same brand colors this way. Console logging the theme and copy and pasting the object can be helpful to get the infos you need and dedupe some things . You can also use whatever color generator this way, for ex use mui reacts theme cascade on fabric components

I wrote a little throwaway app yesterday using preact vue lit and react via the vue cli , works just great;) now for blazor !

[arniebradfo]

I was hoping for official support for css vars in place of the scss vars, with themes updating a single block of css vars.

Here's what I'm going with today:

import * as FluentTheme from "@uifabric/fluent-theme";
import * as FabricUiStyling from "@uifabric/styling";

// Creates a <style/> element full of fabric/fluent --css-custom-property:value;
const createFabricCssVarsStyleSheet = () => {

  // create a list of all the cssVar namespace/sets we want to use
  const fabricCssSetsMap = {

    CommunicationColors: FluentTheme.CommunicationColors,
    ColorNeutral: FluentTheme.NeutralColors,
    SharedColors: FluentTheme.SharedColors,

    FontWeights: FabricUiStyling.FontWeights,
    FontSizes: FluentTheme.FontSizes,
    IconFontSizes: FabricUiStyling.IconFontSizes,
    noWrap: FabricUiStyling.noWrap,

    Depths: FluentTheme.Depths,
    ZIndexes: FabricUiStyling.ZIndexes,

    // MotionAnimations: FluentTheme.MotionAnimations, // requires css @keyframes from somewhere else?
    MotionDurations: FluentTheme.MotionDurations,
    MotionTimings: FluentTheme.MotionTimings,

  };

  let cssProperties = '';

  // for each css namespace we've defined above
  Object.keys(fabricCssSetsMap).forEach(cssNamespace => {
    const fabricCssSet = fabricCssSetsMap[cssNamespace];

    // for each css cssVar:cssValue pair in each namespace 
    Object.keys(fabricCssSet).forEach(cssVar => {
      const cssValue = fabricCssSet[cssVar];

      // create css var (custom properties) --MS_Namespace_VarName: value;
      cssProperties += `  --MS_${cssNamespace}_${cssVar}:${cssValue};\n`;
    })
  })

  // create a <style/> element and add the cssVars to it under the :root{} selector
  const fluentVarsStyle = document.createElement('style');
  fluentVarsStyle.type = 'text/css';
  fluentVarsStyle.id = 'fluentVars';
  fluentVarsStyle.appendChild(document.createTextNode(`:root{\n${cssProperties}}`))

  // return the <style/> element
  return fluentVarsStyle;
}
export default createFabricCssVarsStyleSheet;

// In index.js or root app component:
document.head.appendChild(createFabricCssVarsStyleSheet ());

which creates:

:root{
  --MS_CommunicationColors_shade30:#004578;
  --MS_CommunicationColors_shade20:#005a9e;
  --MS_CommunicationColors_shade10:#106ebe;
  --MS_CommunicationColors_primary:#0078d4;
  --MS_CommunicationColors_tint10:#2b88d8;
  --MS_CommunicationColors_tint20:#c7e0f4;
  --MS_CommunicationColors_tint30:#deecf9;
  --MS_CommunicationColors_tint40:#eff6fc;
  --MS_Depths_depth0:0 0 0 0 transparent;
  --MS_Depths_depth4:0 1.6px 3.6px 0 rgba(0, 0, 0, 0.132), 0 0.3px 0.9px 0 rgba(0, 0, 0, 0.108);
  --MS_Depths_depth8:0 3.2px 7.2px 0 rgba(0, 0, 0, 0.132), 0 0.6px 1.8px 0 rgba(0, 0, 0, 0.108);
  --MS_Depths_depth16:0 6.4px 14.4px 0 rgba(0, 0, 0, 0.132), 0 1.2px 3.6px 0 rgba(0, 0, 0, 0.108);
  --MS_Depths_depth64:0 25.6px 57.6px 0 rgba(0, 0, 0, 0.22), 0 4.8px 14.4px 0 rgba(0, 0, 0, 0.18);
  --MS_FontSizes_size10:10px;
  --MS_FontSizes_size12:12px;
  --MS_FontSizes_size14:14px;
  /* ...more custom properties... */
  --MS_ZIndexes_FocusStyle:1;
  --MS_ZIndexes_Coachmark:1000;
  --MS_ZIndexes_Layer:1000000;
  --MS_ZIndexes_KeytipLayer:1000001;
  --MS_noWrap_overflow:hidden;
  --MS_noWrap_textOverflow:ellipsis;
  --MS_noWrap_whiteSpace:nowrap;
}

And then I scope locally by importing regular component.module.css files

.someReactComponent{
  margin: 8px;
  box-shadow: var(--MS_Depths_depth16);
}

Official support could make all these vars available plus theme vars.

Maybe the names should follow the scss standard syntax: --ms-depth-16 instead of --MS_Depths_depth16

mergeStyles() is weird and kinda unnecessary. No dev wants to re-learn something as basic as css just to use the Fabric UI library.

Also mergeStyles() css cannot be edited in chrome dev tools, and updating any mergeStyles() css requires a recompile. Css modules don't suffer from these developer inconveniences.

[jeremy-coleman]

You can use this to just take the createTheme() function and turn it into a cas var theme(no need to deal with sass at all) https://github.com/jeremy-coleman/garbo/blob/master/cssVars.md

The only things you really need are mergeStyleSets, getTheme, and maybe createTheme. Mergestyles = The css() or style() function from other jss libs, mergestylesets=stylesheet version(multirule)

[jeremy-coleman]

You can also create overridable styles using myComponentCss = (theme = getTheme()) => meegeStyleSets({ Root:{}, Somepart:{ BackgroundColor: theme.palette.primaryTheme} })

[arniebradfo]

@jeremy-coleman My goal is to avoid using any JSS. I just want to write CSS.

[jeremy-coleman]

They have a webpack plugin that replaces the sass loader to load themed styles

Used something like this.. use: [ { loader: "@microsoft/loader-load-themed-styles" }, { loader: "css-loader" } ]

I feel like thats not what youre looking for though

[jeremy-coleman]

@dzearing i think the infastructure is already there , really very little needs to be changed. Keep everything the same as it is now, except just add a top level if statement to check for positive support , then define the theme (still client side) with js as its done now , just instead of actual colors you map the js var to a css var. so theme.palette.primaryTheme: ‘var(—themePrimary)’ or if no var support just ‘blue’ . Now imagine the user or designer whoever is dragging a slider that adjusts the color in a theme picker. With css vars , only ~15 vars need to be changed and should be modified outside of the scope of ui fabric and even react. You can call setProperty directly (which will behave like a jssprovider) or just rewrite vars in the head to change everything (similar to a bootstrap theme or something) . Without css vars , the js on the client (or server) will just regenerate colors down the tree, how it does now. So the end css is going to either be something like backgroundColor: ‘var(—primaryTheme)’ Or backgroundColor: ‘blue’

tried to make a demo but #bundle problems. hopeless

[dzearing]

@layershifter This particular issue gives some background on past conversations we've had about moving the styling system to something else. I think it's good to read, but also difficult to action on at this point. We've done work over the last year and continue refining the makeStyles solution, but it's good to read through this issue for context.

Some key points:

• Some people just want vanilla css
• Some people want to write components with { other css system }
• Inventing another css utility is a tough battle because it will need to mix with existing systems, so it has to be worth it

i wrote mergeStyles a while ago because it solved the bullets I listed above:

• Small bundle size
• Great perf over other libraries (not sure where the "emotion is faster" came from, I have not seen that.)
• Auto prefixing (numbers to units)
• Auto rtl flipping
• Can translate classnames to objects (e.g. create a class, inject it, and it can be mixed.)
• Type safety (we later gave up on this a bit to loosen typings for selectors)
• SSR (this works using namespacing, but hydration doesn't always result in the same classnames since they're numerically incremented instead of hashed)
• Supports "hover parent, style child" scenarios

Still think it works well enough for most scenarios, but again the struggle isn't really the css system itself but the proliferation of solutions not necessarily working great together, and all the different patterns and tools they introduce. Not suggesting anything here, but this conversation always makes me question why bother with anything more complicated than css modules.

I think it's safe to close this, as I believe you're tracking your progress in other issues. If so please link them.

[msft-fluent-ui-bot]

Because this issue has not had activity for over 150 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.