I'm trying to make something like gist.github.com but with MathQuill so you can easily type text and math. But i've run into a few problems.
A single editable math field (span) where you can type math and switch to text mode with a keyboard shortcut Shfit + T. Javascript will capture the keypress event and execute mathField.cmd('\\text');. You can then use the arrow keys to move in and out of text and math mode. Seems perfect, unfortunately this acts like a "input" and not a "textarea" so you can't press enter and jump to a new line. And it doesn't seem like changing from span to textarea just breaks everything.
So seeing the first method didn't work out, I added a content editable div and you can switch to math mode with a keyboard shortcut Shift + E. Javascript will capture the keypress event and insert the html <span id="stdin"></span> into the div and run MathQuill on it. Unfortunately this is extremely buggy when it comes to moving the cursor around and just annoying to deal with. Also i'm not sure if setting multiple mathquill fields is possible (I haven't tried it yet)
I want to stick with the first method since it's simple and works just the way I want it to. But I don't know how to change it from the "input" style to "textarea".
Does anyone know how to do this?
Related
I have a ContentEditable div that I'm using to try to make a WYSIWYG editor (using Chromium 83)
The problem is that when hitting enter to make a new line it's really inconsistent with what it inserts into the div, which causes the cursor to act really weird when pressing Up or Down.
For example when you press Up it sometimes jumps halfway up the page for no apparent reason, and other times it just jumps up to the nearest div tag that it can find, instead of just moving 1 line up.
My question is what can I do, either by handling enter presses or changing something about the editor div, to make the cursor just move up and down line by line like a regular text editor? (even if the line is blank)
It seems like wrapping every line in a div would work, and that's what Chrome is supposed to do by default, but when spamming enter Chrome only inserts a div tag sometimes.
I've tried:
Inserting a unicode "newline" character on enter (which breaks the native WYSIWYG editing, for example pressing enter won't carry on a list or clear formatting)
Changing the default paragraph separator to <p>, still only places them randomly, not every line
Inserting a <br> on enter press, only places it once
Manually inserting <div></div> tags, doesn't work
Executing document.execCommand("insertLineBreak")
And all of these either don't work at all or still cause the cursor to jump up to random places in the editor when pressing Up or Down. I just want it to move up and down 1 line like regular text editors.
I even see this happen in modern WYSIWYG editors that I found online, and can't find a fix anywhere.
Any help appreciated
Edit:
I went and posted this question on the Chromium-Dev google group, and the post editor for Google Groups (the old version, not sure about the "new look" editor) shows the behavior that I'm looking for, so if anyone knows how that works that might help
Edit 2:
Someone on Reddit referred me to ProseMirror and it's a very well-behaved WYSIWYG editor and I ended up using that for my project.
I have a web page with an odd behavior on part of it.
On most of the page, the input tags work just the way one would expect.
Here's an input tag I put in to test:
<input name="vanilla1" value="vanilla" />
In one part of the page, I can click on the field to edit it, but only at the front of the field. So, if the input tag had a value of "vanilla", I could click in front of the "v" and start typing or deleting. But it won't let me click between the two "l" characters and start typing.
It's not easy to just post a full working sample, I would have to retype by hand a lot of code.
If I wanted to get that behavior I don't have a clue of how to do it.
Any ideas of what to look for that might cause this?
It's obviously not disabled or readonly because I can edit it.
When I inspect the problem input tags in the IE DOM explorer, they don't look any different from the input tags that work as expected.
There's javascript, html, angularJS and dojo, plus the esri gis api css libraries in the technical mix.
A few more observations:
In IE, when I click on a working input tag that already has a value in it, I get a little X show up on the far right of the input box. If I click on the X the field is blanked out. On my problem input tags, when I click on them, I get the X but clicking the X does not work. So I appear to be accessing the right object.
When I inspect the object, everything looks normal. No javascript events attached, it's not read only or disabled.
Isn't it like covered by another node or something like that?
Did you check it in all browsers or only in IE?
Try to open Chrome DevTools and click the "Select an element in the page to inspect it" (top left corner of the DevTools window, CTRL + Shift + C shortcut on Windows) and hover over that input. See if there's possibly any element that may cover it. If there's - voila! Remove that overlay and you're good to go. If not - I don't have any ideas for now.
I am trying to make it possible to insert text at the current caret location in a text field when clicking something on the page.
In order to make this work the focus should not leave the text field when clicking, and the caret should not be moved.
I can get this working in - for instance - chrome with event.preventDefault() in the mousedown event.
But in internet explorer I simply cannot make this work. Any suggestions welcome.
Clarification: I am trying to provide some good means for the users to input exotic characters that can not be entered directly from their keyboard.
I have implemented for instance ctrl+alt+p which works well in all browsers, except internet explorer where I cannot stop the default behaviour of pressing ALT (activating the menu bar).
I have then made a "palette" of the characters next to the field, that can be clicked with the mouse while typing. This works well in all browsers, except internet explorer where I cannot prevent the default blur-behaviour of a mouseclick.
Maybe this is a dead conversation but I have a solution.
For IE specifically look into the onbeforedeactivate event. You will want to attach this to the the element you want to keep focus. It's a bit tricky because if you always cancel this event you can never loose focus on this element but if you're careful how you implement it you can achieve what you want.
I've been doing this for a while now with nice clean results.
Don't do this
I suggest you don't do this, because keeping (or better said returning focus) caret in text field will also prevent users from changing browser's address bar which is something you don't want..
I suggest you rather explain your process more detailed and maybe we can suggest a better alternative.
After some clarification
What you should do is insert text/character at caret position. input and textarea preserve caret position even when they loose focus. So you should do something similar to what stackoverflow does here. When you select some text (when you type question/answer) and then click B icon on top, two stars are added around selected text. This is how you should do your special character insertions. When user clicks a perticular exotic character, that character should be added/inserted at input's caret position.
There are quite a few stackoverflow questions related to solving this exact problem - adding text at caret position:
How to insert text at the current caret position in a textarea
How do I insert a character at the caret with javascript?
Setting (or Reading) value of Cursor/Caret in HTML TextArea
Inserting text at cursor in a textarea, with Javascript
Insert text on the current place of the cursor in the browser
...
I am using Firefox to do this but it works in IE6 ... go figure.
Basically I have code written to traverse a grid of input elements using arrow keys. All of that is working just fine. I can move freely to any field using the arrow keys. When I use up or down arrows the select function seems to work correctly by selecting all text in the next field. (desired result)
document.getElementById(id).select();
However when I traverse left or right the text seems to be using a default browser function to move the cursor once to the left or right after the select happens forcing the user to select all the text again (undesired result).
Is there a way to disable that in firefox so my text gets selected correctly? The typical workflow for my users is to just hit the arrow key then start typing numbers ...then repeat.
I'd say this behavior is caused by the keyup event. Did you try to stop it?
edit: yep, works fine when keyup event is cancelled : http://jsfiddle.net/D6ANY/1/
From your description, it seems to me that you are trying to achieve a "spreadsheet" like effect. If thats the case, then the behaviour you are implementing could confuse users. e.g. in spread sheets the selection moves with arrow keys for each cell but if you have to edit a cell, you need to hit the enter key. That makes it editable and then hitting the enter key again will make it read-only
This is a 2 part question:
1)
click on one of the demo dropdowns on this page. when you tab over to the next input, the text is selected/highlighted in firefox. how can i prevent this from happening?
2) bonus: can you review my code that is hosted on google and tell me what i can improve?
Well, that is just default behavior on Firefox. A possible workaround is to have the input fields execute a JavaScript or jQuery function on select, have the function blur the field (which would deselect the text) and then refocus on the field. Very basic and I'm sure it'd need a couple extra hacks. Unfortunately without scripting, no there is nothing you can do to prevent that.
I honestly recommend that you leave it alone. That functionality was put in place so you wouldn't have to use your mouse when typing into forms, hitting tab would select all the text so you can easily retype it or hit the right arrow key to go to the end of the field. Removing the functionality will only irritate some of your visitors. If they're using the tab key to get to the next field, they probably want that functionality.