This seems like shoving implementation details into the specification. HTML should only declaratively describe objects, and leave the implementation of those objects up to the browser. If there’s no difference from an interface perspective as to whether something is a <virtual-scroller> or a “normal” scroller, then this “feature” should simply never exist.
That’s a fair point but there is a difference though.
With this, you can choose whether it makes more sense for your app to have a rendering cost up-front or spread when scrolling through the list.
Also, because it is virtual, you would need to specify the space the rows are taking so that the “physical” space is properly calculated. If you don’t, the scrollbar will not properly adjust.
All of those concerns have no business being in HTML.
We need to separate browser-as-app-host from browser-as-document-browser, the way we’re carrying on makes both of these use-cases worse than they otherwise would be.
This seems like shoving implementation details into the specification. HTML should only declaratively describe objects, and leave the implementation of those objects up to the browser. If there’s no difference from an interface perspective as to whether something is a
<virtual-scroller>or a “normal” scroller, then this “feature” should simply never exist.That’s a fair point but there is a difference though. With this, you can choose whether it makes more sense for your app to have a rendering cost up-front or spread when scrolling through the list. Also, because it is virtual, you would need to specify the space the rows are taking so that the “physical” space is properly calculated. If you don’t, the scrollbar will not properly adjust.
All of those concerns have no business being in HTML.
We need to separate browser-as-app-host from browser-as-document-browser, the way we’re carrying on makes both of these use-cases worse than they otherwise would be.