Feature request: support for human-readable css class names

[resource11]

Hey y'all,

Thanks for all your work in creating this new CSS API! This tool will be better with the option to support human-readable CSS class names. I realize this is with the nebulous region of your architectural principles. However... Users who rely on changing CSS classes for accessibility reasons right in the browser will be grateful you are considering them.

[necolas]

StyleX generates "atomic" or "utility" css rules, which means class names contain little more semantic information than inline styles would. Whether the class names are human readable or not, they can't reliably be used to target a specific UI component with style changes.

[derekjwilliams]

I know this thread is a year old, but there is a use case where having known classnames ahead of time would be beneficial, Lexical themes. e.g.

const lexicalTheme = {
  ltr: 'ltr',
  rtl: 'rtl',
  paragraph: 'editor-paragraph',
  ...
}

In the above, 'ltr', 'rtl', and 'editor-paragraph' are class names at run time. For example:

<p class="editor-paragraph"></p>

in the rendered html in a React application

I'd be curious how Meta handles this since they use (and created) both StlyeX and Lexical

[nmn]

You can use StyleX classes directly for setting Lexical themes:

const lexicalTheme = {
  ltr: 'ltr',
  rtl: 'rtl',
  paragraph: stylex.props(styles.paragraph).className,
  ...
}

NOTE: You will have to be careful about not using Dynamic styles when doing this.

[necolas]

We style them with StyleX. Lexical has APIs that allow the relevant attributes to be set.

[nmn]

I know this wasn't the original question, but there's related questions here.

1. Perhaps what you actually want is the ability to apply additional class names that don't affect styling? In such scenarios, aria attributes are probably a better option. But if you

2. You might want classNames for debugging in the browser. We provide the dev option to add classNames that tell you the filename__variableName.keyname for that. The class names that actually apply styles are hashes. We can probably consider using patterns for common styles in the future, but we would do that to shorten the strings and not for debuggability.

[resource11]

Excellent. Is the enabling debugging classes feature documented somewhere? I'm currently responding in a mobile UI and don't have immediate access to check.

Re:

I think it makes sense to have a separate attribute with caconical IDs, but for lazy developers, this is the easiest thing to do.

Can you define "lazy" here? You're breaking my neurospicy brain. 😅

[nmn]

Is the enabling debugging classes feature documented somewhere?

Yeah, just set the dev option to true and the runtimeInjection option to false.

Can you define "lazy"

This was a reference to your problem statement: developers shipping inaccessible UIs that end-users need to hack around. I was suggesting that it would make more sense to provide data-id attributes to make this easier for end-users, but that developers that don't care about a11y, probably wouldn't care about adding these data-id attributes either. The dev class names are automatic, so it's one fewer thing that you can forget to do.

[resource11]

Ahhh, I see.

Yes, using data-id attributes can be useful, depending on your CSS architectural strategy. YMMV. However. Even people who care about a11y and are not lazy by that definition can implement things with good intentions, and unintentionally make things harder to use or worse. That's a topic for another day.

Thanks for clarifying on the "lazy", and for pointing out where the debugging classes feature is documented. Appreciate your work.

[nmn]

I regret being spicy for no reason with the lazy.

[resource11]

Oh... you were being spicy. And, having a thread with... a neurospicy person (me). Who is Captain Literal when nuance is missing. Ooof. 😅

Well, at least the outcome provided clarity and the necessary information to move forward!

[thevisioner]

Continuing discussion on Developer Experience, I'd like to provide some insights from my role as a front-end developer. My typical workflow involves creating layouts and styles, and subsequently testing them in the Chrome developer console. I recognize the significance of Atomic CSS, particularly in the context of large-scale projects, and I am genuinely eager to utilize a type-safe CSS solution that is compatible with React Server Components. However, I've found that my current workflow is not feasible (please refer to the attached screenshot for more details). And I also want to highlight.. in relation to CSS custom properties (variables). The meaning and context are not perceptible.

I'm interested to know if you have any recommendations or if you've contemplated similar CSS development workflows in your planning. I suspect that this is not a situation unique to me, but rather a routine part of daily CSS work for many developers. I would greatly appreciate any thoughts or guidance on this matter.

[nmn]

Yes. This can be a bit of an adjustment. Here's my workflow when working with StyleX to build UIs:

1. Instead of editing existing CSS rule, work with inline styles (at the top of the sidebar)
2. Use the debug classNames to edit the source code directly.

There have been some prototypes for building dev tools to make this better, so I hope that'll exist one day.

[thevisioner]

Given the potential benefits to a developer's workflow, it may be worth exploring the feasibility of different CSS output configurations in development and production environments. Ideally, one would preserve the CSS style declaration block structure defined in the source code. Also, I think it would be useful to keep the CSS property (variable) names intact. Appreciate your insight.

[nmn]

Ideally, one would preserve the CSS style declaration block structure defined in the source code.

This is not feasible. StyleX generates atomic styles (one style per class) and that is a core design detail that pretty much everything else depends on.

We are looking into a few ways to improve the debugging experience:

1. The debugging class names like page__styles.desc should show the relative file path instead like app/about/page__styles.dec
2. We're investigating if we can generate an empty CSS rule for these debug classNames which somehow contains a source map so that the declaration in JS can show up in dev tools.
3. Finally, there may eventually be a dev tools extension to give you a good and familiar experience.

I think it would be useful to keep the CSS property (variable) names intact.
Yes. This is valuable. Specially in development. I've already been thinking about this, and I think it's possible to implement.

---

NOTE: we do have higher priority tasks we need to tackle first.

[thevisioner]

Thanks for the extended answer. I appreciate your time and the work of all contributors. 💪
Still, I'm eager to see how the project develops. 🙏