Agenda

W3C Code of Ethics and Professional Conduct
Introductions
Other agenda items?
Scribe?

Allow dynamically changing rootMargin (#428)
Ability to have automatic rootMargin for all nested scroll containers (#431)

Present

(Full name, IRC nickname, affiliation, other relevant info)

Simon Pieters, zcorpan, Bocoup, editor of HTML Standard, Quirks Mode
Brian Kardell, bkardell, Igalia
Emilio Cobos, ecobos, Mozilla
Simon Fraser, smfr, Apple
Ralph Swick, Ralph, W3C
Rob Eisenberg, Rob, Microsoft
Eric Portis, eportis, Cloudinary

Meeting notes

Topic: Allow dynamically changing rootMargin (#428)

Zcorpan: When you create an intersection observer, if you want to change the margin you have to create a new observer. For lazy loading images we found it was useful to change the root margin if certain things happen - the network changes for example. It's not so much for performance reasons as much as ergonomics/parity: If the browser does it, we should expose it and not have magic that is in the browser that isn't available to web developers.
Ecobos: I think we need to discuss whether to schedule an update immediately or if you want to change it somehow silently and leave it to the next render update or something… Otherwise, i dont think there is a lot of complexity to this for Mozilla at least
Smfr: That sounds necessary. I assume there would be a callback immediately. I guess there is also if you change it and there is something scheduled already?
Ecobos: You get a callback regardless, so I think we just make equivalent to just as if you had created a new one, you'd get observe/unobserve
Zcorpan: But it would be scheduled, not synchronous, right?
Ecobos: You would need to reset the state.
Zcorpan: I think the event loop is spinning all the time, as specified, and we only do the work when necessary - I'm just wondering if we need to update the spec here at all
Ecobos: We might need to tweak it to add a flag on the observation, but I dont think it would be hard to specify with the current machinery
Smfr: I dont think so either, it seems relatively straightforward. Is there actually a proposed API? I dont see it in the issue
Ecobos: I think that just making the margin assignable, it's a DOMString.. I guess we need to specify the things like what if it doesn't parse.
Zcorpan: The issue doesn't suggest what the API should be, but yes - either assignable or a method - it doesn't cause any synchronous changes so I don't think it warrants a method. Assigning it seems slightly neater as an API
Smfr: I think that is fine as long as it doesn't create any special behavior differences vs creation.
Ecobos: I think in terms of IDL it is just removing the read only, everything else works. It would throw on bad assignment, like constructor
Smfr: If we're making root margin assignable, should the thresholds array also be assignable?
zcorpan: can you think of a use case?
Smfr: I think for the same reasons you would want to do one, you might generally want to do the other. Keeping symmetry in the API makes sense
Zcorpan: I think the next step is to go ahead and propose an API in the issue and lets see what people not in this meeting think - and we could go and specify that

Topic: Ability to have automatic rootMargin for all nested scroll containers (#431)

Zcorpan: As you can see from the demo… (Demo: https://lazy-img-demo.glitch.me/ ) lazy image loading works differently in the main document than inside a scrollable region. In chrome, in a scrollable region we wind up only loading when the image is actually scrolled into view. In the main document it has some buffer of a thousand pixels. Images in a scroll container are actually quite common - that's how carousels are done, for example, typically.

Emilio: makes sense, should be straightforward to implement. Only reasonable behavior is to resolve once, for the root. If things change (missed something). Obvious approach would be to add a member to the dictionary when initializing. Whether we want to make it mutable, no strong opinion.

smfr: proposal is to apply rootMargin to all scrollers, then logic does rect intersection ?

Emilio: the way we impl in gecko, go up the chain and check intersections. Want to apply the margin in all intermediate steps. there was a question about clip paths

smfr: makes sense… do we want the same rootMargin on all scrollers?

Emilio: I was thinking same rootMargin everywhere… Dunno. Changes the shape of the API otherwise

smfr: does it expand on both axis?

smfr: I don’t think it makes sense to expand on the direction a box is not scrollable…

zcorpan: I think that doesn’t matter much

smfr: thinking of a horizontal scroller, does it make sense to expand in the other direction?

emilio: doesn’t matter I think. Hmm actually, I’ve seen pages that rely on non-zero margins. Image couldn’t intersect because it’s 0x0 and can’t intersect.

smfr: sounds like expanding on both axes is reasonable. Open question : what happens if you have an overflow: hidden ?

emilio: intersect with overflow: clip? I don’t know what it does now.

zcorpan: I don’t think overflow: hidden matters much one way or another

smfr: agree

smfr: current proposal is to apply the rootMargin … would be a step, if container is scrollable, expand cliprect by rootMargin

Emilio: has to be opt-in. Don’t know if pages rely on current intersectionobserver behavior

zcorpan: remember a special-case with cross-origin iframes. Do we need to consider that here?

emilio: I think if we apply the same rootMargin we would also need to not apply it to cross-origin iframes.

zcorpan: may provide an API to specify different rootMargin for different scrollers

emilio: maybe a css property? might be hard to implement. Don’t know how to do it in the API. should be part of the scroller itself.

zcorpan: might add a lot of complexity, maybe not that useful?

smfr: for an image carousel… suddenly you’re loading all images in the carousel. if the carousel has scrollSnap, such that you can’t go further than a small step at a time, having a big margin is bad.

emilio: maybe can use percentages. Would be different for different scrollers.

zcorpan: so then the browser would need to use percentages for lazy-loading

smfr: JS libraries allow customization?

zcorpan: yes. through data- attributes, per-image basis or ancestors (maybe?)

smfr: might need more experimentation, with image carousels and scroll snap and such

smfr: Next steps: experiment to figure out - some testing with vertically scrolling pages and horizontal carousels. are lazy images too aggressively loaded? Pages like music.apple.com , don’t interact with all images. If we turn this on, too many images load?

bkardell: question. Does this mean they’re loaded with script?

smfr: yes.

bkardell: so this wouldn’t be a good default, would be too aggressive?

smfr: I can ask the devs for music.apple.com what would be acceptable

zcorpan: thanks!

bkardell: if we were to add lazy images as they are today, to that page, it wouldn’t be aggressive enough?

smfr: yeah. Has some margin

zcorpan: wonder if default vertical and horizontal margins should be different?

smfr: dunno, there are pages with horizontal scrolling