Add `class` & `for` aliases for `className` and `htmlFor`

[jakearchibald]

https://dom.spec.whatwg.org/#dom-element-classname
https://html.spec.whatwg.org/multipage/forms.html#dom-label-htmlfor

I assume these were originally given unusual and inconsistent names to avoid reserved words, but it isn't an issue with modern JavaScript.

Could class be added to alias className, and for to alias htmlFor? The old names would be considered legacy.

It's a minor thing, but it's polyfillable, and removes a weird inconsistency on the platform.

[tabatkins]

Yeah, pre-ES5 those keywords were reserved unconditionally. But it's been a decade since they were usable for property access.

[aminya]

Well, Solidjs, as an example, doesn't expose these names in JSX. It simply uses class. The fact that React is doing this seems like an issue that can be fixed on their part. So I do not think the HTML/DOM specification needs to change because of that.

[annevk]

What's a good use case for className that is not better tackled with classList? (Also, this part of the request impacts whatwg/dom, not whatwg/html.)

[gioboa]

Well, Solidjs, as an example, doesn't expose these names in JSX. It simply uses class. The fact that React is doing this seems like an issue that can be fixed on their part. So I do not think the HTML/DOM specification needs to change because of that.

Same for Qwik we can use class and for in JSX templete and it's so cosy

[jakearchibald]

@annevk cases where you want to override previous changes, or setting an initial set of class names.

[Gpx]

Well, Solidjs, as an example, doesn't expose these names in JSX. It simply uses class. The fact that React is doing this seems like an issue that can be fixed on their part. So I do not think the HTML/DOM specification needs to change because of that.

I think this proposal should be considered on its own ignoring what JSX or other libraries are doing. When teaching how to manipulate the DOM this is often something that catches students off guard. IMO it makes sense to add an alias for these properties. It feels more natural to interact with for rather than htmlFor and the same goes for class.

[jakearchibald]

I think this proposal should be considered on its own ignoring what JSX or other libraries are doing.

Agreed. I didn't mention frameworks or JSX in the proposal for this reason.

[patrickhlauke]

I'd be in favour of the new shorter consistent properties, but for backwards compat likely need to keep the old ones as an alias (assuming that was the implicit intention with making them legacy)

[jakearchibald]

The proposal is to add aliases, not rename the properties.

[patrickhlauke]

Doh, sorry, it's right there in the OP and I managed to miss it.

[hinell]

You should clarify your post on whether you are talking about HTML Attributes or Element properties.

[jakearchibald]

@hinell added spec links. Although, I thought it would be obvious since className and htmlFor are properties, not attributes.