Repository navigation
Add class & for aliases for className and htmlFor #9379
Description
Activity
Yeah, pre-ES5 those keywords were reserved unconditionally. But it's been a decade since they were usable for property access.
Reacted by Jake Archibald, Andrea Giammarchi, Damian Senn, Cory Hughart, Maciej Holyszko, Hlib Zhurba, Tait Brown, Karl O, Manuel Meister, Haroen Viaene and 1 moreWell, 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.Reacted by Vladislav Lipatov, ezzabuzaid, Pascal Schilp, Lea Rosema, Fuzzy Bear, Frank Mayer, Akash and yassine belkaidWhat's a good use case for
classNamethat is not better tackled withclassList? (Also, this part of the request impacts whatwg/dom, not whatwg/html.)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
classandforin JSX templete and it's so cosyReacted by Bo Lingen@annevk cases where you want to override previous changes, or setting an initial set of class names.
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
forrather thanhtmlForand the same goes forclass.Reacted by Ziad El Khoury Hanna, Manuel Meister, T.J. Crowder, Fabian, Georgii Dolzhykov, Willem Garnier, Ivy Reese, Alex Draper, István Szmozsánszky, Massimo Artizzu and 3 moreI 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.
Reacted by Joe PeaI'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)
- changed the title
[-]Add class & for aliases for className and htmlFor[/-][+]Add `class` & `for` aliases for `className` and `htmlFor`[/+]on Jun 5, 2023 The proposal is to add aliases, not rename the properties.
Reacted by Patrick H. Lauke, T.J. Crowder, Lea Rosema and Max DuvalDoh, sorry, it's right there in the OP and I managed to miss it.
You should clarify your post on whether you are talking about HTML Attributes or
Elementproperties.@hinell added spec links. Although, I thought it would be obvious since
classNameandhtmlForare properties, not attributes.20 remaining items
This will break code that assumed
classdoesnt exists. Suchconst prop = 'class' const value = { red:true } if( prop in node ) { node[prop] = value } else if ( prop === 'class' ) { if( value.red ) { node.className = 'red' } //.... }
@titoBouzout do you know of a JS library or so that does that?
No, I am brainstorming how this could break something. However, this svelte code comes very close:
Besides whatever they are doing, I see.
if(prop in setters) { node[prop] = value }else { if (attribute === 'loading') { ... } }(theset_attributecall)
Similar example to what I gave before, they check for
prop inbefore special casing some props, up to an extent tho.
Looking around I am figuring that even if
classis added, It would probably be a good idea to avoid using it because of the likelihood it has to be broken by some random stuff, likeprototype.class = function..somewhere.It becomes a thing of "if this project is new then use class, if its jQuery/htmx or whatever, then use className.".
It also has the problem that however was supporting
className, now has to also supportclass. As in, hookingclassNameto do whatever magic they were doing, now they have to do the same magic forclass.I honestly do not see the benefice of adding it, it will just cause random difficulties for little gain.
Also,
classis supported in most modern frameworks, they just map it once, is not that you seeclassNameeverywhere.classNameis currently defined onElement, butSVGElementoverrides it.Nice, this means
.classcan on onElementand simply work for all elements. Let's keep this philosphy of consistency across all types of elements.const prop = 'class' const value = { red:true } if( prop in node ) { node[prop] = value } else if ( prop === 'class' ) { if( value.red ) { node.className = 'red' } //.... }
This code will still work because
.classNamewill remain the same, andprop === 'class'(I'm assuming) is checking a value from templating (f.e. JSX) and not from the DOM.the likelihood it has to be broken by some random stuff, like
prototype.class = function..somewhere.I understand the concern, and I trust that from the comments above the implementers will follow through with the testing for how many apps break, to determine how doable this is. A handful of breaks won't be meaningful, but if for example some library would break and many dependent sites would go down, it could be significant enough to avoid.
I wonder if folks on this thread have an opinion about what we should do with new occurrences of the
forattribute and how they should be reflected, e.g.<template for>(#11818).My current thinking is that having
element.forin some cases andelement.htmlForin other cases would do more harm than good, and we should usehtmlForin new cases and alias all of them once we resolve on this.But happy to hear other opinions.
Reacted by Masataka YakuraMy current thinking is that having
element.forin some cases andelement.htmlForin other cases would do more harm than good, and we should usehtmlForin new cases and alias all of them once we resolve on this.But happy to hear other opinions.
I remember there being a point made that legacy attributes that are only kept for compatibility shouldn't get this treatment at all. (like the
foronscriptelements)I personally somewhat disagree because it sounds like an unfortunate reason to introduce random inconsistencies, but I thought I'd bring it up as an edge-case to be aware of.
Otherwise this plan sounds sensible.
Reacted by Noam RosenthalMy current thinking is that having
element.forin some cases andelement.htmlForin other cases would do more harm than good, and we should usehtmlForin new cases and alias all of them once we resolve on this.Agreed.
If it's compatible enough I think it would be nicer with
forandclass. Fixing https://issues.chromium.org/u/1/issues/367992694 would help, it has a CL but no activity since August 2025.I had a little search on GitHub and found a few codebases that create label elements and set
.foron them:var label = document.createElement('label'); label.classList.add("form-check-label"); label.className = "form-check-label"; label.for = 'sortSelection-default';
let label = document.createElement('LABEL'); label.id = name + '_label'; label.innerText = name; label.for = name;
var label = document.createElement('label'); label.for = 'radiogroup-typeselect-' + type;
I don't think these are webcompat issues - actually quite the opposite, I think we'll be fixing these websites - however they will change in behaviour.
Reacted by Psychpsyo (Cameron)Note that in some cases like destructuring
htmlForis still useful, e.g. this is a syntax error:const {for, class, id} = my_label; console.log(for);
So I think that even if we add
foras an alias we'd want to keephtmlForalso for future occorunces of theforattribute.Reacted by Jake ArchibaldI had a little search on GitHub and found a few codebases that create label elements and set
.foron them:I don't think these are webcompat issues - actually quite the opposite, I think we'll be fixing these websites - however they will change in behaviour.
I did this same search back in 2024 and came to a similar conclusion after looking through a few pages of results.
Reacted by Keith Cirkel and Jake Archibald
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
classbe added to aliasclassName, andforto aliashtmlFor? The old names would be considered legacy.It's a minor thing, but it's polyfillable, and removes a weird inconsistency on the platform.