Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce in-Textarea highlighting #162

Open
garretthyder opened this issue Jul 6, 2018 · 4 comments
Open

Introduce in-Textarea highlighting #162

garretthyder opened this issue Jul 6, 2018 · 4 comments
Assignees

Comments

@garretthyder
Copy link
Collaborator

This ticket will house the efforts for introducing in-Textarea highlighting for spaces, terms and other items.

Originally the idea stems from this GlotPress issue;
GlotPress/GlotPress#863

This is quite an involved implementation as we'd probably have to retrofit the textarea with a complimentary div which visually replaces the textarea to support highlighting.
We could potentially use a library like this - https://codersblock.com/blog/highlight-text-inside-a-textarea/

Some ideas for what should be highlighted in the text area are;

  • highlight ending space
  • highlight non-breaking space
  • highlight glossary terms with click replace
  • highlight … with click replace
  • etc

In some cases such as the term highlight and the trailing ... highlight we can take advantage of the 'Fix Warning' functionality being built for 1.5 in #145 so that on-click those highlights can execute replace logic.

@garretthyder garretthyder added this to the 1.7 milestone Jul 6, 2018
@garretthyder
Copy link
Collaborator Author

garretthyder commented Jul 6, 2018

We may want to look at the Grammarly extension to get some ideas as they have a really nice in-textarea highlight with tooltip that contains replace actions.
card_correct

@garretthyder
Copy link
Collaborator Author

There's also the 'contenteditable' path as mentioned on GP ticket GlotPress/GlotPress#166

@Mte90
Copy link
Owner

Mte90 commented Jul 10, 2018

If we can use a library is better to have less custom code untested a lot but we will find something :-)

@garretthyder
Copy link
Collaborator Author

Agreed a library is going to be best, hopefully something lightweight.
We'll want to avoid WYSIWYG editors and maybe contenteditable now that I look at it more since both support injecting markup (Bold, Italics, etc) which affects the integrity of the string as we shouldn't be injecting markup that's not already present.

@vlad-timotei vlad-timotei removed this from the 1.8 milestone Sep 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants