Editing TF minutes February 12th, 2021

Note: rrsagent wasn't added at the start of the meeting so these minutes are pasted from my IRC client...

Editing TF Minutes
February 12th, 2021

[18:00] == johanneswilm [~johanneswilm@ef89345d.public.cloak] has joined #editing
[18:00] == whsieh_ has changed nick to whsieh
[18:01] == snianu [~snianu@ef89345d.public.cloak] has joined #editing
[18:01] <BoCupp> present+
[18:01] <GameMaker> present+
[18:01] <johanneswilm> present+
[18:01] <whsieh> present+
[18:01] <comandeer> present+
[18:01] <snianu> present+
[18:02] <tilgovi> present+
[18:02] <BoCupp> topic: https://github.com/w3c/editing/issues/275<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fediting%2Fissues%2F275&data=04%7C01%7Cpcupp%40microsoft.com%7C8f09bdfbd4b54939e32608d8cfa03393%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637487634263183729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GPygvH8EncXIpvRzrRXg4k7jJvY75h0Zmad5GNddNBA%3D&reserved=0>
[18:03] * tilgovi doesn't see anyone in the hangout on my calendar... wondering where we are?
[18:04] <snianu> https://github.com/w3c/input-events/issues/115#issuecomment-777899129<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Finput-events%2Fissues%2F115%23issuecomment-777899129&data=04%7C01%7Cpcupp%40microsoft.com%7C8f09bdfbd4b54939e32608d8cfa03393%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637487634263193685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VQbipZXrWwK7NVQ8U8jhEbT1u%2BnGUK03GxjgZDig7ac%3D&reserved=0>
[18:04] <BoCupp> The hangout is here: https://hangouts.google.com/hangouts/_/calendar/MTdsbXUzcGh2aGpoZWgyaXU5Y2JqaWZyN2NAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ.05caleuqb48b7rf0qjcqbjdh97?authuser=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhangouts.google.com%2Fhangouts%2F_%2Fcalendar%2FMTdsbXUzcGh2aGpoZWgyaXU5Y2JqaWZyN2NAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ.05caleuqb48b7rf0qjcqbjdh97%3Fauthuser%3D0&data=04%7C01%7Cpcupp%40microsoft.com%7C8f09bdfbd4b54939e32608d8cfa03393%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637487634263193685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=coZbTaAz2Ehihp08WnWG%2BOTH6aodGCOVTrwUBMGJQm8%3D&reserved=0>
[18:06] <BoCupp> we should be able to make Chromium match behavior of Safari with respect to insertFromComposition being cancellable
[18:07] == alex_ [~alex@ef89345d.public.cloak] has joined #editing
[18:07] <BoCupp> two issues: 1) keydown, keyup, compositionupdate, beforeinput and input are not in same order between Chromium and Safari
[18:08] <BoCupp> 2) what's need for deleteByComposition
[18:08] <whsieh> note: safari does fire `deleteByComposition` in the case where the user is recomposing a previously committed piece of text
[18:09] <whsieh> (it's ctrl+shift+r on macOS)
[18:09] <BoCupp> johanneswilm: deleteByComposition let's some editors move selection to put composition into final place in the DOM
[18:10] <snianu> But should deleteByComposition be fired in scenarios where the user taps on a word that appears as a suggestion on the mac touch bar or android virtual keyboard that replaces the existing word?
[18:11] <BoCupp> johanneswilm: you can move selection to start composition at some place in the DOM that might be more convenient for the editor's implementation
[18:14] <BoCupp> whsieh: some IMEs during reconversion you can see deleteByComposition
[18:17] <whsieh> (re: keydown/composition event ordering — this is a known bug in Safari: https://bugs.webkit.org/show_bug.cgi?id=165004<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.webkit.org%2Fshow_bug.cgi%3Fid%3D165004&data=04%7C01%7Cpcupp%40microsoft.com%7C8f09bdfbd4b54939e32608d8cfa03393%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637487634263193685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fvdFvzGzACZYIma8TTdMah5hieQutkaq9HN0yS1pZhA%3D&reserved=0>)
[18:18] <BoCupp> snianu: deleteByComposition doesn't align well with IME events (not separate event from IME when reconverting)
[18:19] <BoCupp> johanneswilm: deleteByComposition helps for editors that want to move selection when composition starts
[18:20] <BoCupp> snianu: is there a problem with moving selection because we report context to IME and now with the move that context is lost
[18:22] <BoCupp> johanneswilm: the value is that collaborative editors aren't blocked if you can move the selection at composition start
[18:25] <BoCupp> concerned that start of composition movement will change buffer advertised to IME since that is derived by DOM... that part feels better solved by EditContext
[18:26] <BoCupp> action: investigate whether deleteByComposition will allow movement of selection at start of composition in Chromium
[18:44] <BoCupp> BoCupp: propose we open issues to specify the details of how moving selection would work.
[18:45] <BoCupp> topic: https://github.com/w3c/editing/issues/278<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fediting%2Fissues%2F278&data=04%7C01%7Cpcupp%40microsoft.com%7C8f09bdfbd4b54939e32608d8cfa03393%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637487634263203645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6NYySmSL%2Fd4H7vy4lUaN8dwI3Re9AFgLJY3ezov988I%3D&reserved=0>
[18:46] <BoCupp> johanneswilm: can we standardize movement by word and even other caret movement?
[18:46] <BoCupp> snianu: there are differences between platforms
[18:47] <BoCupp> snianu: Unicode specs also leave room for word breaking to accommodate app/platform differences
[18:48] <BoCupp> johanneswilm: but even on the same platform browsers are not the same... can we do better?
[18:53] <BoCupp> BoCupp: feel like we'd need to solve two problems: 1) what are the word breaks in plain text, 2) what are the canonical positions in the DOM to represent those
[18:58] <BoCupp> BoCupp: do we agree that following platform conventions are a goal?
[18:59] <BoCupp> whsieh: thinks that it should follow platform conventions
[19:01] <BoCupp> johanneswilm: does it make sense to standardize what it means to follow OS conventions?
[19:02] <BoCupp> johanneswilm: alternatively would anyone consider following a browser specific standard and not OS conventions
[19:05] <johanneswilm> Johanneswilm: I see basically two options: 1 - We decide we think it is a good idea for caret movement to follow platform conventions. That means that browser makers should try to follow the conventions of the OS and in terms of standardization we likely need an API for JS to query how the caret would move if the user were to ask to move it in a particular direction. Or
[19:07] <johanneswilm> 2 - We decide we think that caret movement should NOT follow platform conventions and instead we  write a spec on how the caret should move, so the caret will move the same way if it is run on Firefox on Windows or Safari on Mac OS X.
[19:08] <johanneswilm> In case 2 we might not need a a query mechanism for caret movement, as it will be the same in all browsers on all platforms and JavaScript editors can rely on the behavior always being the same.
[19:08] == whsieh [~whsieh@ef89345d.public.cloak] has quit [Ping timeout: 180 seconds]
[19:09] == comandeer [~comandeer@ef89345d.public.cloak] has quit [Ping timeout: 180 seconds]
[19:12] <johanneswilm> johanneswilm: If we don't decide either 1 or 2 and just continue as we do, we have a situation where caret movement is partially OS dependent (to the degree that the browser makers have implemented platform conventions) and additionally, whenever the JavaScript moves the caret, it follows it's own logic that is likely not platform conventions compliant.