minutes, Editing WG call May-9-2024

<sanketj_> Sanket Joshi present+
8:01 AM → whsieh joined (~whsieh@e2f177d0.publics.cloak)
8:02 AM D<dandclark> Dan Clark present+
8:02 AM C<comandeer> Tomasz Jakut present+
8:03 AM S<sanketj_> Sanket Joshi Topic: TPAC 2024 participation
8:03 AM github: https://github.com/w3c/editing/issues/462

8:03 AM G— github-bot OK, I'll post this discussion to https://github.com/w3c/editing/issues/462 (TPAC 2024 participation).
8:03 AM S<sanketj_> Sanket Joshi johanneswilm: Scheduled for Thursday of TPAC week. Please leave comments/thoughts.
8:03 AM ...: estimated 8 people attending
8:03 AM W<whsieh> present+
8:04 AM S<sanketj_> Sanket Joshi smuag: Do we need to figure out conflicts with other WGs?
8:04 AM johanneswilm: Following historical precedence. Thursday/Friday has had least conflicts and some people want to leave on Friday.
8:05 AM Topic: normative spec changes do not always end up as issues filed with browsers
8:05 AM G— github-bot Successfully commented on https://github.com/w3c/editing/issues/462

8:05 AM S<smaug> s/smuag/smaug/
8:05 AM S<sanketj_> Sanket Joshi github: https://github.com/w3c/editing/issues/463

8:05 AM G— github-bot OK, I'll post this discussion to https://github.com/w3c/editing/issues/463 (normative spec changes do not always end up as issues filed with browsers).
8:05 AM → snianu joined (~snianu@e2f177d0.publics.cloak)
8:06 AM S<sanketj_> Sanket Joshi johanneswilm: Apple didn't get notified about a change made in spec. Apple was in attendence, but is there any process improvement we can make to better notify?
8:06 AM ...: Please comment in issue.
8:06 AM wshieh: Will follow up with Marcos as well.
8:06 AM Topic: Specify order of flavors exported to macOS's pasteboard
8:06 AM G— github-bot Successfully commented on https://github.com/w3c/editing/issues/463

8:07 AM S<sanketj_> Sanket Joshi github: https://github.com/w3c/clipboard-apis/issues/137

8:07 AM G— github-bot OK, I'll post this discussion to https://github.com/w3c/clipboard-apis/issues/137 (Specify order of flavors exported to macOS's pasteboard).
8:07 AM S<sanketj_> Sanket Joshi snianu: Not sure has changed since last discussion.
8:08 AM ...: Chromium has fixed order. Order determined when clipboard item created. Order preserved when writing to clipboard.
8:08 AM ...: Not sure if it is possible to standardize order of formats written to clibpoard.
8:09 AM ...: On Windows, there is some historical precedence from legacy apps.
8:09 AM ...: May be different orders are needed on different platforms.
8:11 AM sanketj: Last time we discussed we wanted to find out order from each browser. Chrome and Firefox seem to do different things, not sure if can be reconciled without compat problems.
8:11 AM smaug: Doesn't Safari write based on author order?
8:11 AM S<snianu> my zoom client crashed
8:11 AM S<sanketj_> Sanket Joshi snianu: Sounds right. But we may have to leave it up to the UA. Possibly based on platform.
8:12 AM smaug: Does Chromium have fixed order, regardless of author choice?
8:12 AM sanketj: Chromium has fixed order, seems to be written in that order on all platforms.
8:13 AM wshieh: List is order of fidelity? Highest to lowest?
8:13 AM sanketj: Yes.
8:13 AM ⇐ snianu quit (~snianu@e2f177d0.publics.cloak)
8:13 AM S<sanketj_> Sanket Joshi wshieh: Similar concept on Mac/iOS with Webkit, but we go with the developer's ordering choice.
8:14 AM wshieh: MacOS documentation also old. Points to older APIs.
8:14 AM johanneswilm: Are we likely to get agreement on a behavior across browsers here?
8:14 AM smaug: Not sure if not possible or no strong opinion.
8:14 AM ...: May need investigation from all browsers.
8:15 AM → snianu joined (~snianu@e2f177d0.publics.cloak)
8:15 AM S<sanketj_> Sanket Joshi sanketj: There is risk with making these changes. Is it worth doing?
8:15 AM johanneswilm: How would this make things better?
8:15 AM smaug: Just consistency.
8:16 AM johanneswilm: Spec already mentions you can't rely on the order.
8:16 AM smaug: Depends on what native apps choose.
8:17 AM johanneswilm: Let's set this aside for further investigations from other browsers?
8:17 AM smaug: Why does Chromium have the current order?
8:17 AM snianu: Not sure why fixed order was chosen.
8:18 AM ...: Do want consistent order of formats between DataTransfer and async clipboard API.
8:19 AM ...: Different order between copy/paste and async clipboard API may lead to inconsistent copy/paste for users.
8:19 AM ...: OS like Windows specify higher fidelity formats go on top.
8:20 AM sanketj: Doesn't Windows spec mention order?
8:20 AM ⇐ snianu quit (~snianu@e2f177d0.publics.cloak)
8:20 AM S<sanketj_> Sanket Joshi snianu: Windows spec doesn't specify exact order, but says highest fidelity format should go on top.
8:21 AM ...: Risk is that if the authors provide a different order, then that isn't respected.
8:21 AM ...: Changing browser orders carries risk of copy/paste issues since native apps hard to change.
8:22 AM sanketj: Can someone post in the issue to confirm the active web dev impact? Original issue seems to be a Firefox bug that fixed a long time ago.
8:23 AM johanneswilm: If someone can help take this further, let us know. If not, let's move on until there is more info.
8:24 AM Topic: event order proposal when inserting replacement text such as text prediction, spell checker, etc.
8:24 AM G— github-bot Successfully commented on https://github.com/w3c/clipboard-apis/issues/137

8:24 AM S<sanketj_> Sanket Joshi github: https://github.com/w3c/input-events/issues/152

8:24 AM G— github-bot OK, I'll post this discussion to https://github.com/w3c/input-events/issues/152 (event order proposal when inserting replacement text such as text prediction, spell checker, etc.).
8:24 AM D<dandclark> Dan Clark sanketj_: This came up when we were implementing writingSuggestions
8:24 AM ...: Edge & Safari, the set of events we fired caused compat issues
8:25 AM ...: Came out of discussion with Marcos where we should be more clear about where events are fired. That's what Siye is trying to do.
8:25 AM ...: Beforeinput, input should be fired
8:25 AM ...: Composition events should not be fired
8:25 AM ...: Problem is not unique to writingSuggestions. There's autocomplete...
8:25 AM ...: Can we have the same pattern for all of them?
8:25 AM johanneswilm: I don't understand what the issue is. The order is specified in UI events
8:26 AM ...: Doesn't specify that there's no composition, but specifies this is not part of a composition
8:26 AM ...: I take that as implying there will be no comp events
8:26 AM sanketj_: May be worth clearing up when a suggestion or correction is accepted, these rules are followed
8:26 AM ...: Not clear if that should be here or in HTML spec
8:26 AM johanneswilm: The order of these events is in UI events spec
8:26 AM ...: I thought that's pretty clear
8:27 AM sanketj_: Does it call out they should be fired when autocomplete, autofill is accepted?
8:27 AM johanneswilm: Probably written in different way.
8:27 AM ...: is part of the issue that Apple didn't implement which events should come out of this?
8:27 AM sanketj_: Easy for bugs to be introduced if this is not specified somewhere
8:28 AM smaug: I think it's clear in spec. *reads spec text*
8:28 AM sanketj_: Does it say these need to be fired when something is accepted?
8:29 AM snianu: When you type in android by default, it goes through composition. When you type in site, if browser supports spellcheck, then <missed>. If you type on virtual keyboard it also shows spelling suggestions. On android every keystroke comes through composition
8:29 AM johanneswilm: But that' smore of an androib bug
8:29 AM s/androib/android
8:29 AM ...: If you have keyboard and it's not communicating that it's spellchecking change, browser has no way of knowing.
8:30 AM sanketj_:For that case that's where inputType comes in, you should get insertReplacementText
8:30 AM sanketj_: The main thing is just we should make it clear that when one of these things are accepted, we should fire these events.
8:30 AM ...: Spec just says insert or replace text. Calls out type.
8:30 AM johanneswilm: Event order is in UI events, no?
8:31 AM sanketj_: Yes
8:31 AM sanketj_: Maybe somewhere in one of these specs, we should make it expicit that when suggestions are expected, these events get fired and composition events do not get fired
8:31 AM johanneswilm: Not against it, slightly afraid it's just due to lack of communication about the change
8:31 AM ...: But we can adjust it if it's not totally clear
8:32 AM ...: Should go into UI events
8:32 AM ...: I would be for having event order in same spec, but given we moved it out for everything else, keyboard typing etc, should be in UI events
8:32 AM ...: Maybe move the issue there, have them add it to spec where it seems reasonable
8:32 AM sanketj_: OK
8:32 AM johanneswilm: So all the event orders are in the same spec
8:33 AM sanketj_: Right. The other benefit is implementation-wise, once this is specced it can be forcing function to create common implementation. Rather than every time you invent one of these things you have to reconsider all this.
8:33 AM johanneswilm: Who will file it with UI events?
8:33 AM sanketj_: I'll follow up with Siye and he will take care of it
8:33 AM S<sanketj_> Sanket Joshi Topic: getTargetRanges of beforeinput differ between browsers (should not happen in EditContext)
8:33 AM G— github-bot Successfully commented on https://github.com/w3c/input-events/issues/152

8:34 AM S<sanketj_> Sanket Joshi github: https://github.com/w3c/input-events/issues/146

8:34 AM G— github-bot OK, I'll post this discussion to https://github.com/w3c/input-events/issues/146 (getTargetRanges of `beforeinput` differ between browsers (should not happen in EditContext)).
8:34 AM S<sanketj_> Sanket Joshi johanneswilm: Last update was that Olli asked for documented cases where browsers purposely behave differently on different platforms.
8:34 AM → snianu joined (~snianu@e2f177d0.publics.cloak)
8:34 AM S<sanketj_> Sanket Joshi ...: Dan and Masayuki found cases where Chromium and Gecko behave differently.
8:35 AM johanneswilm: Does that convince us that we are always going to have differences?
8:35 AM smaug: Will follow up with Masayuki after this meeting. Couldn't do it before.
8:35 AM Topic: Need to specify which input types are handled by EditContext
8:35 AM G— github-bot Successfully commented on https://github.com/w3c/input-events/issues/146
8:35 AM S<sanketj_> Sanket Joshi github: https://github.com/w3c/edit-context/issues/94

8:35 AM G— github-bot OK, I'll post this discussion to https://github.com/w3c/edit-context/issues/94 (Need to specify which input types are handled by EditContext).
8:36 AM ⇐ snianu quit (~snianu@e2f177d0.publics.cloak)
8:36 AM S<sanketj_> Sanket Joshi dandclark: Issue is about which input types should be handled by EditContext
8:36 AM ...: Ie. which which input types should change the text store and fire the textchange event
8:37 AM ...: Unhandled types don't reflect in text store or event dispatch, authors need to handle this on their own
8:37 AM ...: Chromium implement 5 of them (see issue)
8:37 AM ...: Ask from last time was to inventory and check if there are any missing/incorrect ones.
8:38 AM ...: Mostly right. insertTranspose is probably one that we should handle.
8:38 AM ...: Not great interop on this one. Chromium and Safari use different names, and Firefox doesn't seem to implement.
8:38 AM ...: However, should probably still include this in the supported list.
8:39 AM ...: Similar caveat about deleteContent. Lack of interop.
8:39 AM ...: In any case, deleteContent should also be added to the supported list.
8:39 AM D<dandclark> Dan Clark https://w3c.github.io/input-events/#event-type-beforeinput

8:40 AM S<sanketj_> Sanket Joshi ...: Propose that list of supported commands should be in the EditContext spec. EditContext dispatch conditions, based on input types, should go into input events.
8:41 AM johanneswilm: Is there an input type in Chromium called "transpose"?
8:41 AM dandclark: It is an execCommand.
8:42 AM johanneswilm: Input types prefixed so that JS can clearly tell what happened and can be handled differently.
8:42 AM ...: If really there is an input type that is not prefixed, that's a bug and should be fixed.
8:42 AM ...: But execCommand may be different.
8:43 AM dandclark: That's right. transpose is just the execCommand name. Input type for input event is insertTranspose.
8:43 AM ...: Seems to only be invokable via execCommand
8:43 AM johanneswilm: Is there not a keyboard shortcut?
8:44 AM dandclark: Not sure.
8:44 AM ...: In any case, input type does exist and anything that invokes that input type should be supported by EditContext.
8:44 AM ...: Missed adding this earlier.
8:45 AM johanneswilm: Sounds good.
8:45 AM ⇐ whsieh quit (~whsieh@e2f177d0.publics.cloak)
8:45 AM S<sanketj_> Sanket Joshi smaug: What about insertFromPasteAsQuotation? Supported in Firefox.
8:46 AM dandclark: Copy/paste and clipboard related commands not included.
8:46 AM johanneswilm: Will we explain what is supported and how they were chosen?
8:46 AM dandclark: We can spec the fixed list and add some explanatory spec that describes the criteria used.
8:46 AM johanneswilm: Sounds good to me.
8:47 AM johanneswilm: Resolved to accept Dan's proposal.
8:47 AM Topic: foo
________________________________
New messages
8:47 AM G— github-bot Successfully commented on https://github.com/w3c/edit-context/issues/94