It’s JS, but not HTML.

And most of the time you see it you’re making JSX elements, where you would expect to use the word ‘class’.

I think they’re right it’s more consistent with what people would expect to happen.

The fact there is a special note in the docs calling out that everyone gets it wrong is a sign it was a problematic choice.

JSX attributes aren't HTML attributes. One way you can tell is because they don't have any namespace whatsoever.

Similarly when you add a style to an element you don't get to use `background-color` for instance, it's `backgroundColor`. Yet they're not revisiting that decision, even though it's exactly the same, i.e. `background-color` can't be used to to a JS syntax conflict.

It seems arbitrary to make JSX attributes pertaining to a DOM that don't have a namespace match XML attributes in a markup language... while not at the same time doing the same to the CSS object model property names for instance.

The backgroundColor vs background-color thing has nothing to do with React.

That is more JSS which is one attempt at CSS-in-JSS. The removed hyphen is needed because JSS requires property names as object property names where hyphens can be problematic.

Other CSS-in-JSS libraries, such as emotion.sh, has support for CSS (vs JSS above) inside of JS, including React components, and can keep default CSS syntax. Example from the emotion.sh homepage:

  const Link = styled.a`
    min-width: 12rem;
    margin: 0 auto 20px;
    padding: ${props => props.primary ? 18 : 16}px;
    border-radius: 5px;
    text-decoration: none;
    border: ${props =>
      props.primary ? 'none' : '3px solid currentColor'};
    background: ${props =>
      props.primary &&
      'linear-gradient(90deg, #D26AC2, #46C9E5)'};
    color: ${props =>
      props.primary ? '#1D2029' : '#D26AC2'};
    &:hover {
      opacity: 0.95;
    }
    @media (min-width: 768px) {
      margin: 0 20px 0 0;
      &:last-child {
        margin: 0;
      }
    }
  `

If you notice variables and props are available via string interpolation. emotion.sh also makes inline styling easier:

  render(
    <div
      className={css`
        background-color: hotpink;
        &:hover {
          color: ${color};
        }
      `}>
      This has a hotpink background.
    </div>
  )

[edited for formatting and word choice]

JSS? `<div style={{backgroundColor: 'black'}} />` is standard React / ReactDOM.

> The backgroundColor vs background-color thing has nothing to do with React.

You’re right, but it absolutely has to do with ReactDOM which is being discussed here.

Which, btw, is called ReactDOM not ReactHTMLandCSSandStuff.

Although reading Dan Abramov’s further comment ReactDOM is a bit of a misnomer, but from an API perspective it’s definitely more DOM especially with the CSS precedent and lack of XML namespaces vs. the `aria` attributes being the only major evidence to the contrary. I mean, sure it only sets `x` properties directly, but as an end user of the library what do I care about the internal implementation?

Edit: A new `classList` property that accepts an array would be nice as that way anyone using `className` has a superior API to migrate to and stay away from this change entirely. It’s not like it’s setting it directly so just convert to a DOMTokenList on the fly.

Oops I totally forgot about inline styling like that without a preprossor. You are correct.

Although it does seem like ReactDOM already does some weird stuff already in regards to vendor prefixing.

Exactly. It’s JS and not HTML.

Because in JS that attribute/property is `className`. Because `class` is a reserved name in JS.

Same goes for `htmlFor`, for example. So now you will have a situation where all props directly correspond to DOM APIs, and one prop that isn’t. A strange choice given how the stated goal is to be more consistent with DOM APIs.

And yet the entire reason for using JSX in the first place is that it looks like HTML. This is a reasonable change.

So I wrote in detail why I think `class` is the right choice here. Hope it helps.

https://github.com/facebook/react/issues/13525#issuecomment-...

Leaving my comment here as well for increased visibility:

Current state of things:

- React is inconsistent

- API is camelCase

Proposed state of things:

- React is inconsistent

- API is camelCase

- `className` -> `class`

Perceived benefits:

> If React was open sourced today, it seems like the pros of allowing class (closer conceptually to what most people expect, less typing for the most commonly used prop) outweigh the downsides (slightly more typing to intercept it — in which cases you'll probably just want the spread operator anyway).

Actual downsides:

- the entire ecosystem that depends on `className` stops working (huge upgrade effort)

- the entire vast body of books, tutorials, examples, code, posts, articles becomes ever so slightly invalid

- the only valid JS remaining is additional typing: `const {class: cls} = props`. Every other possible use-case in plain JS becomes invalid

- React API remains inconsistent, and breaks further assumptions (why `htmlFor` not `for` etc.)

If I were a product manager, my immediate reaction to the change would be: wat?

It will be fully consistent if we change `for` too (and a couple of rare SVG attributes).

So, with `for` you will introduce even more JS-incompatibility, break even mire stuff (basically, all forms), and the reason for the change is?.. Somewhat less typing (which is already covered by autocomplete in everything but Windows Notepad)?

onChange is going to affect forms anyway. So it’s not like this code wouldn’t need to be revisited.

> Migrate from onChange to onInput... It has been confusing that React uses a different event name for what's known as input event in the DOM.

This change is at least somewhat warranted, as it makes things more consistent with the DOM.

What are the reasons for `className->class`, `htmlFor->for` besides the "it's longer to type" when the many downsides to the decisions have been spelled out in no uncertain detail in the issue?

It can't be "We're already allowing passing class down to the DOM node in React 16" because you're confusing a bad decision (allowing `class`) with requirements for the change ("we now have to change className to class"). Honestly, the whole className->class lacks any real justification.

So yes, to quote yourself:

> using a React component should feel like idiomatic JavaScript.

Idiomatic Javascript is:

- no reserved words as variable names (`class` and `for` are reserved words)

- className, htmlFor etc. because that's what they are in Javascript

- in your insistence that everything needs to be camelCase you forget that `className` and `htmlFor` are already camelCase

So the main issue you seem to have is this:

> React Is Not Just Setting Properties

^ this is what causes all the problems, and this is what needs to change. Not additional confusion where "idiomatic Javascript" somehow ends up having to use reserved words and workarounds for those reserved words.

Highly recommend reading Dan's reasoning; it makes a lot of sense. This quote is as close as I can get to distilling it:

>"I think this is the primary reason it's desirable for props like tabIndex, cellSpacing, and most other DOM-related props to follow the camelCase convention. It's not because they're DOM property names. It's because they often end up in component APIs. And we want component APIs to be consistently camelCase."

But both class and className are camelCased.

I don't understand the "but" in your uncontroversial comment.

It seemed to me that the paragraph you quoted does not much illuminate why one should choose for one or the other.

Your argument is addressed by Dan Abramov in the comments on the Github issue -

https://github.com/facebook/react/issues/13525#issuecomment-...

tl;dr, There's already a lot of inconsistency, this is not a good argument.

That said, I don't like the className->class change either. It's a reserved keyword, it always made perfect sense why they originally went with className.