[docs] All the docs actual content

[brijeshb42]

• I have followed (at least) the PR section of the contributing guide.

[Janpot]

Gotta love stylex for fixing this. It's so counterintuitive that just swapping the position of two global variables affects the behavior of where they are applied. I mean, imagine the following two snippets print a different result.

const a = 5;
const b = 7;
console.log(a / b);
// ---
const b = 7;
const a = 5;
console.log(a / b);

[brijeshb42]

IMO, the correct analogy (in CSS context) here will be

const a = 5;
const b = 7;
console.log(a / b);
// vs
console.log(b / a);

Both have different outputs with same order of variable declaration.

Besides, the selling point of stylex is the same as tailwind (when used with something like tailwind-merge), which is atomic css.
This is the main reason due to which, with a runtime check in place, they are able to dedupe the class names based on the property they are targetting and only keep the last class name of a property. So essentially, it applies only one classname for a particular property.

OTOH, Pigment's output is the same as when you'd write CSS modules.

[Janpot]

Both have different outputs with same order of variable declaration.

Exactly, in javascript, the order at call site is important, not at declaration site.

OTOH, Pigment's output is the same as when you'd write CSS modules.

Indeed, that's what's counterintuitive, I'm writing javascript, but I have to keep CSS semantics in mind. The real danger comes when utilities are defined in other files and composed. Now you don't have a module-local record of the order of declaration. You can't even reliably influence it as it may already have been imported somewhere else in a different order.

Besides, the selling point of stylex is the same as tailwind (when used with something like tailwind-merge), which is atomic css.

Sure this is done under the hood with atomic CSS and a lightweight runtime, but I don't think that matters. It's not at all its selling point to me, I don't care how they solve this problem, I care that the semantics match the environment I'm writing in, which is javascript, not css.

[o-alexandrov]

The real danger comes when utilities are defined in other files and composed. Now you don't have a module-local record of the order of declaration. You can't even reliably influence it as it may already have been imported somewhere else in a different order.

We've hit this problem w/ pigment a few times; just want to highlight this problem is real in <5 frontend devs projects, and should be a lot worse when many devs in a project attempt to reuse each others' styles from many different files

[Janpot]

Suggested change

	import { css } from '@pigment-css/react-new';
	import { styled } from '@pigment-css/react-new';

[Janpot]

https://deploy-preview-390--pigment-css.netlify.app/features/theming 404s for me

edit: actually, every page under Theming 404s

[brijeshb42]

BTW, this PR is in draft mode right now. Not ready for review. I need review for this PR - #367