cannot set element.style.cssProperty to null

[sudo-barun]

🔎 Search Terms

style css property null CSSStyleDeclaration

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "style css property null CSSStyleDeclaration".

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/CYewxgrgtgpgdgFwHQCMTAJ5IM4IwGxlQEMwBrAcwCcQI5gBhEfEKgAgF42ByKmYbgG4AUKEixEqdFlwEiKUpRp1GzVpzZwI+fIKA

💻 Code

document.body.style.backgroundColor = null;

🙁 Actual behavior

Errors in code

Type 'null' is not assignable to type 'string'.

🙂 Expected behavior

No error is expected.

Additional information about the issue

This can be fixed by updating the lib.dom.d.ts as follows:

interface CSSStyleDeclaration {
// ...
-    backgroundColor: string;
+    get backgroundColor(): string;
+    set backgroundColor(value: string|null);
// ...
}

Same change has to applied to other CSS properties.

[MartinJohns]

This is intentional. Just use an empty string. See also: #33749 (comment)

[sudo-barun]

Not sure what the problem with getter and setter was back in 2019 but updating lib.dom.d.ts with getter and setter does work in the TypeScript 5.6.2 .

So, why not update lib.dom.d.ts and let developer use the API allowed by the standard?

[MartinJohns]

Why add it when it serves no purpose? It's just being coerced to string, so you can be explicit and just use string. "The standard" is a poor argument, the standard lets you do all kind of nonsensical kinky stuff like adding an object to an array, things TypeScript aims to prevent. And allowing null could potentially introduce bugs in user code, where they want to differentiate between "have no value, do nothing" and "have a value, assign it".

It's essentially the same deal as allowing to pass null to JSON.parse(), which has been rejected numerous times (e.g. issue 29811).

I'm no member of the team so I have no say, but I absolutely can't see this change happening.

[sudo-barun]

IMO, TypeScript should not impose restriction on usage of standard APIs (whenever possible).
Yeah, there are some quirks in standard APIs but TypeScript should expose them instead of hiding them and let developer decide which approach to take regarding API consumption.

The types in lib.dom.d.ts may have been like this due to limitation of TypeScript at some point in time but that is no longer the case and so, it is better to fix the definition file.

[jcalz]

See What does "all legal JavaScript is legal TypeScript" mean? and The ECMAScript Spec is Descriptive, not Normative and #11842, #29811, #49766, etc

[ritschwumm]

@sudo-barun imho "expose them instead of hiding them" is exactly what typescript is doing here by not allowing null without explicitly telling the compiler i know what i am doing.

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.