04:58:32 <RRSAgent> RRSAgent has joined #dap
04:58:32 <RRSAgent> logging to https://www.w3.org/2020/10/22-dap-irc
04:59:18 <mfoltzgoogle> mfoltzgoogle has joined #dap
05:00:27 <mfoltzgoogle> present+ Mark_Foltz
05:00:49 <mfoltzgoogle> zakim, who's here?
05:00:49 <Zakim> Present: Mark_Foltz
05:00:51 <Zakim> On IRC I see mfoltzgoogle, RRSAgent, Zakim, anssik, takio, kenchris, xfq, mounir, reillyg, odejesush99, tomayac, github-bot, rakuco, scheib, slightlyoff, dougt, sangwhan,
05:00:51 <Zakim> ... Josh_Soref, Mek
05:00:59 <amandy_> amandy_ has joined #dap
05:01:09 <xfq> present+
05:01:13 <reillyg> present+
05:01:15 <rakuco> present+
05:01:38 <marcosc> marcosc has joined #dap
05:01:41 <takio> present+ Takio_Yamaoka
05:02:53 <hazel> hazel has joined #dap
05:02:53 <marcosc> present+
05:02:58 <anssik> RRSAgent, draft minutes v2
05:02:58 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:03:12 <anssik> Present+ Anssi_Kostiainen
05:03:15 <plh> plh has joined #dap
05:03:43 <plh> present+
05:03:54 <JamesH> JamesH has joined #dap
05:04:28 <scheib> present+
05:04:34 <tomayac> present+
05:04:35 <JamesH> present+
05:05:20 <larsgk> larsgk has joined #dap
05:05:21 <amandy_> present+
05:05:33 <kenchris> present+ Kenneth_Christiansen
05:05:51 <anssik> Anssi Kostiainen, Intel
05:06:14 <marcosc> AK: WG Chair
05:06:16 <xfq> Fuqiao Xue, W3C
05:06:22 <hazel> Hazel Kuok, W3C Southeast Asia Chapter Evangelist
05:06:44 <kenchris> Kenneth Christiansen, Intel + TAG
05:07:01 <marcosc> Marcos Caceres, Invited Expert
05:07:38 <plh> PLH, W3C
05:07:46 <rakuco> Raphael Kubo da Costa, Intel
05:07:47 <larsgk> Lars Knudsen, Invited Expert
05:08:17 <satakagi> satakagi has joined #dap
05:08:28 <kenchris> larsgk: not on the call?
05:08:53 <Eric> Eric has joined #dap
05:09:05 <larsgk> kenchris: I am on zoom - maybe wrong link (it says DAS though)
05:09:17 <kenchris> I dont see you :)
05:09:43 <amandy_> present+ Arno Mandy, Intel Corporation
05:09:55 <anssik> RRSAgent, draft minutes v2
05:09:55 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:10:06 <larsgk> kenchris: I changed password on W3C and can't access the mailing list link now ;)
05:10:33 <kenchris> larsgk: https://mit.zoom.com.cn/j/98970825623?pwd=dzJJNzVrUjlrZE9ybmZTSG1pWmg4QT09
05:10:38 <marcosc> Eric Mwobobia, Safari Telecom
05:11:40 <marcosc> Alexis Menard, Intel
05:11:47 <anssik> RRSAgent, draft minutes v2
05:11:47 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:12:09 <marcosc> Scribe: marcosc
05:12:23 <marcosc> Leon Han, Intel
05:13:03 <anssik> RRSAgent, draft minutes v2
05:13:03 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:13:12 <plh> rrsagent, make logs public-visible
05:13:14 <anssik> RRSAgent, make logs public
05:13:21 <xfq> RRSAgent, draft minutes v2
05:13:21 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html xfq
05:14:00 <heejinchung> heejinchung has joined #dap
05:14:07 <plh> me https://www.w3.org/2020/10/22-dap-minutes.html is now visible
05:14:59 <Peter_Burrows> Peter_Burrows has joined #dap
05:15:20 <marcosc> Present+ Peter Burrows
05:15:23 <kenchris> Peter Burrows, Pfizer
05:15:24 <mattreynolds> mattreynolds has joined #dap
05:17:02 <leonhsl> leonhsl has joined #dap
05:17:05 <JamesH> James Hollyer, Google Chrome
05:17:39 <marcosc> Lars Knudsen, Invited Expert
05:17:50 <Peter_Burrows> Peter Burrows, Fiserv
05:18:19 <tomayac> s/Pfizer/Fiserv
05:18:31 <marcosc> Mark Foltz, Google
05:19:03 <marcosc> Matt Reynolds, Google
05:19:36 <marcosc> Satotu Takagi, KDDI
05:20:35 <marcosc> Thomas Steiner, Google
05:20:38 <tomayac> Thomas Steiner, Google, Web/Chrome Developer Advocate working on Web capabilities (Project Fugu 🐡)
05:21:26 <marcosc> Takio Yamaoka, Yahoo Japan
05:21:37 <scheib> Vincent Scheib, Google Chrome, Software Engineer on Web Capabilities
05:22:28 <marcosc> AK: good participation
05:23:05 <marcosc> TOPIC: Process 2020
05:23:54 <reillyg> scribenick reillyg
05:24:02 <marcosc> scribenick: reillyg
05:24:02 <anssik> scribeNick: reillyg
05:24:06 <anssik> Scribe: Reilly
05:25:10 <xfq> Current charter: https://www.w3.org/2019/03/devices-sensors-wg-charter.html
05:25:11 <reillyg> Presenting: Philippe Le Hegaret
05:25:31 <xfq> Proposed charter: https://www.w3.org/2020/05/proposed-das-wg-charter.html
05:25:35 <reillyg> Mozilla raised a Formal Objection to rechartering of the Working Group based on proposed deliverables.
05:25:58 <xfq> Mozilla's FO: https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html
05:26:13 <reillyg> Two reasons: 1) Security and privacy concerns. 2) Would prefer refactoring existing APIs over new Generic Sensors framework.
05:26:43 <reillyg> W3C staff found the FO interesting and wants to explore a Director-free process.
05:27:15 <reillyg> PH: We need to find a way to replace Tim Burners-Lee.
05:27:45 <marcosc> s/Burners-Lee/Berners-Lee
05:27:48 <reillyg> ... Creating a council consisting of the Advisory Council and TAG to make decisions.
05:28:22 <reillyg> ... Advisory Board has decided to take on the FO as an example to test the process for making a decision.
05:28:41 <reillyg> ... Director will still make the decision but the AB will discuss as if they were making the decision.
05:28:52 <reillyg> ... Director will make a decision no later than Nov 20th.
05:29:01 <reillyg> ... Charter will be extended through Nov 20th.
05:29:24 <reillyg> ... PH will be acting as team contact for this experiment. Co-chairs will be invited to present on the first call.
05:29:42 <tomayac> (Addendum) Mozilla's formal objection: https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html
05:30:31 <reillyg> AK: What are the practical implications for the participants of the group?
05:31:11 <reillyg> PH: There is currently no effect. Work can continue to happen. Adopting proposals from the WICG is currently blocked because the charter requires it.
05:31:43 <reillyg> AK: Proposed new deliverable "Screen Fold API" cannot be published as a TR.
05:31:55 <reillyg> PH: Correct, but we can discuss the proposal in the group.
05:32:50 <reillyg> TS: What does "blocked" mean?
05:33:12 <reillyg> PH: The charter is required to publish a TR. Discussing the proposal is allowed.
05:33:36 <reillyg> AK: Can you talk about Process 2020?
05:33:55 <reillyg> PH: As of today this group (and other groups) are working under Process 2020.
05:34:19 <reillyg> ... This group is not (and won't be with the current proposed charter) under Patent Policy 2020.
05:34:57 <anssik> RRSAgent, draft minutes v2
05:34:57 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:35:36 <anssik> Meeting: Devices and Sensors F2F - Day 1/2
05:35:39 <reillyg> ... Patent Policy 2020 allow patent policy to cover working drafts and proposed recommendations.
05:35:45 <anssik> Chair: Anssi, Reilly
05:35:57 <anssik> Agenda: https://github.com/w3c/devicesensors-wg/issues/31
05:36:03 <anssik> RRSAgent, draft minutes v2
05:36:03 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:36:05 <reillyg> ... DASWG currently under Patent Policy 2017.
05:36:28 <reillyg> ... Transition plan is to ask chairs about switching in November.
05:37:04 <reillyg> ... In this group's case we will issue the new charter with the revised patent policy so that members only have to rejoin once.
05:38:21 <anssik> https://github.com/w3c/devicesensors-wg/issues/31
05:38:33 <reillyg> TOPIC: Agenda Bashing
05:39:01 <reillyg> scribenick: scheib
05:39:11 <scheib> Scribe: scheib
05:40:10 <scheib> AK: First day discussing technical topics. Second day addressing privacy concerns.
05:41:05 <scheib> ... kenchris invited to discuss screen fold topic anticipated in new charter.
05:42:06 <scheib> ... marcosc invited to discuss network information and describe use cases etc.  Proposal variations exist, with larger, smaller scope
05:42:46 <scheib> ... reillyg to discuss Wake Lock split to screen and system locks earlier this year.
05:43:27 <scheib> ... anssik noticed interesting application of sensors with orientation sensors being used in earbuds
05:43:40 <scheib> ... Comments, suggestions regarding this agenda?
05:44:07 <tomayac> s/earbuds/AirPods Pro/
05:45:18 <scheib> RG: Checking in with marcosc - prepared to discuss?  marcosc: yes.
05:45:23 <anssik> https://www.w3.org/das/roadmap
05:46:05 <scheib> AK: Inviting participants to review https://www.w3.org/das/roadmap, suggest any other topics today.
05:47:15 <scheib> RG: Battery use cases would be good to discuss, but we may not have an appropriate speaker for this.
05:47:19 <anssik> https://github.com/w3c/battery/issues/25
05:48:05 <scheib> AK: Re Battery, use cases are in old email archives, https://github.com/w3c/battery/issues/25 filed to recall adding them.
05:49:05 <scheib> RG: We're aware we need to work on this - but not ready to discuss in this meeting.
05:49:32 <scheib> AK: Noting that motion sensors work is mostly done. At CR.
05:49:55 <scheib> ... Test automation a blocking factor.
05:50:34 <marcosc> MC: the hard part is getting cross browser API for testing
05:50:42 <scheib> ... Might need to discuss how to handle test automation.  Perhaps web driver isn't the solution?  WebXR and USB use a different API?
05:50:54 <scheib> RG: Web Driver is an ideal way.
05:51:20 <scheib> PH: What are these other APIs?
05:51:36 <scheib> RG: We can place testing on agenda.
05:52:35 <scheib> RG: Had discussed in testing meeting, we're short on time today, can add for tomorrow.
05:52:51 <scheib> AK: Any other items, please send to anssik for inclusion tomorrow.
05:52:59 <scheib> AK: Moving on to Screen fold API
05:53:18 <marcosc> TOPIC: Screen Fold API
05:53:55 <reillyg> RRSAgent, draft minutes v2
05:53:55 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html reillyg
05:54:21 <plh> [this will get into the minutes]
05:54:50 <Mizushima> Mizushima has joined #dap
05:55:55 <scheib> KC: Starting with use cases for screen fold.
05:56:05 <anssik> RRSAgent, draft minutes v2
05:56:05 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
05:56:51 <scheib> ... [presenting use case document with diagrams of devices with many different folding configurations]
05:56:53 <reillyg> -> https://github.com/SamsungInternet/Explainers/blob/master/Foldables/FoldState.md
05:57:20 <scheib> ... -> https://github.com/SamsungInternet/Explainers/blob/master/Foldables/FoldState.md Fold Angle Explainer
05:57:47 <scheib> ... Some screens right next to each other considered one virtual screen.
05:58:09 <scheib> ... Consideration: Should screens not so close together still be joinable?
05:58:35 <scheib> ... What about hinges between screens and keyboards as well.
05:59:19 <scheib> ... [skimming quickly through spec draft]
05:59:30 <scheib> ... -> https://w3c.github.io/screen-fold/ Screen Fold API
05:59:47 <reillyg> RRSAgent, draft minutes v2
05:59:47 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html reillyg
05:59:50 <scheib> ... May need to standardize angles of fold
06:00:09 <scheib> ... Goal would be consistent behavior between different devices types.
06:00:34 <scheib> ... One solution is JavaScript, events on angle changes
06:01:16 <scheib> ... Others are CSS solutions... timelines... exposing the angle value.  However downsides are that some computations are not possible (e.g. angle to position).
06:01:52 <marcosc> q+
06:02:00 <anssik> q?
06:02:02 <anssik> acl marcosc
06:02:04 <anssik> ack marcosc
06:02:18 <scheib> MC: Has this been taken to CSS WG?
06:02:39 <scheib> KC: Individually explored, and taken to some CSS experts.
06:03:30 <anssik> Discussed with Alan Stearns, CSS WG co-chair
06:03:30 <scheib> AK: Did confer with CSS co-chair Alan Stearns, Adobe
06:03:53 <scheib> KC: Would still desire JavaScript for some applications, such as 'children's book'.
06:04:05 <scheib> RG: Can a CSS value be pulled out of CSS to JS?
06:04:31 <scheib> TS: Media query ... this might be possible?
06:04:41 <scheib> ... just in theory at least
06:05:00 <scheib> ... Why was this raised for CSS in general?
06:05:52 <scheib> KC: [discussing some calculation challenges, e.g. degree conversion to other unit types]
06:05:52 <xfq> See also: https://drafts.csswg.org/css-values-4/#example-1daf921b
06:06:22 <scheib> TS: Houdini seemed to have related solutions, may be able to bring something from there.
06:06:35 <scheib> JH: Why is CSS desired?
06:07:00 <scheib> KC: For basic layout / animations, want to avoid JavaScript
06:07:08 <scheib> RG: [similar statement]
06:07:22 <marcosc> q+
06:07:28 <scheib> MC: Performance, smoother animations
06:07:31 <anssik> Present+ Philippe_Le_Hageret, Eric_Mcobobia, Hazel, Heejin_Chung, James_Hollyer, Lars_Knudsen, Matt_Reynolds, Peter_Burrows, Satotu_Takagi, Takio_Yamaoka, Tomoaki_Mizushima
06:07:36 <tomayac> Here it is: https://drafts.css-houdini.org/css-properties-values-api/
06:07:40 <anssik> q?
06:07:44 <anssik> ack marcosc
06:07:49 <anssik> RRSAgent, draft minutes v2
06:07:49 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
06:07:59 <scheib> TS: See https://drafts.css-houdini.org/css-properties-values-api/
06:08:38 <scheib> MC: Are postures bound to angles?  Can variables be used, e.g. 'this is a laptop'
06:09:09 <tomayac> This would of course require to register something like "degree" in https://drafts.csswg.org/css-values-3/
06:09:13 <scheib> MC: Can we avoid pre-sets, which might limit devices used?
06:09:23 <scheib> KC: There has been feedback requesting standardization
06:09:49 <reillyg> q
06:09:53 <scheib> KC: Intel working with partners has heard this desire that multiple devices function similarly
06:09:53 <reillyg> q+
06:11:20 <tomayac> For the record, I love this API, I'm purely curious to hear why folks said it couldn't be done in CSS
06:11:32 <scheib> AM: for each posture desire OS actions to also be consistant
06:12:23 <scheib> MC: Concern of exposing both angle and mapping, because developers may use the wrong one.
06:12:47 <scheib> AM: One solution is to start with posture, and see if it is sufficient and wait for requests to read the angle
06:13:35 <anssik> RRSAgent, draft minutes v2
06:13:35 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
06:13:57 <scheib> RG: Will need to react to changes in the ecosystem, and new hardware.  Need to be selective for what is standardized.
06:14:04 <marcosc> +q
06:14:13 <reillyg> ack reillyg
06:14:14 <anssik> q?
06:14:39 <scheib> TC: Fingerprinting concern with fine grained angle
06:15:02 <tomayac> s/TC/TS
06:15:02 <scheib> KC: Without fine grained the animations will be poor.  A mitigation may be to only report when changing.
06:15:18 <scheib> RG: Each time a laptop is opened it will be to a different amount
06:15:44 <marcosc> q-
06:15:46 <tomayac> …but during a session, the screen probably stays static for longer periods
06:16:11 <scheib> ... RG: Do we have more use cases for fine grained angles?
06:16:14 <plh> q+
06:16:20 <anssik> ack marcosc
06:16:24 <anssik> ack plh
06:16:51 <scheib> PH: To access API are permissions needed?
06:17:31 <scheib> KC: Integration with screen placement may affect permissions
06:18:02 <scheib> AK: Can we generate synthetic (fake) values for legacy devices?
06:18:56 <scheib> PH: Fingerprinting concern if not behind a permission.
06:19:09 <scheib> RG: How does this differ vs screen / window resolution?
06:19:44 <scheib> PH: This will add to the problem
06:19:56 <scheib> MC: Resolution is used as a vector
06:20:17 <scheib> AK: The specification should describe the concern and address it
06:20:29 <reillyg> q+
06:20:43 <scheib> MC also noting angle may be constantly changing
06:21:29 <reillyg> q-
06:21:47 <plh> --> https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications
06:22:12 <scheib> RG: Concern that permissions can solve the fingerprinting concern.  Can browsers describe the risk sufficiently?
06:22:21 <anssik> q?
06:22:29 <scheib> PH: notes --> https://w3c.github.io/fingerprinting-guidance/ Mitigating Browser Fingerprinting in Web Specifications
06:22:53 <scheib> PH: Discuss with the privacy WG sooner than later
06:23:10 <xfq> s/privacy WG/Privacy IG/
06:24:17 <scheib> AK: Should address in spec and address anticipated questions and then request review.
06:25:16 <anssik> q?
06:25:37 <marcosc> q+
06:26:09 <scheib> KC: Discussions in github issues appreciated.
06:26:19 <marcosc> q-
06:26:23 <anssik> q?
06:26:33 <marcosc> MC: I'll send stuff to github
06:27:08 <Eric> Eric has joined #dap
06:27:15 <scheib> Topic: Network Info
06:27:16 <tomayac> Spec: https://w3c.github.io/screen-fold/ Repo: https://github.com/w3c/screen-fold/issues
06:27:18 <mfoltzgoogle> * It's past my curfew, so I will say good night. Thank you chairs for allowing me to observe the meeting.
06:27:52 <xfq> https://wicg.github.io/netinfo/
06:27:56 <scheib> AK: A long history in this WG, was previously discussed.
06:28:07 <scheib> AK: Inviting Marcos to discuss
06:28:18 <scheib> ... --> https://wicg.github.io/netinfo/
06:28:46 <scheib> MC: Original use cases:
06:28:47 <tomayac> Use cases: https://wicg.github.io/netinfo/#requirements-and-use-cases
06:29:02 <scheib> ... --> https://wicg.github.io/netinfo/#requirements-and-use-cases Use cases
06:29:13 <scheib> ... What type of connection is being used?
06:29:24 <scheib> ... Raised many concerns of exposing too much information
06:29:56 <scheib> ... Picture element came along, which allows responsiveness to environment.   Also media queries, lazy loading, etc.
06:30:04 <scheib> ... Needs of the API were reduced.
06:30:27 <scheib> ... Notably: Did not address if the connection is "Metered" or not.
06:30:35 <scheib> ... Does the connection cost money.
06:31:06 <scheib> ... Metered or not could be a signal.
06:31:11 <tomayac> We have Save-Data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) and prefers-reduced-data now (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data)
06:31:20 <xfq> https://github.com/WICG/netinfo/issues/84
06:31:45 <scheib> ... --> https://github.com/WICG/netinfo/issues/84 Metered Github Issue
06:32:02 <scheib> AK: Does metered mean there's a data limit?  Or a charge?
06:32:10 <scheib> MC: Up to the user + user agent.
06:32:57 <scheib> RG: Some OSes may make assumptions, or get a signal from a carrier.
06:33:55 <scheib> TS: On windows, when tethered to a phone, poor results can happen, but there are heuristics to detect connection type.
06:34:07 <scheib> MC: iOS option briefly shown
06:34:20 <tomayac> Windows link: https://support.microsoft.com/en-us/windows/metered-connections-in-windows-10-7b33928f-a144-b265-97b6-f2e95a87c408
06:34:40 <scheib> TS: --> https://support.microsoft.com/en-us/windows/metered-connections-in-windows-10-7b33928f-a144-b265-97b6-f2e95a87c408 Windows link
06:34:45 <tomayac> Low data mode on iOS: https://support.apple.com/en-ca/HT210596#:~:text=Wi%2DFi%3A-,Open%20the%20Settings%20app.,Turn%20on%20Low%20Data%20Mode.
06:35:10 <anssik> q+
06:35:28 <scheib> MC: Confusion around heuristics working well enough, and what some OS signals even mean.
06:35:42 <scheib> MC:  Connection Type
06:36:03 <scheib> MC:  What type of bandwidth may be available, may influence what is downloaded
06:36:24 <scheib> MC: Concerns around connection type being poorly identified, e.g. due to transient conditions.
06:36:25 <anssik> ack anssik
06:36:38 <scheib> q+
06:36:47 <scheib> AK: Where has this API shipped?
06:37:01 <tomayac> https://caniuse.com/mdn-api_networkinformation
06:37:02 <scheib> AK: Data from real-world use cases?
06:37:44 <scheib> JH: Seeing Chrome is behind a flag
06:37:51 <scheib> TS: notes https://caniuse.com/mdn-api_networkinformation
06:38:08 <scheib> RG: [details missed]
06:38:40 <scheib> TS: Differential Serving == adjusting what applications do based on connection type / quality.
06:39:04 <scheib> TS: We have Save-Data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) and prefers-reduced-data now (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data)
06:39:43 <scheib> TS: concern isn't about use cases, but concern is that information is too fine grained.
06:40:05 <anssik> Repeating what TS said earlier, we have Save-Data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data) and prefers-reduced-data now (https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data)
06:40:10 <scheib> TS: precision now is more than needed for differential serving
06:40:35 <marcosc> https://www.w3.org/TR/netinfo-usecases/
06:40:42 <scheib> MC: Problem is that API is overzealous
06:41:07 <scheib> AK: Is earlier editor Ilya Grigorik still working on this?
06:41:13 <tomayac> s/differential serving/adaptive loading/
06:41:14 <tomayac> https://addyosmani.com/blog/adaptive-loading/
06:41:37 <marcosc> q+
06:41:41 <anssik> q?
06:41:46 <anssik> ack scheib
06:41:49 <scheib> TC: Correcting use cases term that are known employed: adaptive loading https://addyosmani.com/blog/adaptive-loading/
06:41:59 <tomayac> s/TC/TS
06:42:48 <marcosc> VS: what use cases remain that we want to solve... seems like we want this adaptive loading use case solved
06:43:14 <scheib>  VS: what use cases remain that we want to solve... seems like we want this adaptive loading use case solved
06:43:14 <anssik> q?
06:44:05 <scheib> TS: One problem remaining is a site changing behavior even though the user prefers another.  E.g. a user who would want to wait and see a higher resolution image.
06:44:20 <amandy> amandy has joined #dap
06:44:27 <scheib> RG: Yes, issue is "what is the signal"
06:45:01 <scheib> RG: A) the carrier indicating connection type, or B) User indicating what type of bandwith usage they want
06:45:23 <tomayac> Chrome Lite mode reillyg was referring to: https://support.google.com/chrome/answer/2392284?co=GENIE.Platform%3DAndroid&hl=en
06:45:23 <scheib> RG: Related: browser 'data saving' features that can be toggled by users.
06:45:25 <anssik> q?
06:45:43 <scheib> TS: Chrome Lite mode reillyg was referring to: https://support.google.com/chrome/answer/2392284?co=GENIE.Platform%3DAndroid&hl=en
06:46:13 <anssik> ack marcosc
06:46:19 <scheib> JH: The site will need to implement functionality
06:46:25 <tomayac> On extremely slow connection Chrome would proxy pages through Google Web Light: https://support.google.com/webmasters/answer/6211428?hl=en
06:46:39 <tomayac> s/slow connection/slow connections/
06:47:03 <scheib> MC: Hard part is network signal in an interoperable manner.
06:47:40 <anssik> q?
06:47:45 <scheib> MC: Also: are client hint and CSS media-query sufficient for use case?
06:48:31 <scheib> RG: Interop is challanging.  But "is metered" and "user wants to save data" should be achievable
06:48:32 <tomayac> Nit: it's not a client hint (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH), but just a header
06:48:50 <tomayac> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data
06:48:55 <marcosc> /me thanks for clarifying tomayac
06:49:09 <scheib> TS: (Nit: it's not a client hint (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-CH), but just a header
06:49:09 <scheib> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data)
06:49:46 <scheib> AK: Reviving user override desired
06:50:18 <scheib> RG: Yes, apps need to implement the app behavior ... so a poorly behaving app may be corrected by the browser sending a different signal
06:50:54 <scheib> AK: Need a refresh of specification for 2020 context.
06:51:30 <anssik> q?
06:51:36 <scheib> TS: Will check in with editor Ilya Grigorik to see status
06:52:47 <scheib> RG: Seems we're discussing around a minimal sub-set that is already in the platform.  Could drop the spec
06:54:15 <scheib> RG: Research warranted to understand what sites are using this functionality, can e.g. Chrome deprecate them?
06:54:39 <scheib> RG: If not, at least document status quo and try to get interop
06:55:32 <scheib> TS: Is it fingerprinting use, or legitimate use?
06:56:28 <anssik> q?
06:56:52 <tomayac> +1
06:57:03 <anssik> RESOLUTION: Revise Network Info use cases for 2020 drawing from real-world usage experience e.g. for adaptive loading pattern, review what API knobs are required given the new properties HTTP Save-Data header and prefers-reduced-data CSS media feature are made available
06:57:17 <plh> rrsagent, generate minutes v2
06:57:17 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html plh
07:09:26 <tomayac> scribenick: tomayac
07:09:56 <anssik> rrsagent, generate minutes v2
07:09:56 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
07:10:36 <tomayac> TOPIC: System Wake Lock
07:10:43 <anssik> q?
07:11:30 <tomayac> reillyg Where we left the discussion as of last TPAC: we split the spec into screen and rest. Screen has shipped in Chrome, with interest from Mozilla.
07:12:00 <tomayac> Last TPAC I (@reillyg) had some ideas around system, but didn't want to distract from screen.
07:12:01 <marcosc> s/with interest from Mozilla/with "worth prototyping" from Mozilla
07:12:50 <tomayac> reillyg The observation was that there is work that sites are doing
07:13:01 <tomayac> that the site wants to tell the user they are doing
07:13:21 <tomayac> It's separate from background geolocation and geofencing
07:13:33 <tomayac> They are fascinating, but a different discussion
07:13:58 <tomayac> Examples of sites doing work would be Figma and Squoosh doing data processing
07:14:08 <tomayac> Work, which, if canceled, would be lost
07:14:22 <tomayac> Another example would be an IDE compiling code
07:14:47 <anssik> -> https://github.com/w3c/system-wake-lock/issues/4 System Wake Lock use cases meta issue
07:14:49 <tomayac> While also allowing the user to know that an operation is in process
07:15:13 <tomayac> On OS, there is the concept of foreground operation
07:15:24 <tomayac> Like downloading updates or processing photos
07:15:34 <tomayac> s/OS/OS like Android/
07:15:57 <tomayac> The proposal I hinted at last TPAC was an integration between screen wake lock and the notifications API
07:16:12 <tomayac> Along with some UI elements (indicators)
07:16:23 <anssik> q?
07:16:30 <tomayac> UAs can implement some heuristics when to show this indication
07:16:33 <anssik> q+
07:16:49 <marcosc> q+ my concern is separating the lock from the processing
07:17:05 <marcosc> q+ to say my concern is separating the lock from the processing
07:17:09 <tomayac> Developers would take these locks eagerly, and the UA could then decide whether or not to show the indicator
07:17:30 <tomayac> This is a signal the site could provide to the UA
07:17:47 <tomayac> Similar to what we have today with onunload handlers, I know that's frowned upon
07:17:59 <anssik> q?
07:17:59 <tomayac> Used to say I have unsaved changes
07:18:04 <anssik> ack anssik
07:18:24 <tomayac> @anssik What you describe at the user experience is alongside notification
07:18:41 <tomayac> Would this be dismissible UI by the user?
07:19:12 <tomayac> In your idea, if the user wishes, could the user break the lock?
07:19:36 <tomayac> @reillyg Yes, this would be interruptible
07:19:49 <anssik> q?
07:20:05 <tomayac> There is a second level to this. Background tab throttleing
07:20:42 <marcosc> -> https://github.com/WICG/page-lifecycle
07:20:43 <tomayac> Users have a lot of tabs open, and UAs try to throttle. But heuristics are hard. Is it just a carousel sliding, or something actually important?
07:21:01 <tomayac> You can balance that against the system policy
07:21:05 <anssik> q?
07:21:27 <tomayac> @anssik Am I right in assuming the API shape would be different from screen wake lock?
07:21:41 <tomayac> @reillyg We're not there yet. Not concerned about that yet.
07:21:52 <tomayac> More interested in use cases that need to be ack'ed
07:22:15 <tomayac> When you play a video, you get a screen wake lock for free. Maybe we should be stopping this.
07:22:25 <tomayac> Like when videos are used to replaced animated GIFs
07:22:38 <tomayac> Browsers will take a system wake lock when downloads run
07:22:51 <tomayac> There are cases where the browser can't decide alone and needs help
07:22:56 <anssik> q?
07:23:05 <anssik> q+ anssik to ask about abuse mitigations
07:23:07 <anssik> q?
07:23:19 <anssik> ack marcosc
07:23:19 <Zakim> marcosc, you wanted to say my concern is separating the lock from the processing
07:23:27 <JamesH> q+
07:23:43 <tomayac> @marcosc My concern would be separating wake lock and actually doing the work
07:23:54 <anssik> q?
07:23:56 <tomayac> Maybe we should have a dedicated worker
07:24:21 <tomayac> @reillyg I don't understand the difference. If it is main thread work or a worker.
07:24:46 <tomayac> @marcosc You would not be doing work on the main thread, it would enforce a best practice of working on workers
07:24:49 <anssik> q?
07:24:53 <tomayac> and not the main thread
07:25:20 <tomayac> @reillyg This makes sense. Sites can work around this. Sites could spawn a fake worker and still do work on the main thread
07:25:21 <anssik> RRSAgent, draft minutes v2
07:25:21 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
07:25:39 <tomayac> @marcosc If you do work on the main thread you get the "this site is blocked" thing
07:25:57 <tomayac> @reillyg Not talking about blocking like with loops, but just regular work
07:26:12 <tomayac> s/thing/UI/
07:26:40 <marcosc> s/@marcosc/MC:
07:26:53 <anssik> q?
07:26:58 <anssik> ack anssik
07:26:58 <Zakim> anssik, you wanted to ask about abuse mitigations
07:27:30 <tomayac> AK: How do we prevent every site declaring they are doing important work?
07:28:02 <tomayac> RG: Not concerned about this. Sites already today compete for resources.
07:28:22 <tomayac> There's a visibility tied up with that
07:28:26 <tomayac> q+
07:28:51 <tomayac> The user agent can make the intention visible to the user
07:29:06 <tomayac> AK: SGTM
07:29:07 <anssik> q?
07:29:38 <anssik> q?
07:29:46 <anssik> ack JamesH
07:30:10 <tomayac> JH: This also doesn't hog resources. The system would just go to sleep.
07:30:33 <xfq> ack queue
07:30:38 <xfq> ack "queue
07:30:38 <Zakim> "queue, you wanted to react to JamesH
07:30:40 <tomayac> When some timer has gone up, a popup could appear. Saying "this tab is preventing the system from sleeping"
07:31:08 <tomayac> I would not watch a compiler do its work
07:31:18 <tomayac> I hope the indication would be in the tab
07:31:33 <tomayac> RG: User agents could adjust the way this gets displayed
07:31:38 <anssik> q?
07:31:39 <tomayac> Including not showing it at all
07:32:07 <tomayac> For example, if a site is in the foreground, the timer could be longer
07:32:19 <tomayac> But if you're in the background, the timer could be shorter
07:32:33 <tomayac> You could then see some popup that tells you about ongoing work
07:32:49 <tomayac> The UA is given more ability to decide how to show the UI
07:32:55 <anssik> qq+
07:32:58 <anssik> q?
07:33:02 <anssik> ack anssik
07:33:02 <Zakim> anssik, you wanted to react to "queue
07:33:21 <tomayac> AK: Is there use for allowing web pages to explain the reason?
07:33:31 <marcosc> +q
07:33:32 <tomayac> Like "I'm doing video encoding"
07:33:42 <anssik> q?
07:33:51 <tomayac> RG: My strawman is that it's a type of notification that includes progress
07:34:05 <tomayac> You would have to upgrade that progress periodically
07:34:10 <tomayac> AK: I like that
07:34:13 <JamesH> qq+
07:34:18 <anssik> ack tomayac
07:34:52 <zkis> zkis has joined #dap
07:35:19 <anssik> Present+ Zoltan_Kis
07:35:37 <tomayac> TS: We have iOS' camera usage indication, but there's nothing like this on desktop
07:35:56 <anssik> anssik has changed the topic to: Agenda: https://github.com/w3c/devicesensors-wg/issues/31
07:35:57 <tomayac> RG: We have tabs red dot for recording
07:36:08 <tomayac> Also screen sharing
07:36:26 <tomayac> q++
07:36:32 <JamesH> q-
07:36:34 <anssik> q?
07:36:36 <tomayac> qq+
07:36:42 <anssik> ack +
07:36:55 <anssik> ack tomayac
07:36:55 <Zakim> tomayac, you wanted to react to tomayac
07:37:23 <tomayac> TS: Clarifying that I was talking about OS level indication
07:37:31 <tomayac> Not browser-level
07:37:51 <tomayac> RG: Windows has the concept of in-taskbar icon progress
07:37:57 <anssik> ack marcosc
07:38:16 <tomayac> MC: macOS shows geolocation in the title bar
07:38:37 <anssik> RRSAgent, draft minutes v2
07:38:37 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
07:38:42 <tomayac> MC: Tying it to "progress" sounds good
07:38:59 <tomayac> RG: We also need an indetermined mode
07:39:12 <tomayac> For things that don't know how long something will take
07:39:33 <tomayac> AK: It would be like a heartbeat
07:39:43 <tomayac> If there's no heart beat you could ask for aliveness
07:40:00 <tomayac> MC: If you see the worker is working based on CPU, you know it's busy
07:40:17 <tomayac> RG: The heartbeats are important to know if progress is being made at all
07:40:25 <anssik> q?
07:40:29 <tomayac> Does the code think it's making progress
07:40:31 <larsgk> q+
07:40:55 <tomayac> MC: For example when I'm walking I would turn off the screen, but might still be interested in progress
07:41:12 <tomayac> RG: On mobile, it's different. You're more likely to put it away instead.
07:41:26 <tomayac> The notification could still be useful
07:41:50 <tomayac> Like in the aftermath. You could discover abusive behavior
07:42:09 <tomayac> On the other hand, it could feed into systems like battery consmption
07:42:20 <tomayac> So you could see which sites have taken a lot of system locks
07:42:30 <tomayac> MC: It could be managed by the OS or the UA
07:42:35 <anssik> ack larsgk
07:43:12 <tomayac> LK: One example from enterprise would be where there is no progress for days, but the need to wake up the screen when something important happens
07:43:26 <tomayac> RG: This would be more like a kiosk mode
07:43:33 <tomayac> This is a policy the admin sets
07:43:46 <tomayac> There is a proposal for Microsoft to set install-time permissions
07:44:01 <tomayac> Like a site is run in kiosk mode. The site would declare this in its meta data
07:44:23 <tomayac> Tied in with monitoring: one of the use cases for this:
07:44:38 <tomayac> you have WebUSB where you might be flashing a device
07:44:52 <tomayac> You need to download the data, then flash
07:45:08 <tomayac> The hint is important to make the UA understand
07:45:32 <anssik> q?
07:45:54 <tomayac> AK: I feel like there is need to do more work
07:46:06 <tomayac> We have collected use cases
07:46:12 <tomayac> and excluded background geolocation
07:46:17 <tomayac> which helps frame the scope
07:46:50 <tomayac> RG: Understanding the scope helps. I would like to hear from @marcosc how he sees Mozilla perceive this?
07:46:56 <anssik> q?
07:47:11 <tomayac> MC: There is definitely a clear case for this
07:47:47 <tomayac> They need to be outlined a little bit more clearly, and then we need to think about the API shape
07:48:07 <tomayac> I don't think anything is blocking here
07:48:15 <tomayac> AK: Maybe we need an Explainer
07:48:32 <tomayac> RG: Yes. Something with the goals and non-goals defined. And the rough API shape.
07:48:51 <tomayac> MC: Some discussion of the pros and cons of the worker route
07:49:01 <tomayac> JH: Do you think worker is more feasible?
07:49:29 <tomayac> MC: Depends on how much work the browser needs to do. It's also less of a footgun
07:49:47 <tomayac> There are lots of things to consider there
07:50:05 <tomayac> AK: We need to agree on what the Explainer should contain
07:50:09 <tomayac> there is this template
07:50:18 <tomayac> Please provide key concerns and questions
07:50:28 <xfq> Template: https://w3ctag.github.io/explainers
07:50:39 <marcosc> clear use case + real world examples from native apps or things that web apps are doing today
07:50:39 <tomayac> RG: Not sure we need to go into that much detail. The template is probably good enough
07:50:58 <anssik> proposed RESOLUTION: Write System Wake Lock explainer and draft an API shape
07:51:18 <reillyg>  /me +1
07:51:24 <marcosc> +1
07:51:26 <anssik> RESOLUTION: Write System Wake Lock explainer and draft an API shape
07:51:27 <xfq> +1
07:51:31 <tomayac> =1
07:51:32 <anssik> RRSAgent, draft minutes v2
07:51:32 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
07:51:36 <tomayac> s/=1/+1
07:52:21 <tomayac> RG: This is on my/Fugu's plate. People asking for this are coming to me (@reillyg)
07:52:47 <tomayac> Wanted to get a signal from folks in thew WG if this is valid
07:52:54 <tomayac> And it seems the answer is yes
07:53:13 <tomayac> MC: Especially since screen wake lock has gone well. Offloading this cognitive load is helping us.
07:53:25 <tomayac> AK: Reilly, do you want to own this action?
07:53:31 <tomayac> RG: Sure
07:53:37 <tomayac> ACTION: Reilly to kick off the System Wake Lock explainer work
07:53:58 <anssik> RRSAgent, draft minutes v2
07:53:58 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
07:54:15 <tomayac> AK: Thanks for today. We'll be back tomorrow
07:54:24 <tomayac> Giving outlook on the agenda
07:54:27 <anssik> https://github.com/w3c/devicesensors-wg/issues/31
07:54:45 <tomayac> TOPIC: Adjourn
07:54:47 <anssik> RRSAgent, draft minutes v2
07:54:47 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/22-dap-minutes.html anssik
09:38:51 <zkis> zkis has joined #dap
09:47:25 <xfq> xfq has joined #dap
10:31:12 <Zakim> Zakim has left #dap
11:05:46 <sonia> sonia has joined #dap
12:04:20 <zkis> zkis has joined #dap
12:44:56 <ooy> ooy has joined #dap
12:45:09 <ooy> 
12:45:11 <ooy>