TypeScript: 2339 Property 'style' does not exist on type 'Element'.

I am not the best one to answer the question about the DOM sepec. We do generate these from IE’s definitions. it is possible that it is an issue. @zhengbli would be able to comment better here.

For your issue, i believe you need to use HTMLElement all the time; so assuming you do not use any SVG elements in this code path, casting should be safe.

class Test {
  constructor(elem:HTMLElement) {
    elem.style.color = 'red';
  };
}

let elem = <HTMLElement>document.querySelector('#test');
let test = new Test(elem);

If someone are still looking for the solution, I can suggest do the following simple solution. Becasue HTMLElement was extended from Element, so if we queried from the DOM, it’s absolutely a HTMLElement, we can cast from Element to HTMLElement by using:

(document.querySelector('ion-nav') as HTMLElement).style.color = 'red';

Hope this help 😃

SVG elements DO have ‘style’ property in browsers (including MS IE11 and Edge), so usually you don’t have to check for its existence.

The exception is arbitrary XML elements, including MathML in Firefox ( Safari not tested ). MathML is dying and most web developers don’t mix arbitrary XML in HTML, so this is not a problem in practice.

According to the CSSOM spec, both HTMLElement and SVGElement have style propterty (Element doesn’t, however). So I suggest adding style to SVGElement, and to Element as an optional property in TS. can we reopen this issue?

Use a type guard. You need to check for null anyway.

let elem = querySelector("#test")
if (elem instanceof HTMLElement) {
    // elem.style
} else {
    throw new Error("element #test not in document")
}

SVG elements really do exist.

If your JS runs over arbitrary DOM trees, it might encounter one, and we’d be wrong to act as if that were not the case.

@NekR while i agree that an HTMLElement is more common target for querySelector/querySelectorAll, this change leaves users of SVGElements with one extra cast:

// with the current definition
querySelector(selectors: string): Element;

// this is how you access it
let htmlElement  = <HTMLElement>document.querySelector('#test');
let svgElement = <SVGElement>document.querySelector('#test');

// if it was changes to HTMLElement
querySelector(selectors: string): HTMLElement;

// this is how you access it
let htmlElement = document.querySelector('#test');
let svgElement = <SVGElement><Element>document.querySelector('#test');

That is a breaking change though, as it will break existing calls that expect to cast to SVGElement.

I am not saying MDN is wrong, I am pretty sure they are right, but they also say what Element have Element.onwheel 😃

that don’t obviously return HTMLElement over Element in most of the time, as it does feel hacky and inconsistent.

Same for getElementById, it does not returns HTMLElement more often than, for example, querySelector because one can easily request inline SVG element by id.

I do not think svg or xml elements are more frequint for querySelector, but I can agree what for XPath that might not be true. So, since querySelector returns Element then any developer should cast it to type they wanted (HTML, SVG, something else?). It would be good to have HTMLElement as a default for such methods, since (as far as I know 😃) HTML is default for the web (ignore xhtml here).