Align on HTML attribute/property casing (ie not camelCase)

[titoBouzout]

Summary

I am cross-posting an issue I made with Preact and Voby
preactjs/preact#4555
vobyjs/voby#45

[guillaumebrunerie]

It's not "made up", it's camel case, and it's by design. See #2882 or #10139.

[titoBouzout]

Thanks, it is "made up camelCase" then, because such properties don't exist in the DOM elements, and its just confusing.
Its confusing even within the framework, if you ever do node.autoPlay = true for whatever reason, it won't do what you expect.

I think React 19 is a great opportunity to drop these and align more with how HTML actually is.

[josephsavona]

Thanks for posting. Quick answer is that this is a major breaking change and would definitely not happen as part of React 19 (implied by the title of your post). It's something we will consider for a future major, but note that there is some subtlety around some properties, since attributes like class are reserved names in JavaScript.

[titoBouzout]

Thanks @josephsavona that same thing has been said in 2017.. I think its time specially with the introduction of web-components support to make sure we align more with HTML. It shouldn't be that hard, and some stuff like className could stay in place maybe given muscle memory.... It has so many benefits:

• aligns with how html actually is
• removes confusion from people
• makes the code smaller
• possibly makes the code faster as it needs less transformations
• its what people actually want, for example in Preact there are at least two comments from maintainers in some way expressing interest Get rid of made up propNames preactjs/preact#4555 (comment) Get rid of made up propNames preactjs/preact#4555 (comment)

If you can consider it seriously, like in for real this time, the whole ecosystem will be welcome, because this doesn't only impact React, it also impacts people trying to learn what HTML is, and people trying to explore other approaches....

[titoBouzout]

@gaearon can you make a case for a tiny last effort push to deal with this problem before React 19 becomes a thing? Thanks for your consideration

[rschristian]

I think every framework but React has had a significant number of people ask questions like "What you mean autoPlay is not a prop? It's what I use in React" -- Preact more so than others most likely, as we somewhat awkwardly straddle the React & standard attrs/props divide, but all have received these questions. I agree with @titoBouzout whole heatedly-here, it's having a major negative impact on the way people learn to use the platform. Users learn React and don't realize how non-transferable some of this knowledge is, creating some amount of lock-in. I understand the original reasoning, the DOM can be somewhat inconsistent, and I don't think lock-in is a goal or intentional in any way, but it is occurring.

While I fully appreciate the truly massive scale you all work on here, and just how slow a big ship like this turns, if there was interest, I think the front-end ecosystem as a whole would appreciate seeing it start to move sooner rather than later. A fairly gentle rollout over 3 majors (say, 1. deprecate types, 2. remove types, 3. remove support, if even possible?) might be 4+ years away, and if you only begin to consider it once work begins on v20, well, we'll be stuck with this much longer.

Just something to consider anyhow. I think it'd do a lot of good for the web ecosystem to use the standardized casing of DOM properties, even if we can all agree they are a bit lacking from time to time.

[titoBouzout]

This is the full list of keys to deprecate is really not that hard, at least mark them as deprecated

🗑 🛑 allowTransparency
🗑 🛑 classID
🗑 🛑 keyParams
🗑 🛑 keyType
🗑 🛑 mediaGroup
🛑 allowFullScreen
🛑 autoComplete
🛑 autoFocus
🛑 autoPlay
🛑 charSet
🛑 controlsList
🛑 crossOrigin
🛑 encType
🛑 enterKeyHint (you do not support his one)
🛑 formEncType
🛑 hrefLang
🛑 imageSrcSet
🛑 playsInline
🛑 popoverTarget (you do not support his one)
🛑 srcDoc
🛑 srcLang
🛑 srcSet