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

[NekR]

Some example of code:

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

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

This produces:
2339 Property 'style' does not exist on type 'Element'.
If I change elem:Element to elem:HTMLElement then is says:
2345 Argument of type 'Element' is not assignable to parameter of type 'HTMLElement'. Property 'accessKey' is missing in type 'Element'.

I understand what querySelector might not always return HTML or SVG elements, but why Element does not have style property?

[mhegazy]

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);

[NekR]

@mhegazy yes, I now how to work around it right now, I was just confused what Element does not have style property. I am also not sure if it should have it, but it will be strange in a future to always cast any DOM requests (querySelector, getElementById, etc) to HTMLElement.

[zhengbli]

According to the MDN spec, Element interface doesn't have a style property, and querySelector does return Element.
However, in the case of getElementById, we made it convenient by returning HTMLElement by default, although it is different from the spec. I don't know if we should do the same thing for other methods that don't obviously return HTMLElement over Element in most of the time, as it does feel hacky and inconsistent.

[NekR]

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).

[kitsonk]

DOM Level 3 IDL for Element does not contain it.

[NekR]

@kitsonk yes, I got it. Please treat now this issue as "Return HTMLElement by default instead of Element from dom request methods (getElement(s)By*, querySelector(All), etc)"

[mhegazy]

@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.

[duanyao]

As I suggested in issue 424, querySelector/querySelectorAll etc. can return UniversalElement by default, which is an imaginary Element that extends all known sub-interfaces of Element. Thus no casts are ever needed, no matter for HTML or SVG.

Of cause this is not quite conformant to WebIDL of DOM specs, but I don't think there are many TS users that care about this problem.

[NekR]

Indeed, double casting seems weird. But it's also strange that TypeScript follows spec more than real use cases. What is a real benefit of returning Element for such methods except of being type-compatible with spec?

UniversalElement solution seems good. I do not know if it's possible, but something like that will help.

[RyanCavanaugh]

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.