[DOM] Add support for the inert attribute

[kripod]

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

When specifying inert={false} on an element, React throws the following message:

Warning: Received `false` for a non-boolean attribute `inert`.

However, inert={undefined} works fine as a replacement for false, while inert="" (empty string) provides an escape hatch as a truthy value.

What is the expected behavior?

The inert attribute should be accepted as a boolean DOM attribute, as proposed by the HTML Standard.

[kripod]

Also, type declarations are required for TypeScript development, so DOMAttributes and JSX.IntrinsicAttributes should also be updated.

[aweary]

@kripod it looks like the spec doesn't explicitly define an inert attribute yet

This section does not define or create any content attribute named "inert". This section merely defines an abstract concept of inertness.

We should probably wait until the spec defines this as a boolean attribute before adding it to the list. In the meantime the workaround you mentioned with inert="" should be sufficient!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

[MidnightDesign]

The inert attribute will be supported by all major engines very soon and this issue should be reopened.

[eps1lon]

Seems like inert in React does not match <div inert="" /> in HTML: https://codesandbox.io/s/react-inert-lb4beo?file=/src/index.js

[jfbrennan]

Trying to use inert today and... no surprise React once again won't let me use completely valid vanilla HTML features🤦‍♂️

When your framework is perpetually struggling to be compatible with the web that's kind of sign, right? Can we get #24730 merged please!

[kripod]

@jfbrennan behind every framework we use, there are human beings with feelings. No one forces you to use React as-is: you could either fix in on your own through a fork or use another library. Please be respectful to the maintainers and evaluate your own contributions before blaming anyone.

I’ve got tired of open source due to the attitude shown above. As a community, I think we should call this behavior out and remind consumers to be grateful towards contributors.

[jfbrennan]

@kripod oh I understand and I'm with you about respecting and collaborating with open-source folks. But let's not get it twisted, React is totally different.

[mrienstra]

Workaround (thank you @kripod!): DefinitelyTyped/DefinitelyTyped#39289 (comment)

[...] the following has to be added into a project-specific declarations.d.ts file:

declare module 'react' {
  interface DOMAttributes<T> {
    inert?: '' | undefined;
  }
}

declare global {
  namespace JSX {
    interface IntrinsicAttributes {
      inert?: '' | undefined;
    }
  }
}

export {};

Edit: if you run into:

'T' is defined but never used. eslint@typescript-eslint/no-unused-vars

... fixes include:

1. interface HTMLAttributes<T> extends AriaAttributes, DOMAttributes<T> (use the var)
2. interface DOMAttributes or interface HTMLAttributes (drop <T>)
3. // eslint-disable-next-line @typescript-eslint/no-unused-vars (ignore rule just on that line)

I'm not 100% sure which option is best, I'm going with "1" for now. Your mileage may vary, I'm using react 18.2.0, eslint 8.47.0, & @typescript-eslint 6.4.0

[jfbrennan]

Yeah, I used to be compelled to workaround IE too. I already stuck this hack into our app and moved on (not the first time).

This is absolutely a step backwards for the frontend community and we all know it. This kind of thing should have died with IE never to be tolerated again. It's been 3.5 years since this issue was opened - ample time to get React prepared for the day when browsers support this attribute (not to the mention error of a design that requires a framework to be maintained alongside the HTML spec).

React is a corporate project with a multi-million dollar budget and highly paid full-time maintainers. Again, really great people just like the old IE team, but it is unacceptable to drag your feet for over 3 years on web standards like this and other instances. Not to mention the persistent failure to support Web Components.

The PR is there - has been for a year - and here we are adding 13 lines of TS to make HTML's inert work. 😫

[pauldraper]

you could either fix in on your own through a fork

Namely the fork https://github.com/eps1lon/react/tree/feat/inert

Hopefully, the react project will find this suitable for merging in #24730

[pauldraper]

Workaround (JS):

<div inert="" />

Workaround (TS):

<div {...{inert:""}} />

[Benimation]

I'm currently using it like this:

<div
  inert={isShown ? undefined : ''} // React doesn't support inert yet
/>

Would be nice if it could be supported by default, though.

[0x00000001A]

4 years issue for the native html attribute, cmon

[effulgentsia]

In 2019, @aweary wrote:

We should probably wait until the spec defines this as a boolean attribute before adding it to the list.

Which I think was quite sensible. I don't know when exactly this changed, but as of now it looks like the HTML spec officially defines it as a boolean.

[johann1301s]

When I, as of 2024 January 18, go to canisue, it seems that all browsers support the inert attribute.

Caniuse also links to the specification for inert.

It seems like its time to add support for inert at this time in react?

[jfbrennan]

@johann1301s, it's gotten better over the years, but React's design effectively makes it a browser and needs its own column on caniuse. I originally opened this request as a troll, but your comment and all the frequent disappointment here makes me think we might need to take this more seriously Fyrd/caniuse#6699

A framework should not be a web standards gatekeeper - that was IE's job!

[eps1lon]

boolean values for inert landed in the Experimental release channel (react-dom@experimental). inert="" will then be treated as false instead of true in experimental builds. We plan to land it in stable in React 19.

[Cuuki]

Hi @eps1lon, we just got an update for the @types/react package for patch version 18.2.67 from Renovate. We are using inert as type '' | undefined so we had some type failures after the update since the attribute now expects boolean | undefined. Unfortunately, React 18 doesn't add the attribute to the DOM node with inert={true}.

As you mentioned this was only meant for experimental and stable in React 19 so the patch version bump is incorrect or at least doesn't work as expected 🤔 . This would rather be a breaking change that should only be included in @types/react@>=19. I am uncertain how the type packages are handled regarding SemVer and the actual react package version, this would just be my expectation as a consumer.

We have pinned the @types/react package to 18.2.66 in the meantime. I just found this issue and the recent activity and thought you might want to know! 🙂

[eps1lon]

@Cuuki Something in your app is pulling in types for the experimental release channel e.g. a import react/experimental or /// <reference types="react/experimental" /> somewhere in your app.

The stable types do not have types for inert. I'd need a full repro to see the issue. But we defintiely didn't add the types for inert in stable types

[benface]

I confirm I have the same issue as @Cuuki and I am definitely not importing react/experimental.

EDIT: Though maybe Next.js, which I use, is doing it?

[eps1lon]

I think I did that in Next.js for convenience a while ago not realizing they vendor Canary not Experimental. I'll check how we can fix it. Might need to break users of experimental features.

I recommend upgrading and annotating breakages with @ts-expect-error.

[Cuuki]

We are authoring a component library with multiple packages in a monorepo, other than emotion and react-aria we don't depend on much here. So at least in this context, Next.js is only used in one of the example apps, outside of the library scope where the error was thrown.

I had already checked for experimental occurence usage earlier but it could of course be that some of the dependencies pull in the experimental types but I can't be sure. If I find some time in the upcoming days I can try to analyze this further, in the meantime I will go with the @ts-expect-error suggestion - thank you! 🙏🏻

[lgenzelis]

Same happening here (I'm also using NextJs, so there's definitely a pattern here). We have very strict rules agains using @ts-expect-error, so for now I disabled the updates for @types/react, no problem. :)

[thathurtabit]

Should this issue be reopened until React 19? 🤷 i.e. this comment

[h3rmanj]

@eps1lon

boolean values for inert landed in the Experimental release channel (react-dom@experimental). inert="" will then be treated as false instead of true in experimental builds. We plan to land it in stable in React 19.

We shipped the inert ? "" : undefined workaround in a library. Is it possible for us to still support both React v18 and v19 at the same time? Does react 19 ship something we can detect and then change behavior based on that?

cc @xec

[eps1lon]

Does react 19 ship something we can detect and then change behavior based on that?

Other maintainers check for existence of React.use since that exists in 19 but 18.

[filipw01]

inert="" will then be treated as false instead of true in experimental builds. We plan to land it in stable in React 19.

Would inert="anyNonEmptyString" be treated as true in React 19? That would allow it to work in both React 18 and React 19

[eps1lon]

Would inert="anyNonEmptyString" be treated as true in React 19? That would allow it to work in both React 18 and React 19

For now but no guarantees that it won't break later. 3rd party tooling may complain about non-standard values.