Open devlzl opened 2 months ago
As another person responsible for a text editing solution, but not someone who uses an hidden textarea. As far as I know the major reasons I am excited about EditContext are not relevant to you. Here are the remaining ones I can think of:
@DavidMulder0 Thank you for your reply.
Regarding the first point you mentioned, I think we can implement this ourselves. For example, during the compositionupdate
event, we can mark the data to render underlines. I'm not entirely clear about where you see thin/thick underlines, wavy lines, normal lines
appearing. As far as I know, only IMEs show a simple underline during input. Where do other styles of lines appear?
For the second point, this is actually a concern with EditContext. Historically, different browsers have had inconsistent behaviors with execCommand
, and currently, different browsers may have inconsistent selections with window.getSelection().getRangeAt()
. However, EditContext is only implemented in Chrome at the moment. Not to mention, we don’t know if or when Safari or Firefox will implement it, and if so, whether their implementations will be consistent.
Regarding the third point, I agree. Since I have almost no experience with editing on Android, the hidden textarea might indeed not solve the problem very well.
@devlzl is the source for the project you are referring to available online? From the things I have tried it is very difficult to get anything using custom rendering to have access to the IME features correctly without limiting what is rendered to what the browser can natively do or making an editing mode that shows a standard input/textarea. If this is possible, even to get close I would love to see the source code and work on a polyfill to use until the other browsers support this API.
@talltyler Sorry the code I'm referring to is not open source, but could you please list the limitations you encountered?
In my production code I'm working around the issue with an editing mode with a normal textarea that is hidden after editing. I would like to have input and selection rendered in the canvas so that there isn't a jump between the two modes that visually look different but because I've not gotten what you are talking about working I don't have a list for you.
When I've tried using a hidden input I've had difficulty with connection between what is selected and what is rendered and how to place the hidden field so that the IME shows up in the correct space because of the differences in what is rendered.
With any of this I'm also unsure how multibyte characters like emojis or Arabic scripts pair with the concept of selection ranges in strings. I can break the string input into glyphs and graphemes to render but pairing this with selection ranges in strings seems like it could get off. I can maybe see how a system could work to constantly reevaluate between the two could work but then someone enters an IME and a character that was a simple 'o' is now transformed into 'œ' or something. While doing this I've seen issues with key events between browsers and trying to handle the differences between keyboard input, IME changes and keyboard shortcuts unrelated to the field you are in.
There must be ways around this stuff, and I would love hints or links if you have them but also lots of these topics are pretty deep and I welcome new APIs or libraries that wrap up even small parts of this.
I am a developer of a rich text editor engine. I would like to know more about the advantages of EditContext API compared to
contenteditable
orhidden textarea
.I know that using contenteditable directly on the DOM to implement a rich text editor can lead to inconsistent data and unpredictable behavior. So I now use a hidden textarea. I get user input by listening to
beforeinput
,compositionstart
/compositionend
and update my own text model and selection model, then render them. At the same time, by modifying the position of thetextarea
element, I make the IME window appear in the appropriate position. Even when I use canvas to implement 3D art text input, I can also receive input text through a hidden textarea and then render it on the canvas.So as of now, I'm not sure what significant benefits the EditContext API can bring me compared to hidden textarea?