Why are attribute names "class" and "for" discouraged?

[callumlocke]

From the docs:

Note:
Since JSX is JavaScript, identifiers such as class and for are discouraged as XML attribute names. Instead, React DOM components expect DOM property names like className and htmlFor, respectively.

But the JSX compiler seems to be smart enough to quote keys like "class" and "for" (so they'll work fine even in pre-ES5 environments). So what's the problem? Why are they discouraged, and what exactly does that mean?

[zpao]

The wording there is a bit confusing but here's a short answer:

Our DOM components use (mostly) the JS API so we opted to use the JS properties (node.className, not node.class).

You're welcome to use class and for in your own components. Not all JSX compilers quote keys (eg react-tools) so just be aware of your own constraints and tool choices.

[jimfb]

If the docs are confusing, we should leave the issue open to fix them.

[kevinSuttle]

I thought the same about the type attribute.

[chicoxyzzy]

type is not reserved word in JS (but it is in TS and Flow)

You're welcome to use class and for in your own components. Not all JSX compilers quote keys (eg react-tools) so just be aware of your own constraints and tool choices.

Also those keys are hard to add typings to using TypeScript or Flow

[kevinSuttle]

Right, but there are several type attributes in HTML, particularly in input and button elements.

[nhunzaker]

I'd like to see support for direct use of class and for. There is overlap with #5926, and conversation has picked up again there, so I'll close this out.

[karansinghgit]

It may not come under best practices, but will I face any issues in the future if I use class and not className?

[sarimarton]

In app code I would say it's outright recommendable to use class, especially if you want your codebase to be a lot more ergonomic with tailwind. Suppressing the warning can be done with a console.log override, and typing can be added easily as well. In library code, I would support both.