Repository navigation
Define referenceable algorithms for IntersectionObserver methods #427
Description
In whatwg/html#5510 I'm trying to specify <img loading=lazy> in terms of IntersectionObserver as per discussion in whatwg/html#5236
As @domfarolino pointed out, in web specs we try not to call public APIs, but instead want to call the underlying algorithm directly. (Also see #401 )
For lazy-loaded images currently, we need to
- initialize a new
IntersectionObserverwith a callback that is a set of steps defined in spec prose - call
observe() - call
unobserve()
Activity
zcorpan commentedon May 18, 2020
When fixing this, also fix (or file an issue to fix) the "XXX" issues introduced in whatwg/html#5510
szager-chromium commentedon Sep 11, 2020
Is there an idiomatic way to do this? Is it just a matter of moving the language from the public API methods into new sections under Processing-Model/Algorithms, and referring to them from the public API description?
I must say, it seems needlessly complicated to add this level of indirection to the spec. Could you instead follow the example given in issue #55 for getBoundingClientRect, and say something like:
"Perform the steps described in the IntersectionObserver spec for the IntersectionObserver constructor."
"Perform the steps described in the IntersectionObserver spec for the observe() method."
?
zcorpan commentedon Sep 14, 2020
The usual way is a level of
<dfn>abstraction. But it doesn't need to be in a different section, that's up to how you want to structure the spec. See for example https://fullscreen.spec.whatwg.org/#dom-document-exitfullscreenI don't think the example for
getBoundingClientRectis a great one to follow; it's less explicit, and I don't see a good reason not to change the cssom-view spec.I think there's an argument to be made that this is a bit annoying for writing specs and we could do something to make it easy to do the right thing, but for now, we need an extra
dfnwhen other specs want to reference algorithms.WIP: update xrefs to use new IntersectionObserver terms
zcorpan commentedon Oct 22, 2020
Thanks for fixing! I tried today to update the HTML standard and ran into further issues, see #464