| 15:16 | <domfarolino> | annevk: RE https://github.com/whatwg/html/issues/5250#issuecomment-581941697: Delaying the load event is controlled by the `delay the load event` variable, which I think is independent of the return value from the `will lazy load image` steps, right? |
| 15:19 | <annevk> | domfarolino: yeah |
| 15:19 | <annevk> | domfarolino: hence the question 🙂 |
| 15:19 | <domfarolino> | So I think even if scripting being disabled does impact the `will lazy load image` steps, the `delay the load event` variable would still have the image delay the load event |
| 15:20 | <annevk> | Oh hmm |
| 15:20 | <domfarolino> | annevk: Sorry, would _not_ delay the load event |
| 15:21 | <domfarolino> | Ughh, I'm misinterpreting everything tonight :/ |
| 15:23 | <annevk> | domfarolino: afaict <var>delay load event</var> depends solely on the loading attribute |
| 15:24 | <annevk> | domfarolino: I guess that's what you're also saying, in which case the question is, is that what we want or should scripting disabled be equivalent to eager? |
| 15:25 | <annevk> | domfarolino: if it's not equal to eager, what causes it to be fetched? |
| 15:26 | <annevk> | domfarolino: separate thing, the PR needs to be rebased and INSERT FINGERPRINT needs to be replaced with INSERT TRACKING, I can do that later, but also don't really want to stamp on any work you might be doing |
| 15:33 | <domfarolino> | annevk: Eager-fetching and eager-load-event semantics are separate as you've mentioned (former is controlled by the |
| 15:34 | <domfarolino> | will lazy load image steps, and the latter is controlled solely by the attribute |
| 15:35 | <domfarolino> | We'd want environments where scripting is disabled, to always eagerly-fetch the image, for privacy/tracking reasons. But the image would still have lazy-load-event semantics (which I don't think has any tracking concerns?), unless we handle it separately. Does that make sense? |
| 15:36 | <annevk> | domfarolino: actually, I guess that's a fine outcome too |
| 15:37 | <annevk> | domfarolino: it might make refactoring this will lazy load thing trickier, is what I'm saying |
| 15:37 | <annevk> | domfarolino: since if we move that to "update the rendering" as desired, we'd need something else for script being disabled |
| 15:39 | <domfarolino> | annevk: Right, good point. So I'm OK with leaving the load event behavior as-is even when scripting is disabled, since it makes the refactoring simpler and also doesn't (seem to) expose a tracking vector. |
| 15:45 | <domfarolino> | annevk: let me know if that's what you had in mind/we're on the same page |
| 15:46 | <annevk> | domfarolino: ideally you have an opinion on it 🙂 |
| 15:47 | <annevk> | domfarolino: but either that or not delaying the load event but fetching directly anyway work for me |
| 15:55 | <domfarolino> | annevk: As long as scripting-disabled == fetch eagerly, I don't have a strong pref on the load event. For consistency, I prefer scripting-disabled == everything eager (delay load event). Not sure if either way complicates the refactoring. Will think on it more |