[Minutes] Editing WG — 6/8/2023

[08:03] <whsieh_> johanneswilm: start with https://github.com/w3c/editing/issues/430
[08:03] <whsieh_> johanneswilm: what happens if you Return in editing host?
[08:04] <whsieh_> smaug: up to other implementors to comment
[08:04] <whsieh_> johanneswilm: default behavior is overridden by JS in practice
[08:04] <whsieh_> johanneswilm: but default behavior should be well-defined and spec'ed
[08:05] == edgar [~uid184785@1d899584.public.cloak] has joined #editing
[08:05] == whsieh [~whsieh@1d899584.public.cloak] has quit [Ping timeout: 180 seconds]
[08:06] <whsieh_> whsieh_: can of worms specifying this
[08:06] == sanketj [~uid392014@1d899584.public.cloak] has joined #editing
[08:07] <whsieh_> johanneswilm: EditContext or beforeinput exist to allow editors to get consistent behavior
[08:08] <whsieh_> johanneswilm: next: https://github.com/w3c/edit-context/issues/50
[08:09] <whsieh_> dandclark: lots of potential tricky corner cases if EC can be associated with multiple elements
[08:09] <whsieh_> dandclark: (shadow roots, etc.)
[08:09] <whsieh_> dandclark: let's start with having one associated element at a time, and let's write the API such that it can be extended
[08:10] <whsieh_> dandclark: myElement.eC = eC throws
[08:10] <whsieh_> dandclark: main use case for multiple associated elements is multi-page editing scenario
[08:11] <whsieh_> dandclark: not super clear how much that actually helps
[08:11] <whsieh_> q+
[08:11] <whsieh_> dandclark: weirdness with state mgmt
[08:11] <whsieh_> dandclark: proposal is to throw upon attempting associated with multiple elements
[08:12] <whsieh_> johanneswilm: what about associated EC with parent?
[08:13] <whsieh_> dandclark: everything underneath it becomes editable w.r.t. caret placement
[08:13] <smaug> q+
[08:13] <whsieh_> dandclark: I suppose page could set cE=false
[08:15] <whsieh_> smaug: multiple associated elements is related to third issue (coord spaces)
[08:16] <whsieh_> whsieh_: (a bit earlier) motivation for multiple elements was being able to show IME composition spanning multiple discontiguous Dom elements
[08:16] <whsieh_> dandclark: coordinate spaces is a good example of something that becomes more complicated with multiple elements
[08:17] <whsieh_> dandclark: I experimented with native word on windows — they try hard to keep the IME *not* overflow onto the next page
[08:18] <whsieh_> dandclark: seems like there's agreement to start with single element
[08:18] <whsieh_> johanneswilm: we resolve on ^
[08:18] <whsieh_> johanneswilm: onto https://github.com/w3c/edit-context/issues/40
[08:19] <whsieh_> dandclark: works by introducing new HTML attr on Element
[08:19] <whsieh_> dandclark: should we consider alt. where we just have API on EC?
[08:20] <whsieh_> dandclark: (e.g. EC.attach())
[08:20] <whsieh_> dandclark: kind of like current API shape since it mirrors contentEditable
[08:20] <smaug> q+
[08:20] <whsieh_> dandclark: devs will be used to that pattern
[08:20] <whsieh_> dandclark: maybe that outweighs downside of polluting HTML element API surface
[08:21] <whsieh_> smaug: also like current API shape
[08:21] <whsieh_> smaug: nice because the element naturally keeps EC alive
[08:21] <whsieh_> smaug: re: only working on subset of elements, there is precedent for attachShadow()
[08:21] <johanneswilm> q+
[08:22] <whsieh_> johanneswilm: this isn't an API that you quickly hack together in dev console
[08:22] <sanketj> +1 to aligning with precedent like attachShadow
[08:22] <whsieh_> johanneswilm: in practice, won't make much difference because barrier to adoption is relatively high
[08:23] <whsieh_> dandclark: lifetime of EC makes a lot of sense
[08:24] <whsieh_> whsieh_: I'm okay either way. above arguments make sense to me
[08:24] == alexk [~alexk@1d899584.public.cloak] has joined #editing
[08:24] <whsieh_> johanneswilm: resolution: group is okay with the current behavior, and we'll sync up with Anne
[08:24] <whsieh_> johanneswilm: next: https://github.com/w3c/edit-context/issues/39
[08:25] <whsieh_> dandclark: this is about where the IME window (and other selection UI) should be drawn
[08:25] <whsieh_> dandclark: currently all specified in client coords
[08:25] <whsieh_> dandclark: consequence of this is that when the page is scrolled, coordinates are no longer valid
[08:26] <whsieh_> dandclark: requires author to listen for scrolling and adjust
[08:27] <whsieh_> dandclark: alt. to consider: have coordinate space relative to EC-associated element
[08:27] <whsieh_> dandclark: if the position of the element moves, UA can handle that
[08:27] <whsieh_> dandclark: use page coordinates instead (content coordinates)
[08:28] <whsieh_> dandclark: ..so that it remains valid when scrolling
[08:28] <johanneswilm> q+
[08:28] <whsieh_> dandclark: my preference: go with client coordinates, better integration with getBoundingClientRects()
[08:29] <whsieh_> dandclark: approach where associated element is the coordinate space has the problem of extensibility if there's multiple elements in the future
[08:29] <whsieh_> q+
[08:29] <whsieh_> dandclark: most authors probably don't care much about scroll
[08:30] <whsieh_> johanneswilm: it's fairly simple to go from client -> page
[08:31] <whsieh_> johanneswilm: what happens if DOM is changed outside of EC-associated element? does that influence our decision here
[08:32] <whsieh_> dandclark: about elements changing outside of the associated element — talked to GDocs, and they want main editor in <canvas> still
[08:33] <whsieh_> dandclark: they want to be able to set the IME UI over canvas (outside of EC-associated element)
[08:33] <whsieh_> (correction: "and they want main editor in <canvas> still" -> "they want the EC-associated element to not be the canvas")
[08:34] <whsieh_> dandclark: there is advantage to making it possible for author to position IME window outside of associated element
[08:34] <whsieh_> dandclark: this makes it weirder if the coord system is relative to associated element
[08:35] <whsieh_> johanneswilm: oh, we need to make it clear that negative coordinates are possible
[08:35] <whsieh_> whsieh_: what's the disadvantage of using page vs. client
[08:36] <whsieh_> dandclark: (iframes)
[08:36] <whsieh_> dandclark: client coordinates are more unambiguous
[08:37] <whsieh_> dandclark: no very strong arguments either way. leaning towards client coords for simplicity
[08:38] <whsieh_> johanneswilm: if we have client coordinates, it makes it hard to automatically move IME window when scrolling
[08:39] <whsieh_> johanneswilm: do we want browsers to automatically move IME window when scrolling?
[08:39] <whsieh_> chris: good to move with window
[08:40] <whsieh_> smaug: how does developer handle this behavior?
[08:40] <whsieh_> johanneswilm: are there cases where browser may get it wrong?
[08:40] <whsieh_> johanneswilm: maybe this should be an option on the part of developer
[08:41] <whsieh_> dandclark: easy to get wrong if we use page coordinates and the EC is in an iframe but the outer page is scrolling
[08:41] <snianu> would we handle panning/browser zoom the same way as scrolling?
[08:41] <whsieh_> smaug: in GDocs if associated element is outside of viewport things get weird
[08:42] <whsieh_> chris: so in situation where associated element is not tied to UI it doesn't make sense to have coordinates relative to EC host
[08:43] <whsieh_> dandclark: maybe this is something we punt on — do simple thing first (client), then we can add options to report different coordinate spaces
[08:44] <whsieh_> johanneswilm: is that something we can agree with? (start with client coordinates, and consider fancier options in v2)
[08:44] <whsieh_> chris: dan, can you confirm that concrete use cases work with client coords?
[08:45] <whsieh_> dandclark: yes, with caveat that page authors handle scrollling
[08:45] <whsieh_> *scrolling
[08:45] <whsieh_> dandclark: also uncommon that authors need this
[08:45] <whsieh_> q+
[08:45] <whsieh_> (q- just wanted to mention it's def. a bug)
[08:46] <whsieh_> whsieh_: we should call out in non-normative note or an developer example
[08:47] <whsieh_> johanneswilm: proposal — go with client coords, document this in non-normative note, and consider more complex options in v2
[08:48] <whsieh_> johanneswilm: should we have a July meeting? (middle of summer holidays). if there are no issues in about a month, we can cancel
[08:49] <whsieh_> chris: quick detour back to #430
[08:50] <whsieh_> johanneswilm: it's basically impossible to 100% standardize this in every scenario. but maybe worth specifying in document somewhere
[08:51] <whsieh_> chris: the reason foolip filed the issue is that there are tests relevant to this in Interop 2023
[08:52] <whsieh_> johanneswilm: if the goal is to have browsers match 100% then unsure if we can do it
[08:52] <whsieh_> (^ I agree)
[08:52] <whsieh_> q+
[08:52] <whsieh_> johanneswilm: in the past it has not worked very well to try and standardize
[08:53] <whsieh_> smaug: someone from Blink/WK should comment on issue
[08:53] <whsieh_> 👀
[08:54] <whsieh_> whsieh_: expectations array
[08:55] <whsieh_> smaug: it's also a good way to document extantbehaviors
[08:56] <whsieh_> johanneswilm: resolution unchanged