Re: minutes call 2023-11-09

Hey,
Gmail decided to scramble the contents. Here is a more readable version.


[17:03] <sanketj_> present+

[17:03] <dandclark> present+

[17:04] <smaug> present+

[17:05] <whsieh> johanneswilm: issue 198 in clipboard apis

[17:05] <comandeer> present+

[17:05] <whsieh> johanneswilm: skip to input events

[17:05] <whsieh> johanneswilm:
https://github.com/w3c/input-events/issues/147

[17:05] <whsieh> johanneswilm: allowed in FF and Chrome, but not WebKit (at
the moment)

[17:06] <whsieh> q+

[17:07] <whsieh> yep. we should add those arguments to the event init

[17:08] --> snianu (~snianu@7e4e2622.public.cloak) has joined this channel.

[17:09] <snianu> present+

[17:09] <whsieh> smaug: weird that getter is inconsistent with init
arguments

[17:09] <whsieh> johanneswilm: next issue:
https://github.com/w3c/input-events/issues/146

[17:10] <dandclark> q+

[17:10] --> edgar (~uid184785@7e4e2622.public.cloak) has joined this
channel.

[17:11] <whsieh> johanneswilm: should we align getTargetRanges in all
cases? or just some types of ranges?

[17:12] <whsieh> dandclark: w.r.t. EditContext, getTargetRanges is needed
for many commands

[17:12] <whsieh> dandclark: for deletion cmds we have them zeroed out

[17:12] <whsieh> (does "zeroed out" mean empty range? or null range?)

[17:12] <whsieh> I see, thanks

[17:13] <whsieh> dandclark: this makes it so that sites are unlikely to
rely on this, while we figure this out

[17:13] <whsieh> johanneswilm: would be best to not have them removed

[17:14] <whsieh> dandclark: if we ship with them working differently,
compat will be difficult moving forward

[17:15] <whsieh> johanneswilm: the non-trivial deletion commands need
getTargetRanges (request from JS authors)

[17:15] <whsieh> johanneswilm: ...such as delete word, delete sentence, etc.

[17:15] <whsieh> johanneswilm: FB's editor just uses API for extending
selection to determine ranges

[17:15] <whsieh> johanneswilm: masayuki felt that was not a good way

[17:16] <whsieh> johanneswilm: unrealistic to align on complex editing like
table merging, paragraph merging

[17:16] <whsieh> johanneswilm: maybe we can align on behaviors when
selection is collapsed

[17:16] <whsieh> johanneswilm: (and align on accented character behavior)

[17:17] <whsieh> johanneswilm: on several platforms it's common to delete
the accent first and then delete the base char

[17:17] <whsieh> q+

[17:17] <whsieh> johanneswilm: I'm a bit afraid that we may never get full
agreement

[17:19] <whsieh> whsieh: can we use insert text replacement?

[17:20] <whsieh> example character: b̂

[17:20] <whsieh> johanneswilm: Chrome only deletes accent mark, target
range is inconsistent

[17:21] <whsieh> johanneswilm: or actually it makes sense because target
character is affected?

[17:21] <whsieh> q+

[17:22] <whsieh> johanneswilm: defn. of target ranges is very wishy-washy

[17:22] <whsieh> johanneswilm: however, for these character type of
deletions it makes sense to be more specific

[17:23] <whsieh> johanneswilm: we should specify this character deletion
case, maybe not in the table/paragraph merge case

[17:24] <whsieh> dandclark: approach sounds good to me

[17:25] <whsieh> smaug: doesn't cover the extent of #146

[17:25] <whsieh> johanneswilm: resolution is: be more specific in
char-level deletions

[17:25] <whsieh> next up: https://github.com/w3c/clipboard-apis/pull/198

[17:26] <snianu> trying to speak

[17:26] <snianu> can you hear me?

[17:26] <whsieh> snianu: audio issues, let's move on for now

[17:26] <whsieh> snianu: nvm audio issues fixed!

[17:27] <whsieh> snianu: if clipboard item is empty and developer writes to
clipboard, the write will throw an exception in Chrome but FF/WebKit allows
that

[17:28] <whsieh> s/clipboard item is empty/clipboard item list is empty/

[17:28] <whsieh> snianu: creates confusion for web dev since it's unclear
if they need to retry, or…

[17:28] <whsieh> q+

[17:29] <dandclark> q+

[17:29] <whsieh> s/developer writes to clipboard/developer reads from
clipboard/

[17:29] <whsieh> q-

[17:29] <whsieh> snianu: read should not throw exception, write should
throw exception

[17:30] <whsieh> snianu: with current DT APIs dev cannot clear clipboard by
writing

[17:30] <whsieh> snianu: with async clipboard API you can write empty item
(?)

[17:30] <whsieh> snianu: maybe flag to indicate that clipboard item is
intentionally "empty"

[17:30] <whsieh> q+

[17:32] <whsieh> whsieh: if we want to expose a "clear clipboard" API, it
should probably be navigator.clipboard.clear() or something

[17:33] <whsieh> johanneswilm: seems we're all in agreement

[17:33] <whsieh> sanketj_: to summarize, allow read empty items

[17:34] <whsieh> can you link it?

[17:34] <whsieh> next up: https://github.com/w3c/editing/issues/439

[17:35] <whsieh> snianu: WebKit says "web custom formats are a tracking
vector"

[17:35] <whsieh> snianu: discussed this with internal privacy folks

[17:36] <whsieh> snianu: can we allow max 5 custom formats?

[17:36] <whsieh> johanneswilm: is this up to UA, or baked into spec

[17:37] <whsieh> snianu: current proposal is to add to spec

[17:38] <whsieh> smaug: unclear if this addresses anything since you could
have app that only reads 1 type of data

[17:39] <whsieh> smaug: doesn't mitigate core issue

[17:40] <whsieh> snianu: if you only have  < 5 types, tracking vector is
smaller

[17:40] <whsieh> q+

[17:40] <whsieh> snianu: making it harder for sites to detect

[17:41] <johanneswilm> q+

[17:41] <whsieh> whsieh: not robust to collusion

[17:42] <whsieh> snianu: 5 is just an arbitrary number. maybe we can start
with 1?

[17:42] <sanketj_> q+

[17:43] <whsieh> snianu: ack that sites can use the same 5 custom formats
to track users across web

[17:43] <whsieh> snianu: it does restrict to small number at least

[17:44] <whsieh> johanneswilm: if you had 1000 custom formats, you could
have an app that spams arbitrary types on the clipboard, can't do this kind
of spam with only limited number of types

[17:48] --> whsieh_ (~whsieh@7e4e2622.public.cloak) has joined this channel.

[17:48] <johanneswilm> q+

[17:49] <whsieh_> sanketj_: the first time you paste it'll get populated on
the clipboard

[17:50] <whsieh_> whsieh: collusion is a problem with custom formats in
general, not just the limit

[17:51] <-- whsieh (~whsieh@7e4e2622.public.cloak) has left this server
(Ping timeout: 180 seconds).

[17:52] <whsieh_> sanketj_: best thing we can do while still enabling this
use case is limit privacy impact

[17:52] <whsieh_> sanketj_: don't allow too many custom formats to be
delayed

[17:53] <whsieh_> sanketj_: privacy problems are inherent to API

[17:53] <whsieh_> sanketj_: source app is going to know that custom format
was pasted in

[17:53] <whsieh_> *destination*?

[17:53] <whsieh_> johanneswilm: we should continue discussion in the issue

[17:53] <whsieh_> I can ping Anne and discuss offline

[17:54] <whsieh_> johanneswilm: maybe another dedicated meeting slot

[17:55] <whsieh_> johanneswilm: let's move on —
https://github.com/w3c/edit-context/issues/71

[17:55] <whsieh_> johanneswilm: what connection should there be between
execCommand and EC?

[17:55] <dandclark> q+

[17:56] <whsieh_> dandclark: agree with johanneswilm, copy needed. agree
with masayuki, we don't generally want to support this

[17:57] <edgar> q+

[17:57] <whsieh_> dandclark: simplest solution: commands that are available
when focused in non-EC should be available in EC

[17:58] <whsieh_> edgar: we are working on shipping clipboard API (?)

[17:58] <whsieh_> johanneswilm: resolve on dandclark's comment above

[17:58] <sanketj_> s/privacy problems are inherent to API/source app will
have to know when a paste happens and what format is requested/

[17:58] <whsieh_> https://github.com/w3c/edit-context/issues/74

[17:59] <whsieh_> dandclark: cE=false with nested cE=true works

[17:59] <whsieh_> dandclark: EC should work the same way, make it possible
to nest

[17:59] <whsieh_> dandclark: is in line with previous resolution

[18:00] <whsieh_> dandclark: if no CE=false, then EC is ignored

johanneswilm: resolve on dandclark's comment above


On Thu, Nov 9, 2023 at 6:09 PM Johannes Wilm <mail@johanneswilm.org> wrote:

> scribe: whsieh [17:03] <sanketj_> present+ [17:03] <dandclark> present+
> [17:04] <smaug> present+ [17:05] <whsieh> johanneswilm: issue 198 in
> clipboard apis [17:05] <comandeer> present+ [17:05] <whsieh> johanneswilm:
> skip to input events [17:05] <whsieh> johanneswilm:
> https://github.com/w3c/input-events/issues/147 [17:05] <whsieh>
> johanneswilm: allowed in FF and Chrome, but not WebKit (at the moment)
> [17:06] <whsieh> q+ [17:07] <whsieh> yep. we should add those arguments to
> the event init [17:08] --> snianu (~snianu@7e4e2622.public.cloak) has
> joined this channel. [17:09] <snianu> present+ [17:09] <whsieh> smaug:
> weird that getter is inconsistent with init arguments [17:09] <whsieh>
> johanneswilm: next issue: https://github.com/w3c/input-events/issues/146
> [17:10] <dandclark> q+ [17:10] --> edgar (~uid184785@7e4e2622.public.cloak)
> has joined this channel. [17:11] <whsieh> johanneswilm: should we align
> getTargetRanges in all cases? or just some types of ranges? [17:12]
> <whsieh> dandclark: w.r.t. EditContext, getTargetRanges is needed for many
> commands [17:12] <whsieh> dandclark: for deletion cmds we have them zeroed
> out [17:12] <whsieh> (does "zeroed out" mean empty range? or null range?)
> [17:12] <whsieh> I see, thanks [17:13] <whsieh> dandclark: this makes it so
> that sites are unlikely to rely on this, while we figure this out [17:13]
> <whsieh> johanneswilm: would be best to not have them removed [17:14]
> <whsieh> dandclark: if we ship with them working differently, compat will
> be difficult moving forward [17:15] <whsieh> johanneswilm: the non-trivial
> deletion commands need getTargetRanges (request from JS authors) [17:15]
> <whsieh> johanneswilm: ...such as delete word, delete sentence, etc.
> [17:15] <whsieh> johanneswilm: FB's editor just uses API for extending
> selection to determine ranges [17:15] <whsieh> johanneswilm: masayuki felt
> that was not a good way [17:16] <whsieh> johanneswilm: unrealistic to align
> on complex editing like table merging, paragraph merging [17:16] <whsieh>
> johanneswilm: maybe we can align on behaviors when selection is collapsed
> [17:16] <whsieh> johanneswilm: (and align on accented character behavior)
> [17:17] <whsieh> johanneswilm: on several platforms it's common to delete
> the accent first and then delete the base char [17:17] <whsieh> q+ [17:17]
> <whsieh> johanneswilm: I'm a bit afraid that we may never get full
> agreement [17:19] <whsieh> whsieh: can we use insert text replacement?
> [17:20] <whsieh> example character: b̂ [17:20] <whsieh> johanneswilm:
> Chrome only deletes accent mark, target range is inconsistent [17:21]
> <whsieh> johanneswilm: or actually it makes sense because target character
> is affected? [17:21] <whsieh> q+ [17:22] <whsieh> johanneswilm: defn. of
> target ranges is very wishy-washy [17:22] <whsieh> johanneswilm: however,
> for these character type of deletions it makes sense to be more specific
> [17:23] <whsieh> johanneswilm: we should specify this character deletion
> case, maybe not in the table/paragraph merge case [17:24] <whsieh>
> dandclark: approach sounds good to me [17:25] <whsieh> smaug: doesn't cover
> the extent of #146 [17:25] <whsieh> johanneswilm: resolution is: be more
> specific in char-level deletions [17:25] <whsieh> next up:
> https://github.com/w3c/clipboard-apis/pull/198 [17:26] <snianu> trying to
> speak [17:26] <snianu> can you hear me? [17:26] <whsieh> snianu: audio
> issues, let's move on for now [17:26] <whsieh> snianu: nvm audio issues
> fixed! [17:27] <whsieh> snianu: if clipboard item is empty and developer
> writes to clipboard, the write will throw an exception in Chrome but
> FF/WebKit allows that [17:28] <whsieh> s/clipboard item is empty/clipboard
> item list is empty/ [17:28] <whsieh> snianu: creates confusion for web dev
> since it's unclear if they need to retry, or… [17:28] <whsieh> q+ [17:29]
> <dandclark> q+ [17:29] <whsieh> s/developer writes to clipboard/developer
> reads from clipboard/ [17:29] <whsieh> q- [17:29] <whsieh> snianu: read
> should not throw exception, write should throw exception [17:30] <whsieh>
> snianu: with current DT APIs dev cannot clear clipboard by writing [17:30]
> <whsieh> snianu: with async clipboard API you can write empty item (?)
> [17:30] <whsieh> snianu: maybe flag to indicate that clipboard item is
> intentionally "empty" [17:30] <whsieh> q+ [17:32] <whsieh> whsieh: if we
> want to expose a "clear clipboard" API, it should probably be
> navigator.clipboard.clear() or something [17:33] <whsieh> johanneswilm:
> seems we're all in agreement [17:33] <whsieh> sanketj_: to summarize, allow
> read empty items [17:34] <whsieh> can you link it? [17:34] <whsieh> next
> up: https://github.com/w3c/editing/issues/439 [17:35] <whsieh> snianu:
> WebKit says "web custom formats are a tracking vector" [17:35] <whsieh>
> snianu: discussed this with internal privacy folks [17:36] <whsieh> snianu:
> can we allow max 5 custom formats? [17:36] <whsieh> johanneswilm: is this
> up to UA, or baked into spec [17:37] <whsieh> snianu: current proposal is
> to add to spec [17:38] <whsieh> smaug: unclear if this addresses anything
> since you could have app that only reads 1 type of data [17:39] <whsieh>
> smaug: doesn't mitigate core issue [17:40] <whsieh> snianu: if you only
> have < 5 types, tracking vector is smaller [17:40] <whsieh> q+ [17:40]
> <whsieh> snianu: making it harder for sites to detect [17:41]
> <johanneswilm> q+ [17:41] <whsieh> whsieh: not robust to collusion [17:42]
> <whsieh> snianu: 5 is just an arbitrary number. maybe we can start with 1?
> [17:42] <sanketj_> q+ [17:43] <whsieh> snianu: ack that sites can use the
> same 5 custom formats to track users across web [17:43] <whsieh> snianu: it
> does restrict to small number at least [17:44] <whsieh> johanneswilm: if
> you had 1000 custom formats, you could have an app that spams arbitrary
> types on the clipboard, can't do this kind of spam with only limited number
> of types [17:48] --> whsieh_ (~whsieh@7e4e2622.public.cloak) has joined
> this channel. [17:48] <johanneswilm> q+ [17:49] <whsieh_> sanketj_: the
> first time you paste it'll get populated on the clipboard [17:50] <whsieh_>
> whsieh: collusion is a problem with custom formats in general, not just the
> limit [17:51] <-- whsieh (~whsieh@7e4e2622.public.cloak) has left this
> server (Ping timeout: 180 seconds). [17:52] <whsieh_> sanketj_: best thing
> we can do while still enabling this use case is limit privacy impact
> [17:52] <whsieh_> sanketj_: don't allow too many custom formats to be
> delayed [17:53] <whsieh_> sanketj_: privacy problems are inherent to API
> [17:53] <whsieh_> sanketj_: source app is going to know that custom format
> was pasted in [17:53] <whsieh_> *destination*? [17:53] <whsieh_>
> johanneswilm: we should continue discussion in the issue [17:53] <whsieh_>
> I can ping Anne and discuss offline [17:54] <whsieh_> johanneswilm: maybe
> another dedicated meeting slot [17:55] <whsieh_> johanneswilm: let's move
> on — https://github.com/w3c/edit-context/issues/71 [17:55] <whsieh_>
> johanneswilm: what connection should there be between execCommand and EC?
> [17:55] <dandclark> q+ [17:56] <whsieh_> dandclark: agree with
> johanneswilm, copy needed. agree with masayuki, we don't generally want to
> support this [17:57] <edgar> q+ [17:57] <whsieh_> dandclark: simplest
> solution: commands that are available when focused in non-EC should be
> available in EC [17:58] <whsieh_> edgar: we are working on shipping
> clipboard API (?) [17:58] <whsieh_> johanneswilm: resolve on dandclark's
> comment above [17:58] <sanketj_> s/privacy problems are inherent to
> API/source app will have to know when a paste happens and what format is
> requested/ [17:58] <whsieh_> https://github.com/w3c/edit-context/issues/74
> [17:59] <whsieh_> dandclark: cE=false with nested cE=true works [17:59]
> <whsieh_> dandclark: EC should work the same way, make it possible to nest
> [17:59] <whsieh_> dandclark: is in line with previous resolution [18:00]
> <whsieh_> dandclark: if no CE=false, then EC is ignored johanneswilm:
> resolve on dandclark's comment above
>
> --
> Johannes Wilm, PhD
> tel +46766922220
> https://www.johanneswilm.org
>


-- 
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org