If scrollheight is not a performant property, than it shouldn't be a property. It should have been a method called calculateScrollHeight() or something to indicate that it is not cheap.
Element.scrollHeight first appeared in the DOM API with IE6 in 2001 as far as I can tell. That browser was the first really modern one, with javascript and CSS that could drive a dynamic layout and they innovated with things like AJAX and vector graphics. The web browser had matured from a document model with live elements to a programmable operating environment.
The API implementation was klunky though, where DOM Elements attached to the DOM became 'live' objects. Reading some of the properties would necessarily require reflowing the page in order to calculate the value. It's interesting to think about all the ways the DOM thread can stall for synchronous API's. The Paul Irish gist is always the top hit when I search:
I'm always impressed by how old sins like element.scrollHeight can get papered over with newer API's. You can use ResizeObserver or requestAnimationFrame() to time your reads of the property and hopefully get the reflows for cheap or free.
Why? Plenty of web APIs have been redesigned since then. Nobody is going to stop the browser makers from introducing an alternative and deprecating the old one for removal 25 years from now.
If they can remove <blink> and <marquee>, they can provide an alternative to this.
<marquee> hasn't been removed; although it is deprecated, the HTML standard requires browsers to support it, and they all do, and I don't think anyone is planning to change this.
<blink> hadn't worked for most users since 1998; Internet Explorer never supported it, and neither did Chrome or Safari. The only browser that dropped support for it was Firefox, which merely brought it in line with how other browsers had always behaved. Furthermore, when it was removed, content in existing pages' <blink> tags still appeared on the page; it just no longer blinked. So there was probably very little breakage, at least if we define "breakage" as "behavior change that causes problems for end users" rather than "any behavior change at all".
By contrast, if they remove scrollHeight, every existing page that uses it will crash.
There's actually a footnote to the <blink> saga that illustrates this perfectly. JavaScript strings have a .blink() method that surrounds them with <blink> tags (e.g., "a".blink() returns "<blink>a</blink>"). With hindsight we can say that making this a fundamental string operation was profoundly silly to begin with, and now that <blink> doesn't even work anymore it's basically 100% useless. Yet it remains in the standard, and every browser still supports it, and they almost certainly always will. Because while removing <blink> didn't cause breakage, removing .blink() absolutely would.
Agree, but also easy to say after it been in use for 20 years or what it is. Doing this change today would be a monumental migration, unless you provide fallbacks, and then what's the point?
The API implementation was klunky though, where DOM Elements attached to the DOM became 'live' objects. Reading some of the properties would necessarily require reflowing the page in order to calculate the value. It's interesting to think about all the ways the DOM thread can stall for synchronous API's. The Paul Irish gist is always the top hit when I search:
https://gist.github.com/paulirish/5d52fb081b3570c81e3a
The mouse event ones always get me.
I'm always impressed by how old sins like element.scrollHeight can get papered over with newer API's. You can use ResizeObserver or requestAnimationFrame() to time your reads of the property and hopefully get the reflows for cheap or free.