RE: [EXTERNAL] meeting on target ranges and EditContext

Notes from today's call:

8:10 AM johannesmilm: Apple may not be willing to change native behavior and position may be that they don't want to converge, need Apple position confirm
8:11 AM johannneswilm: Masayuki (Firefox) has different position
8:11 AM smaug: Canvas important case, platform behavior not applicable there
8:11 AM smaug: Do you need EditContext at all if you basically want contenteditable capabilities?
8:12 AM smaug: getTargetRanges unreliable in any scenarios
8:12 AM johannneswilm: Canvas scenario was top off mind when this API was first designed
8:13 AM johannneswilm: JS editors want browsers to do selection, ex. CodeMirror
8:14 AM johannneswilm: JS editors want DOM based editing but their own model and can handle DOM changes themselves
8:14 AM smuag: Why do they need EditContext then?
8:15 AM johannneswilm: IME integration is important
8:15 AM johannneswilm: EditContext much better at handling IME, no need to dance around IME as with contenteditable
8:15 AM johannneswilm: Huge source of pain previously
8:16 AM johannneswilm: Have been working towards this solution for over 10 years
8:17 AM johannneswilm: getTargetRanges are needed for a variety of operations to work correctly, deletions, insertReplacementText, spellcheck
8:17 AM johannneswilm: Spec needs to be updated, it's actually opposite to what Chromium implements
8:17 AM smaug: How so?
8:17 AM johannneswilm: Inputevents spec requires editing host to specify what target ranges should be
8:18 AM smaug: If canvas is host, no target ranges. Other cases, may be different. That is not defined.
8:18 AM johannneswilm: Not sure about spec, but two totally different cases.
8:18 AM smaug: Still needs to be defined
8:19 AM johannneswilm: getTargetRanges should apply to all cases, not just deletion
8:19 AM smaug: Agree, that's what is confusing. The cases are really different, some are handled by the browser and some not.
8:20 AM johannneswilm: Agree that does probably need to be specified.
8:20 AM johannneswilm: Target ranges is not selection though, those two aren't necessarily connected
8:20 AM johannneswilm: Ex: Replacing word with spellchecker, selection may be somewhere else
8:21 AM smaug: Can be used to denote focus via empty range
8:21 AM johannneswilm: If the EditContext or input events spec doesn't say, we should say this: In the case of Canvas, no target ranges should be returned.
8:22 AM daniec: Agree that needs to be specified, but that shouldn't mean other cases shouldn't have this case
8:22 AM daniec: Only way for authors to plug into native spellchecker
8:22 AM daniec: getTargetRanges need to work for non canvas cases
8:23 AM sanketj: Agree with that
8:23 AM johannneswilm: Specific reason for getTargetRanges vs. different API is that getTargetRanges can to sub character specificity
8:23 AM johannneswilm: Not possible with selection API for example
8:24 AM johannneswilm: Behaves differently on Mac
8:24 AM smaug: Does it behave differently on Mac or just Firefox?
8:25 AM johannneswilm: Mac specific behavior, non normative note in spec that on some OS behavior works this way
8:25 AM johannneswilm: Also says that browsers may have different behaviors
8:25 AM johannneswilm: Alternatively, engine would need to maintain list of grapheme clusters and behave differently on each OS
8:26 AM smaug: How would this be possible on Canvas? Need consistency in implementation.
8:26 AM dandclark: When using Canvas, authors take the responsibility of managing more functionality on their own
8:27 AM dandclark: That's why non Canvas case is important
8:27 AM dandclark: Canvas only for really large editors
8:27 AM dandclark: Smaller editors would still benefit from non Canvas support of EditContext
8:27 AM johannneswilm: Agree
8:28 AM johannneswilm: Why would we disallow getTargetRanges just for deletion?
8:28 AM smaug: Intent is just to have compatible behavior.
8:28 AM smaug: All implementations should behave the same, especially given that this is a new API.
8:29 AM smaug: Perfect time to fix the old mistakes, where implementations are inconsistent.
8:29 AM dandclark: If getTargetRanges can be fixed for contenteditable, that would be delightful, but I don't see a path to doing that.
8:29 AM dandclark: API explicitly accounts for platform differences
8:29 AM dandclark: Not really a path for cross-platform consistency
8:30 AM dandclark: If can't get there for contenteditable, EditContext behavior needs to have slightly different
8:30 AM dandclark: EditContext behavior can still be interoperable
8:31 AM smaug: Really hard to fix contenteditable, so shouldn't we try to fix EditContext?
8:31 AM dandclark: Not so much about the browser, the OSes would have to change, that's really hard
8:31 AM johannneswilm: JS Editors would love if OSes could agree, but seems unlikely
8:32 AM johannneswilm: Target ranges was built the way it was to get around these OS differences, since OSes want web apps to behave similar to native apps
8:32 AM johannneswilm: Goal of those designing this wanted that as a goal as well
8:32 AM johannneswilm: Fixing the API would go against that original goal
8:33 AM johannneswilm: Wanting web apps to behave like native apps still seems to be position for companies that control the OS
8:33 AM smaug: Lots of test failures in getTargetRanges in all browsers
8:33 AM johannneswilm: Behavior is already very different
8:34 AM smaug: Some web tests may not be testing what spec says
8:34 AM smaug: Point is implementations are doing different things
8:35 AM johannneswilm: Some cases may be just be browser bugs, but other cases may be spec compliant but behave differently on different platforms
8:35 AM johannneswilm: Happy to look into tests if that helps
8:35 AM johannneswilm: Would be a good exercise to look at getTargetRanges and find cases where things don't look right
8:35 AM johannneswilm: Some cases may need more specification
8:36 AM johannneswilm: Still don't see how getTargetRanges can behave the same everywhere
8:36 AM smaug: Can we specify the cases where OS behavior is different?
8:36 AM smaug: Other cases should be tested and specified properly
8:37 AM johannneswilm: Looked into this last year for web compat for contenteditable standardization, gets complex very quickly
8:37 AM johannneswilm: Likely means we won't have getTargetRanges for a long time, because a lot of cases to get sorted out
8:38 AM smaug: But this would be the best time since EditContext is brand new and its a point in time where we can think about interoperability
8:39 AM johannneswilm: Other editing behaviors may still be standardizable, don't think getTargetRanges can be
8:39 AM johannneswilm: JS editors do special things with contenteditable behaviors on other platforms too
8:40 AM johannneswilm: Because browsers kept changing and sites were breaking, JS editors started relying on getTargetRanges
8:40 AM johannneswilm: Likely to continue
8:40 AM smaug: Shouldn't ideally work that way
8:40 AM smaug: We really want compat and interop
8:41 AM dandclark: Unfortunately, doesn't seem possible here.
8:41 AM dandclark: EditContext is not making this worse.
8:41 AM smaug: This is best time to fix it though.
8:42 AM johannneswilm: Have had a continuous stream of issues for getTargetRanges for several years, but no success fixing them so far
8:42 AM johannneswilm: Spent a long time discussing these issues and browsers made some changes, but hard to get everything in place in a timely manner
8:42 AM johannneswilm: Editors don't want to wait for a long for EditContext to work for them
8:43 AM dandclark: +1
8:43 AM dandclark: Doesn't seem worth it to delay EditContext in favor of fixing getTargetRanges
8:43 AM smaug: Can we at least define behavior for getTargetRanges?
8:43 AM smaug: May be doable without caring about legacy.
8:44 AM smaug: Very different from contenteditable, because compat considerations. Existing editors may break with contenteditable.
8:44 AM smaug: Not true for EditContext, it is brand new.
8:44 AM dandclark: See getTargetRanges not as a new API, but an old API that already has a lot of history
8:45 AM johannneswilm: What should we do?
8:45 AM johannneswilm: Can getTargetRanges work with EditContext the same way they do for contenteditable?
8:45 AM smaug: Spec unclear for canvas case
8:45 AM dandclark: Yes, but not unclear for non canvas cases
8:45 AM johannneswilm: Can update spec for canvas case
8:47 AM smaug: EditContext seems quite complex for JS editors
8:47 AM johannneswilm: JS editors doing DOM changes themselves anyways, takes away complexity around IMEs
8:48 AM johannneswilm: Tried in the past to isolate IME operations from contenteditable, didn't work out on Android
8:48 AM johannneswilm: EditContext + input events seems like the most plausible solution
8:50 AM smaug: Spec not clear about mapping from DOM to EditContext position
8:51 AM dandclark: Spec may need updates, but developer needs to define mapping model
8:51 AM dandclark: Developer in control with EditContext, may have different behaviors depending on their own editing model
8:52 AM smaug: Curious is Apple has had web compat issues around this
8:53 AM johannneswilm: Editors are based on getTargetRanges
8:53 AM johannneswilm: There are real pain points for JS editors with this API.
8:54 AM smaug: JS editors have to work around issues and therefore browsers get compat bugs.
8:54 AM johannneswilm: That's why having getTargetRanges behaving reasonably is important.
8:55 AM johannneswilm: In the past, impossible to change contenteditable, now may be possible without breaking editors, because editors are more browser agnostic with their model
8:56 AM smaug: Still there are cases where things can be broken
8:56 AM smaug: I'd like to discuss with Masayuki
8:57 AM smaug: More optimistic about sticking to existing getTargetRanges behavior for EditContext after this conversation
8:57 AM johannneswilm: What resolution is EditContext looking for?
8:59 AM dandclark: Looking for agreement that current text spec is fine for non canvas cases
9:00 AM dandclark: Sooner we get agreement here the better, since EditContext has shipped in Chromium
9:01 AM smaug: I'll discuss with Masayuki and get back on our position.
9:02 AM johannneswilm: Dan or I will update spec for canvas case.


From: Johannes Wilm <mail@johanneswilm.org>
Sent: Friday, December 15, 2023 12:13 PM
To: public-editing-tf@w3.org
Subject: [EXTERNAL] meeting on target ranges and EditContext

You don't often get email from mail@johanneswilm.org<mailto:mail@johanneswilm.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hey,
please note that we have an extra call next week, December 21st, same time as always (1600 UTC) with same connection link as normal, to discuss issue https://github.com/w3c/input-events/issues/146 .

Time permitting, we might also discuss other EditContext issues with an Agenda+ tag: https://github.com/w3c/edit-context/labels/agenda+

Feel free to start discussing the issue in the github issues before the meeting.
--
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org<https://www.johanneswilm.org/>