[Minutes] Editing WG - 10/8/2023

smaug> scribe: smaug
6:05 PM issue https://github.com/w3c/editing/issues/430
6:05 PM johanneswilm: let's remove from the agenda and let the discussion happen in the issue
6:06 PM issue https://github.com/w3c/edit-context/issues/38
6:07 PM dandclark: What happens when an editing host is associated with an EditContext?
6:07 PM which one should win?
6:08 PM <smaug> smaug: I agree that EditContext should win
6:10 PM johanneswilm: I did some testing. If you associate an EditContext with editing host, you do get all the input events
6:12 PM smaug: so you get input events in both places. But how do you handle them
6:12 PM johanneswilm: you'd handle formatting events in editing host
6:15 PM dandclark: for just typing editing host gets all the events and EditContext events too
6:17 PM smaug: so is the DOM modified when user types?
6:18 PM wenson: maybe this is similar to some other cases when beforeinput event is fired but there is no dom modification
6:19 PM smaug: ok, so it is only beforeinput event which is dispatched
6:20 PM <whsieh> present+
6:21 PM <smaug> resolution: EditContext wins, also editing host gets beforeinput
6:21 PM issue: https://github.com/w3c/edit-context/issues/53
6:22 PM "Event firing and editability for nested editable elements"
6:23 PM dandclark: Children inherit editability, but they aren't editing hosts, except if nested one sets contenteditable=false and then enable again 
in nested nested element
6:24 PM dandclark: So should only editing host get beforeinput when associated EditContext?
6:25 PM dandclark: and nestedly enabling contenteditable should be no-op
6:26 PM johanneswilm: makes sense
6:27 PM johanneswilm: There may be few cases when selection moves to unexpected places
6:29 PM whsieh: what if EditContext is bound to something under editing host?
6:29 PM dandclark: EditContext would do nothing
6:30 PM whsieh: is editing host defined somewhere?
6:32 PM dandclark: we need two kinds of editing hosts. Something where user input does change DOM, but with EditContext there are no DOM changes
6:33 PM dandclark: EditContext spec could clarify this
6:33 PM <dandclark> Dan Clark https://w3c.github.io/edit-context/#edit-context-differences
6:35 PM <smaug> dandclark: everyone, please review the relevant parts of the spec
6:35 PM johanneswilm: this needs to be clear also on input event side
6:36 PM johanneswilm: I'll take a look at the input events spec
6:36 PM dandclark: EditContext is monkey patching the input events spec
6:40 PM resolution: behavior is defined by the top level editable root
6:41 PM contenteditable=false does still reset editability
6:43 PM dandclark: editing events don't leak out from inner editable areas
6:43 PM issue: https://github.com/w3c/edit-context/issues/54
6:43 PM "Can we remove TextFormat.textColor?"
6:44 PM dandclark: IME may want to format the text
6:44 PM dandclark: textColor is one of those
6:45 PM dandclark: most of the the event doesn't inform about the expected color
6:46 PM dandclark: there was a plan to have a OS level feature, but it hasn't been implemented
6:47 PM dandclark: so, remove until there is a use case, and if added back later, make sure it is clear to devs when/how to use it
6:48 PM whsieh: one motion was also Mac's touchbar
6:49 PM johanneswilm: what about using EditContext with canvas?
6:49 PM dandclark: canvas should still get beforeinput
6:52 PM smaug: there are other properties too, like backgroundColor
6:53 PM dandclark: they do have similar issues too
6:55 PM whsieh: I think removing them and adding them back later is the way to go
6:56 PM dandclark: remove textColor, and as a followup action item I'll check whether there are use cases for other properties
6:57 PM resolution: see above ^
6:58 PM johanneswilm: would be good to clarify some issues before W3C TPAC
6:59 PM ...if you don't want me to decide the whole agenda, propose some,  via email

Received on Thursday, 10 August 2023 16:17:05 UTC