| 09:39 | <kochi> | I am struggling to understand what rniwa_ proposes in https://github.com/w3c/csswg-drafts/issues/159 |
| 16:02 | <smaug> | do I recall correctly, that some blink folks were wondering if removing <dialog> was still possible? |
| 18:00 | <wanderview> | JakeA: ping |
| 18:01 | <JakeA> | wanderview: hey! |
| 18:01 | <wanderview> | JakeA: has there been any discussion of background sync events only when you are wifi, etc? |
| 18:04 | <wanderview> | JakeA: I have someone requesting that feature... which seems kind of reasonable |
| 18:04 | <wanderview> | right now its only really doable with navigation.connection on the main window (AFAIK) |
| 18:05 | <JakeA> | wanderview: yeah, that feature got dropped from the MVP |
| 18:05 | <JakeA> | wanderview: although devs would have to be careful, some users *never* go on wi-fi |
| 18:05 | <JakeA> | so it'd have to be a choice they expose to the user |
| 18:06 | <JakeA> | although, I question why limiting to wifi is important. If the uploads are large, background sync is probably the wrong choice vs background fetch |
| 18:06 | <wanderview> | JakeA: well, background fetch does not exist yet :-\ |
| 18:07 | <wanderview> | JakeA: I think the use case here is opportunistic pre-caching... but they don't want to waste metered network for it |
| 18:07 | <wanderview> | (yea, wifi does nto necessarilly mean not metered) |
| 18:08 | <JakeA> | wanderview: I think it's a reasonable feature... I'm just worried it's wrong for this particular use-case |
| 18:09 | <wanderview> | JakeA: background fetch would not disciminate between mobile data and wifi, right? |
| 18:12 | <wanderview> | JakeA: anyway, I suggested they write a bg-sync spec issue |
| 18:16 | <JakeA> | wanderview: I don't have anything in background-fetch for that right now. I can't decide if it'd be better as a per-site feature or a browser feature |
| 18:16 | <JakeA> | wanderview: eg the browser could assume wifi only unless the user clicks something in the notification to start it now |
| 18:19 | <wanderview> | JakeA: I think in this case they would not want to pester the user with a notification at all since this sounds like low-priority opportunistic stuff |
| 18:19 | <wanderview> | JakeA: seems like sites should be able to indicate "the users asked for this explicitly... download ASAP" vs "I think maybe they want this, download if possible but whatever" |
| 18:19 | <JakeA> | wanderview: hmm, but if it's large background download, it really need to be visible from a privacy perspective |
| 18:19 | <wanderview> | JakeA: I don't think these are particularly large |
| 18:20 | <JakeA> | wanderview: large enough for wi-fi vs cell to matter |
| 18:20 | <wanderview> | JakeA: do you think a native app like Snapchat should have to put up a notification if its downloading images in the background? |
| 18:21 | <wanderview> | only thinking of that one since I know snapchat ate a ton of my wife's data plan one month with background downloads |
| 18:22 | <JakeA> | wanderview: the podcast app I use does, and I kinda like that it does. Also useful if I have limited bandwidth I can see that the podcast app is clogging up the pipes |
| 18:23 | <wanderview> | JakeA: play store updates do as well... but it just feels different to do it for large things like apps, videos, podcasts... vs "I'm downloading 20 articles I think you might want to read maybe" |
| 18:23 | <wanderview> | JakeA: I mean... why wouldn't small stuff using bg-sync be able to discriminate based on wifi? why restrict it? |
| 19:08 | <JakeA> | wanderview: yeah, I think it's a feature we should have. It was in the original designs |
| 19:15 | <wanderview> | JakeA: I feel like we have a long tail of stuff we should implement... hard to prioritize |
| 19:17 | <KiChjang> | https://domparsing.spec.whatwg.org has an invalid security certificate |
| 19:18 | <KiChjang> | can anyone fix it? |
| 19:18 | <ajeffrey_> | KiChjang: you beat me to it :) |
| 19:26 | <Domenic> | KiChjang: ajeffrey_: that's just a redirect to https://w3c.github.io/DOM-Parsing/ ; where did you find a link to it? |
| 19:30 | <ajeffrey_> | Domenic: we still have links to it from the servo code base, we should probably update at our end. |
| 19:30 | <ajeffrey_> | the update is a bit more urgent now the cert has expired :) |
| 19:30 | <Domenic> | Yeah I pinged Hixie, I believe he still manages all the certs |
| 19:35 | <JakeA> | wanderview: yeah, I want to use the next meeting to work out the priorities |
| 19:36 | <wanderview> | JakeA: I wrote another issue to discuss too! random thought I had this week... https://github.com/w3c/ServiceWorker/issues/1024 |
| 23:07 | <MikeSmith> | PSA: if you think https://bugs.chromium.org/p/chromium/issues/detail?id=443374 should be prioritized higher, please star it |
| 23:07 | <MikeSmith> | = “Web Worker network requests blocked by main thread in Chrome” |
| 23:08 | <MikeSmith> | https://bugs.chromium.org/p/chromium/issues/detail?id=443374#c8 “super important for PWA sites, because fetch() in Service Workers is also blocked by the main thread” |