Display locking alternatives?
dfabulich opened this issue · comments
I don't know if this is the right place to discuss this, but Display Locking doesn't seem to be getting good uptake from Mozilla and Apple.
In mozilla/standards-positions#135, dbaron on the Mozilla team tentatively describes the feature as "harmful," and rniwa has said that WebKit team is opposed as well, and reinforced that at yesterday's F2F https://www.w3.org/2019/04/26-components-minutes.html
What now? Back to https://github.com/rakina/searchable-invisible-dom?
Hey, this is the repo for virtual scroller, not display locking. Did you mean to open this issue over there?
No, but I may be confused in a different way. <virtual-scroller> is meant to build on top of Display Locking as a layered API, right? But without Display Locking, it needs to be built on top of something else. I wanted to discuss how <virtual-scroller> could be implemented without Display Locking.
Should I move this to the Display Locking repo?
This is a repository for a virtual-scroller API and (eventually) specification. How different browsers choose to implement that specification is up to them. Those discussions will probably end up happening in each browser's bug trackers and code review tools as they work on implementing the spec.
I'd thought/hoped that browsers could/would share the JS implementation of layered APIs, managing the code on a github like this one.
Is that a bad/unworkable idea? Where would I go to discuss the question of how browsers would/wouldn't share JS for layered APIs? Would I post an issue on https://github.com/drufball/layered-apis/issues?
The layered APIs concept hasn't seen a lot of movement in some time; we're instead working on just speccing things, and letting folks implement them in whatever fashion they wish. All browsers' code is now open source, and it's possible the code will be reused for some APIs, as is done today for things like Web Audio, Web RTC, internationalization, etc. But that's an individual policy decision, probably best discussed with individual browser teams. For example, a browser that doesn't implement display locking probably wouldn't want to use that in implementing virtual scroller, as you point out. But that doesn't impact the virtual scroller spec, and is instead something that the browser team will discuss if/when they implement virtual scroller.