Scroll to HTML element ID in VStack of WKWebView views - swift

Question

I have a ScrollView with a LazyVStack outputting items in ForEach.
I'm rendering HTML in the LazyVStack with the RichText library: https://github.com/NuPlay/RichText which is essentially a dynamically sized WKWebView for each item in the VStack.
#State var scrollTarget: Int?
//struct view
ScrollView {
ScrollViewReader { proxy in
LazyVStack {
ForEach(ficDetail.chapters.indices, id: \.self ) { i in
Text(self.ficDetail.chapters[i].post_title)
.id(self.ficDetail.chapters[i].id)
RichText(html: self.ficDetail.chapters[i].html)
.lineHeight(170)
.colorScheme(ColorScheme.auto)
.imageRadius(6)
}
}
.onChange(of: scrollTarget) { newValue in
if let target = newValue {
scrollTarget = nil // allows for future triggers
proxy.scrollTo(target)
}
}
}
}
As the above code shows, I'm using ScrollViewReader to auto scroll the ScrollView to the Text view with property: .id(self.ficDetail.chapters[i].id).
The issue is that the HTML I'm displaying inside each RichText view is very large, and I need to let users auto scroll to specific areas inside each RichText HTML view, particularly if they close the app and I want to restore the Scene.
The rendered HTML has <span id="{Int}"> ... </span> wrapping each sentence inside the HTML.
Is there anyway to bind proxy.scrollTo to the embedded <span> IDs to scroll the LazyVStack to that <span id="{Int}">?
If not, is there another method already in practice for this use case?
When I webView.evaluateJavaScript("document.getElementById('30').scrollIntoView();" this only scrolls the inner WKWebview and not the outer ScrollView, so the HTML content inside the view is getting cutoff as it's scrolling out of view.
I'm considering recording the scroll offset of the ScrollView and finding a way to restore the Scene and scroll back to that offset. Though seems messy as the HTML content + CSS can change the offset sizes.
Another option I considered is adding HiddenView slices with .id()s proportional to the size of each RichText view to act as a proxy to the WKWebViews, but that also seems hacky.