ClassName and Class inconsistency

[mikeybox]

Standard elements and custom elements have a diverging API in the case of the class attribute (and for), they should be consistent to aid developer use. I would suggest that the custom-element naming is the better solution. While class and for are keywords that is obviously mitigated by the fact they're used as object properties

[nhunzaker]

What do you think, @gaearon, particularly after #7311? We already alias className to class under the hood. What if we just supported both without a warning?

Similarly for for.

[aweary]

Supporting both class and className sounds reasonable to me, with the downside being that it introduces more overhead for keeping a React codebase consistent. Though, that can be mitigated by linting tools.

As long as this doesn't introduce a problem with any of our supported browsers (IE8 would throw when accessing props.class, but that's not a problem anymore) I'm in favor of allowing it.

[aweary]

This behavior has changed as of React 16, see DOM Attributes in React 16. Using class will result in a warning, but it will still render the attribute. It was decided that we should continue to recommend using the existing attribute names, but be more lenient about rendering them to the DOM.

I don't believe there's any intention to move to class/ for, etc as the canonical names, so I'm going to close this out. Thanks!

[r3wt]

fucking idiots

[nhunzaker]

Sorry you feel this way, but this sort of behavior is unacceptable. Locking this thread.