IRC log of dap on 2020-10-22

Timestamps are in UTC.

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]