getTargetRanges of beforeinput differ between browsers (should not happen in EditContext)
#146
Comments
|
@masayuki-nakano Editcontexts do provide the native selection. So why would this work differently than with contenteditable? |
|
As pointed out by @johanneswilm and as stated in https://w3c.github.io/edit-context/#edit-context-differences, the user agent will still handle selection and caret navigation in an EditContext. So I think it makes sense that |
|
My main point is about the cases deleting text from collapsed range. It requires a lot of computation to consider the range to delete even though web apps finally consider the behavior and the result is not consistent between browsers. See current test result. The amount how much the user wants to delete can be detected is notified by .inputType. In other words, if |
|
@masayuki-nakano Can you not wait with calculating the target ranges until the The exact ranges that a browser-provided target range covers will be OS/browser dependent as is also now the case. That's why we didn't specify it any further in the case of contenteditable, and I'm imaging in this case you can just run the same code that you are running for contenteditable to calculate them. Is that not the case? |
Good idea for the
I think that it does not make sense for web apps to use Even if browsers should return useful ranges for text deletion, I think that the spec should define the behavior clearly. E.g., word amount backward deletion at |
We can try to discuss this point again. Last time we concluded that it's just not possible as different platforms have different ideas about what should be the right target range. This seems like a general question related to I think that the target ranges are more important for some |
|
It sounds like the main problem here is lack of cross-browser interoperability of I don't think the EditContext spec needs to define how We do need to support The simplest approach in my opinion is to just keep The alternative is to go through each |
Actually, we received reports from JavaScript editors previously that they need this information as there can be platform dependent differences for things like deleting a word or line forward or backward that would require re-implementing a lot in JavaScript that is already in the browser. Looking at the way target ranges are used in an editor like CKEditor5 that is working mainly using the As this seems to be a general issue with target ranges, I will move this issue to the input events spec. |
johanneswilm
added
the
Agenda+
johanneswilm
changed the title
beforeinput on EditContext editing hostbeforeinput differ between browsers
|
(Sorry for the delay due to side-effects of vaccination) I do not agree with this point: In other words,
Oh, thank you for the information, if I got the STR, I'll fix it (or them). |
johanneswilm
changed the title
beforeinput differ between browsersbeforeinput differ between browsers (should not happen in EditContext)
|
Hey @masayuki-nakano, ok, I understand. You want all browsers to behave the same in EditContext but can live with the current state for contenteditable. I have changed the heading of this issue back to better cover your concern and tagged it to be discussed at next month's meeting.
I'm a bit confused here. As we can see in the CKEditor 5 source code, the existing target ranges in contenteditable are already in use today (with provisions made for a bug in Firefox that makes it return target ranges outside of the editable element at times). So given that this is actually being used in at least one of the major open production-level editors out there, why would it require a lot of work to make target ranges useful for actual usage?
The idea is here that if the target ranges are not the same right from the beginning, then JS editors will be written in a different way so that browsers converging later on will not work. Is that your concern? As someone working with CkEditor @Comandeer, is the differences between returned target ranges in different browser a concern for you? If so, is there an area in which standardization would be more useful than another? For The question is whether browser makers would be willing to return target ranges that are fully standardized even if that means breaking with the behavior of native apps in their OS/platform. This could especially be the case in scenarios involving text block merging and complex structures such as lists or tables. |
|
Looking around github for usages of
This could be an alternative solution for JS editor developers if they don't have |
Thank you very much!
I think that using same rules to compute About CKEditor 5, I guess that they don't refer the
So, my concern is about that web apps may use Previously, the result of
I think that the platform difference may just cause web-compat issues or increasing the code of web apps to get consistent behavior. I think that block merging etc should be handled by web apps itself in the So, I think that the necessary and simplest rules are:
Then, I guess that you do not need to struggle with this issue so long time.
Ah, using Selection API can check the word boundary etc, it's clever approach. However, Selection API is not cheap (runtime cost). Therefore, I'd be happy if they would stop using it with new APIs (I guess it never happens). |
Are the changes to the selection obtained by running |
In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32
In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32
In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018}
In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018}
In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018}
|
Sorry for the delayed answer.
It's not a big concern as we always validate the returned ranges and fix them ourselves if it's necessary. The more useful area would be "subcharacter" cases (I'll explain them below).
If they are consistent between browsers, than it sounds good to us. However, I looked into the Selection API spec and found that the smallest possible granularity is "character". How would it behave in cases where there are "subcharacters"? By that, I mean cases like "b̂" (so a letter with an additional accent). I've created a demo with that case. And the current behavior while deleting the content with a Backspace is quite inconsistent in browsers (tested on macOS 14.1):
We consider Firefox's behavior the right one. As for the |
|
Notes from 2023-11-09 Editing WG meeting:
|
|
@smaug---- @masayuki-nakano Given that EditContext will ship in Chromium without a flag in January (this has been merged already), do you think it would be preferable for it to return an empty array as from |
The way I understand you here, @masayuki-nakano , is that you want the target ranges to be the same in all browsers. It is my understanding that we wrote the spec in a way that is meant to not return the same target ranges in all browsers, but rather that the target ranges should correspond to the platform dependent behavior. @whsieh is that also your understanding? Is Webkit willing to give up on returning target ranges that correspond to the iOS/MacOS native behavior in order to return the same target ranges as Chromium and Firefox? If there is no new consensus that target ranges should now be the same across browsers, then I would strongly suggest that EditContext that will ship in Chromium returns the target ranges as required by the spec instead of returning an empty array for some input types. Otherwise it will not be spec compliant, as far as I can tell. |
We already have non-normative notes on this:
and
So I'm guessing the resolution we took then only means that these notes will be turned into part of the normative text of the specification. |
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojiichromium.org> Commit-Queue: Dan Clark <daniecmicrosoft.com> Reviewed-by: Anupam Snigdha <snianumicrosoft.com> Cr-Commit-Position: refs/heads/main{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818 UltraBlame original commit: e584836b1a351c801e83db73dcc453ad1a7f43ee
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojiichromium.org> Commit-Queue: Dan Clark <daniecmicrosoft.com> Reviewed-by: Anupam Snigdha <snianumicrosoft.com> Cr-Commit-Position: refs/heads/main{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818 UltraBlame original commit: e584836b1a351c801e83db73dcc453ad1a7f43ee
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojiichromium.org> Commit-Queue: Dan Clark <daniecmicrosoft.com> Reviewed-by: Anupam Snigdha <snianumicrosoft.com> Cr-Commit-Position: refs/heads/main{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818 UltraBlame original commit: e584836b1a351c801e83db73dcc453ad1a7f43ee
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Anupam Snigdha <snianu@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojiichromium.org> Commit-Queue: Dan Clark <daniecmicrosoft.com> Reviewed-by: Anupam Snigdha <snianumicrosoft.com> Cr-Commit-Position: refs/heads/main{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818 UltraBlame original commit: ea631482f94e2d8f8474753e35bff27fd67d3fce
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojiichromium.org> Commit-Queue: Dan Clark <daniecmicrosoft.com> Reviewed-by: Anupam Snigdha <snianumicrosoft.com> Cr-Commit-Position: refs/heads/main{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818 UltraBlame original commit: ea631482f94e2d8f8474753e35bff27fd67d3fce
…nges for deletions, a=testonly Automatic update from web-platform-tests [EditContext] Don't populate getTargetRanges for deletions In [1] the issue was raised that getTargetRanges() in beforeinput is not interoperable across browsers for deletions. We don't want to include non-interoperable behaviors in EditContext, so return an empty array for getTargetRanges() when beforeinput is received for deletions in EditContext. We may revisit this later on and start providing a range if interoperable behavior can be designed. [1] w3c/input-events#146 Bug: 999184 Change-Id: Iac697f89a7c7ecee57c850e7b929e42670c10e32 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4985470 Reviewed-by: Koji Ishii <kojiichromium.org> Commit-Queue: Dan Clark <daniecmicrosoft.com> Reviewed-by: Anupam Snigdha <snianumicrosoft.com> Cr-Commit-Position: refs/heads/main{#1217018} -- wpt-commits: 818b3f80df16e77a879749335b997cdc8223777b wpt-pr: 42818 UltraBlame original commit: ea631482f94e2d8f8474753e35bff27fd67d3fce
|
I believe that by returning an empty array as getTargetRanges instead of something like The point of target ranges was never to make all browsers return the same values. In fact, it was meant to allow to program text editors so that they would behave similar to native apps across platforms. Breaking from the spec is not improving this situation. Also, all inputTypes will have differing target ranges - not just those specific to deleting. They are not returning the exact same, as was never meant to be and is probably impossible to implement. |
make code point replacement normative, based on resolution on #146
|
Notes from 2023/12/14 WG meeting:
|
|
Notes from 2023/12/23 side call |
|
My point is, it's hard to define the rules of
However, according to the meeting log, editor app developers want only range(s) in text. I agree with the usage, but I cannot agree with fully implementing
In my understanding, editor app developers who don't want to use |
That must be a misunderstanding. No one requested to have target ranges only in text. It was merely said that there were certain cases when working within text nodes where it was extra important for
But has it not been implemented and shipped in Firefox already? I know there are a few bugs in Firefox'es current implementation, but are you suggesting to remove it altogether?
So what if the user has some content selected and then right clicks on a spell checking suggestion somewhere else in the DOM? For example: The user clicks on "teft" to change it to "test", but because "have selected" is selected, the result will be:
A few years ago, when we were still a taskforce, I was told that for good reason browser makers decided not to come to agreement on what constitutes a word, a sentence, a paragraph, etc. . Has this changed? If it has not, and there is no agreement in sight, then it's probably not a good to wait with EditContext until such agreement exists.
If there is agreement on where the word boundary is, this sounds like a good idea. But why not implement it uniformly also in contenteditable? It will be very confusing if getTargetRanges return something slightly differently in contenteditable/EditContext.
This sounds like it will make it a confusing API. I don't understand what the need for this is. |
Then the selection isn't collapsed, so getTargetRanges works like with contentEditable. |
|
Notes from discussion during today's Editing WG call:
|
No, I'm talking about (Although I'd really love somebody would consider the detail of
Ah, if the
I'm not sure the context, currently I think that all browsers support per-word deletion, therefore, I just used it for the example.
Why does it make the developers confused? In my understanding,
So, there is no definition for the node boundary cases.
I think that limiting the result range in text nodes makes the spec editors free from the mission impossible to define every edge case of |
|
The Web Editing Working Group just discussed The full IRC log of that discussion<johanneswilm> topic: target ranges and editcontext<johanneswilm> github: https://github.com//issues/146 <johanneswilm> It seems like there are different ideas about whether EditContext on a dom element should behave like contenteditable in that same browser or whether it should behave the same across browsers. |
|
The Web Editing Working Group just discussed The full IRC log of that discussion<dandclark> topic: getTargetRanges of beforeinput differ between browsers (should not happen in EditContext) #146<dandclark> github: https://github.com//issues/146 <dandclark> johanneswilm: Masayuki thinks EditContext should work the same for all browsers. Other browser makers say we should be able to follow conventions on specific platforms. <dandclark> ...: Spec currently says the second, should make it possible to follow conventions. Chomium implementation has removed target ranges and not yet put them back, going against the spec. <dandclark> smaug: getTargetRanges says that representing text that event will modify if event is cancelled. It's only about the text. It's unclear what target ranges represent if you press delete/backspace and there is no text <dandclark> johanneswilm: Why is it unclear? <dandclark> smaug: In the input events spec, getTargetRanges talks about just text, not nodes <dandclark> johanneswilm: yeah, text doesn't seem right, should it be the content? <dandclark> smaug: But there's no content if selection is collapsed <dandclark> ...: So it's a bit unclear now <dandclark> johanneswilm: What's the part that's not clear? It's not the selection, it's the part being affected <dandclark> ...: There's no problem of understanding in the implementations, no implementation has made it work only for text. But I agree the word 'text' there is not the best <dandclark> ...: Are we moving closer to anything? <dandclark> ...: Masayuki has different view vs Apple <dandclark> ...: Can't have both, either it's working the same across all browsers or it's making it possible to follow conventions <dandclark> smaug: have you heard feedback in Edge/Chromium <dandclark> johanneswilm: getTargetRanges is important, need to know which part of grapheme range to delete <dandclark> johanneswilm: Open source projects I know of are waiting until this has been resolved to build on this <dandclark> dandclark: I haven't heard feedback that pushes us in one way or another <dandclark> sanketj_: Will we realistically get interop here? <dandclark> johanneswilm: If all browsers return the same yes, but then we're removing this feature. <dandclark> ...: Won't return same target ranges across all browsers <dandclark> smaug: Interop should always be the goal in some way <dandclark> ...: But I understand there is this platform specific behavior. <dandclark> sanketj_: Does every browser do exactly what the OS wants on a given OS? <dandclark> johanneswilm: If I recall, whsieh said there's code in webkit that behaves differently in Windows, not supported anymore but in theory it's there. Question is whether Chromium does that. <dandclark> snianu: I made some changes in Chromium for word deletion for Windows. Behavior was not the same as other native apps like Word, Notepad. Did change some behavior that was Windows only <dandclark> johanneswilm: So we can say there's some level of that? <whsieh> Looks like Chromium still has this? https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/editing/editing_behavior.h <dandclark> ...: If there's some of that, then we will never get the same behavior <dandclark> sanketj_: Seems that way to me <whsieh> (the editing behavior is what I had in mind when I mentioned Safari/windows behavior before) <dandclark> sanketj_: Is the answer do nothing? Agree we can't standardize that part? <dandclark> johanneswilm: If we can't, then what's the consequence? I think we should follow the spec as is (re-add target ranges to Chromium) <dandclark> smaug: What's the minimum viable API that editors need? Can we achieve that in some other way? <dandclark> johanneswilm: Is proposal to only have target ranges for text certain changes. But the only thing we achieve is some editors need to have both contenteditable and EditContext around <dandclark> johanneswilm: This would make sense if we could eventually achieve interop. But otherwise seems we are cutting hole in feature unnecessarily. <dandclark> johanneswilm: Could we write something in spec so Firefox doesn't have to implement that part? <dandclark> smaug: That's immediately an interop issue <dandclark> johanneswilm: If you get target ranges you can funnel the platform conventions without knowing them <dandclark> smaug: On <canvas> target ranges won't work anyway <dandclark> johanneswilm: Can we get target ranges back, and then also have a list of the interop differences that we can track and knock down? Masayuki has done this in the past, let's do more. Some may be platform issues, some may be bugs. <dandclark> smaug: I will talk to Masayuki <dandclark> smaug: For <canvas> case they presumably already have code handling this <dandclark> johanneswilm: On <canvas> your document model doesn't need to follow logic of HTML document <dandclark> johanneswilm: So resolution is smaug will speak to Masayuki? <dandclark> sanketj_: Proposal is to keep target ranges in spec, let Chromium put them back, then Masayuki enumerates specific interop differences? <dandclark> johanneswilm: Yes, and we can't promise resources but will try to get browser makers to fix these where possible <dandclark> dandclark: SGTM |
|
The Web Editing Working Group just discussed The full IRC log of that discussion<dandclark> Topic: getTargetRanges of beforeinput differ between browsers (should not happen in EditContext)<dandclark> github: https://github.com//issues/146 <dandclark> smaug: Can someone look and confirm that browsers other than Firefox have different behavior on mac vs windows? <dandclark> dandclark: I can, if noone else gets to this <dandclark> smaug: I will keep pinging Masayuki for feedback <dandclark> whsieh: In webkit we use the selection range for most typing commands when editing <dandclark> whsieh: Not sure what getTargetRanges returns for transpose. Should probably return both? Because replacing both characters with swapped content <dandclark> johanneswilm: And they have to be next to each other |
|
Following up on this:
In Chromium there is an EditingBehavior class that centralizes a bunch of checks for editing functionality that differs by design between platforms. Picking one example from those, Word-breaking behavior deliberately differs in Chromium to follow platform conventions on Windows vs non-Windows. See SelectionModifier::NextWordPositionForPlatform or this CL. |
|
In Gecko, the behavior difference is not centralized, so, I cannot list all items up. However, as far as I know, the following things are different between platforms:
I don't know whether word breaker and/or grapheme cluster consideration depend on platform or not in some specific languages. |
|
The Web Editing Working Group just discussed The full IRC log of that discussion<sanketj_> Topic: getTargetRanges of beforeinput differ between browsers (should not happen in EditContext)<sanketj_> github: https://github.com//issues/146 <sanketj_> johanneswilm: Last update was that Olli asked for documented cases where browsers purposely behave differently on different platforms. <sanketj_> ...: Dan and Masayuki found cases where Chromium and Gecko behave differently. <sanketj_> johanneswilm: Does that convince us that we are always going to have differences? <sanketj_> smaug: Will follow up with Masayuki after this meeting. Couldn't do it before. |
|
The Web Editing Working Group just discussed The full IRC log of that discussion<dandclark> topic: getTargetRanges of beforeinput differ between browsers (should not happen in EditContext)<dandclark> github: https://github.com//issues/146 <dandclark> smaug: I think Masayuki is more positive on having getTargetRanges <dandclark> smaug: He's happy to expose the differences because platforms have different behaviors. That's how I interpret his statement on this. I will confirm. <dandclark> ...: Should I file new issue to add getTargetRanges? <dandclark> I to confirm with masayuki and reply |
Should it always return empty array? In my understanding, browsers do not manage selection range as deleting range in EditContext editing host. Therefore, I think that the range should be considered by the web apps themselves.
On the other hand, this example uses the result of
getTargetRanges...The text was updated successfully, but these errors were encountered: