Some DOM props do not match the spec. Do we "fix" them or give up saying props match the DOM spec?

[dantman]

The props for React DOM elements is supposed to be based on DOM properties. Hence why className and htmlFor are used and supposedly why all the prop names are camelCase.

However the eager camelCasing decided by React doesn't actually match up the spec in a number of cases. In a number of cases the spec defines non-camelcase properties which are used in the browser while React defines a non-spec camelCase prop.

HTMLImageElement

• srcSet (actually srcset)

HTMLFormElement

• autoComplete (actually autocomplete)
• encType (actually enctype)

HTMLMediaElement

• autoPlay (actually autoplay)

etc...

---

This leaves us in an awkward situation where "React DOM props are based on DOM property names not HTML attribute names" is used to justify sticking with className and htmlFor while a number of props don't actually use the same name as they use in the dom.

If we want to fix this I think there are two options:

A) We keep saying that React uses the DOM property names, and deprecate srcSet, autoComplete, encType, autoPlay, etc... with the same warnings you get when using class="" in JSX.

B) We stop saying React DOM props are based on DOM properties and start saying something like:

React DOM props for HTML elements are camelCased props loosely based on DOM property names which are often but not always camelCased. This aligns with the common practice of using camelCased properties in JavaScript. And avoids the need to quote prop names for attributes that use characters which are illegal in JS, such as accept-charset. But does so without forcing developers to continually consult the HTML spec to know when a property is supposed to be camelCase and when it is not.

However if we choose B then there are probably going to be people arguing that the reason why className and htmlFor are used became invalid in ES5 when reserved words were made valid in property names and object literals. And that React should start supporting class and for. Because sticking with ES3 rules doesn't make sense when React requires the environment to be shimmed and shamed to fit ES5 and most users of React use JSX which is either part of an ES6 environment or at least incorporates some ES6 syntax into the JSX syntax.

[sophiebits]

B is correct. See also #4433, particularly my reply.

[andrewplummer]

This issue has been closed for a while but it's still very inconsistent. I get that looking up the spec is a pain, but "words" that aren't even words like "srcset" don't really feel intuitive to be camel cased in the first place.

This may be a separate issue but more importantly react-dom/server spits out <img srcSet="" /> which makes my tests leveraging enzyme fail due to a single character.