I have a problem and I can't figure out what exactly is causing this behavior. I cannot access my input fields and textareas on my HTML form.
Unfortunately, the JS, HTML and CSS are very large, so I can't really post it all here.
Can anybody tell me what to look for when debugging this strange behavior?
UPDATE
If I move the cursor over the input field I can see the text cursor, but when I click it the field does not get the focus. I can access the field via pressing the Tab key and if I right click on it and then click on the field I also get the focus for it.
...and nope, they don't have the disabled or readonly attributes ;-)
when i click it the field does not get the focus. i can access the field via pressing the "tab-key"
It sounds like you've cancelled the default action for the mousedown event. Search through your HTML and JS for onmousedown handlers and look for a line that reads.
return false;
This line may be stopping you from focusing by clicking.
Re: your comment, I'm assuming you can't edit the code that adds this handler? If you can, the simplest solution is to just remove the return false; statement.
is there a way to just add functionality to the event-trigger by not overwriting it?
That depends on how the handler is attached. If it's attached using the traditional registration method, e.g. element.onmousedown, then you could create a wrapper for it:
var oldFunc = element.onmousedown;
element.onmousedown = function (evt) {
oldFunc.call(this, evt || window.event);
}
Since this "wrapper" doesn't return false, it will not cancel the default action (focusing) for the element. If your event is attached using an advanced registration method, such as addEventListener or attachEvent then you could only remove the event handler using the function name/reference and reattach it with a wrapped function similar to the above. If it's an anonymous function that's added and you can't get a reference to it, then the only solution would be to attach another event handler and focus the element manually using the element.focus() method.
I had this problem too. I used the disableSelection() method of jQuery UI on a parent DIV which contained my input fields. In Chrome the input fields were not affected but in Firefox the inputs (and textareas as well) did not get focused on clicking. The strange thing here was, that the click event on these inputs worked.
The solution was to remove the disableSelection() method for the parent DIV.
Use the onclick="this.select()" attribute for the input tag.
I know this is a very old thread, but this just happened to me recently; took me a while to figure it out.
This same issue can be caused by putting 'input' elements inside of pair of 'label' tags.
In my case, I had intended to create a pair of 'div' tags but instead I accidently created a pair of 'label' tags, then inserted some text input fields 'input type="text"..' using DOM.
It displayed normally on the screen, but when I clicked on any of the text fields, the cursor kept jumping back to the first 'input' and really acting erratic.
Took me a while to figure this out because this behavior is subtle, and not at all what I would have expected from making this kind of mistake.
bsnider
I've been struggling with the same problem a while ago. I was using the jquery.layout plugin in a modal jquery-ui dialog and I couldn't access any of the fields in it.
It appeared to be a z-index problem (some div was over my input fields, so I couldn't click them). You should check it out and try changing the z-index value of your input fields.
This happens sometimes when there are unbalanced <label> tags in the form.
I had this problem too, and in my case I found that the color of the font was the same color of the background, so it looked like nothing happened.
I have read all the answers above, and some directed me to the problem, but not to the solution for the problem.
The root cause of the problem is disableSelection(). It is causing all the problems, but removing it is not a solution, as (at least in 2016 or slightly before), on touch-screen devices, you "have" to use this if you want to be able to move objects with jQuery.
The solution was to leave the disableSelection() to the sortable element, but also add a binding action just above:
$('#your_selector_id form').bind('mousedown.ui-disableSelection selectstart.ui-disableSelection', function(event) {
event.stopImmediatePropagation();
})
The form in the jQuery element is just to stop propagation on the form, as you might need propagation on some elements.
This can occur in bootstrap if you do not place your columns inside a <div class ='row'>. The column floats are not cleared and you could get the next column overlying the previous, hence clicks wont hit the dom elements where you expect.
If you are faced this problem while using canvas with DOM on mobile devices, the answer of Ashwin G worked for me perfectly, but I did it through javascript
var element = document.getElementById("myinputfield");
element.onclick = element.select();
After, everything worked flawlessly.
I had the similar issue - could not figure out what was the reason, but I fixed it using following code. Somehow it could not focus only the blank inputs:
$('input').click(function () {
var val = $(this).val();
if (val == "") {
this.select();
}
});
For Anyone Using Electron
For anyone having this issue with Electron specifically, the problem for me was using alert before selecting the input fields. Apparently alert and confirm aren't entirely supported by Electron, and therefore can mess up input fields. If you'd still like to use them, refer to this post: https://stackoverflow.com/a/38859135/12293837
I had this problem because of this code:
$("#table tbody tr td:first-child").bind("mousedown", function(e){
e.preventDefault();
$(this).parents('tr').removeClass('draggable');
});
I resolved it by removing
e.preventDefault();
New code:
$("#table tbody tr td:first-child").bind("mousedown", function(){
$(this).parents('tr').removeClass('draggable');
});
Just in case someone else is looking for this answer, we had a similar problem and solved it by changing the z-index of the input tags. Apparently some other divs had extended too far and were overlapping the input boxes.
I had this problem for over 6 months, it may be the same issue. Main symptom is that you can't move the cursor or select text in text inputs, only the arrow keys allow you to move around in the input field. Very annoying problem, especially for textarea input fields. I have this html that gets populated with 1 out of 100s of forms via Javascript:
<div class="dialog" id="alert" draggable="true">
<div id="head" class="dialog_head">
<img id='icon' src='images/icon.png' height=20 width=20><img id='icon_name' src='images/icon_name.png' height=15><img id='alert_close_button' class='close_button' src='images/close.png'>
</div>
<div id="type" class="type"></div>
<div class='scroll_div'>
<div id="spinner" class="spinner"></div>
<div id="msg" class="msg"></div>
<div id="form" class="form"></div>
</div>
</div>
Apparently 6 months ago I had tried to make the popup draggable and failed, breaking text inputs at the same time. Once I removed draggable="true" it works again!
I'm using JQuery UI and Bootstrap so I faced this issue and I think it is a conflict between the two as in normal case the textarea or the input filed is editable by nature but I made this solution after testing all the above answers but none solve the cross browser support for all major browsers, but I solved it and I like to share my solution you can use it on input text and textarea
(Tested on Desktop: IE (All Versions), Chrome, Safari, Windows Edge, Firefox, Visual Studio Cordova Ripple Viewer on Windows & Visual Studio Cordova Windows 10 Store App)
(Tested on Mobile: Chrome, Firefox, Android Internet Browser & Visual Studio Cordova App on Android & Visual Studio Cordova Windows 8 + 8.1 + 10 Phone App)
This is the HTML Code:
<textarea contenteditable id="textarea"></textarea>
This is The CSS Code:
textarea {
-webkit-user-select: text !important;
-khtml-user-select: text !important;
-moz-user-select: text !important;
-ms-user-select: text !important;
user-select: text !important;
/*to make sure that background color and text color is not the same (from the answers above)*/
background-color:#fff !important;
color:#733E27 !important;
}
This Is The JQuery Code On Document Ready
$("textarea").click(function() {
setTimeout(function(){
$("textarea").focus();
//add this if you are using JQuery UI (From The Solutions Above)
$("textarea").enableSelection();
var val = $("textarea").val();
if (val.charAt(val.length-1) !== " " && val.length !== 1) {
alert(val.length);
val += " ";
}
$("textarea").val(val);
}, 0);
});
if (navigator.userAgent.indexOf('Safari') !== -1 || navigator.userAgent.indexOf('Chrome') !== -1) {
//alert('Its Safari or chrome');
$("textarea").onfocus(function(e) {
setTimeout(function(){
var end;
if ($("textarea").val === "") {
end = 0;
} else {
end = $("textarea").val.length;
}
if ($("textarea").setSelectionRange) {
var range = document.getElementById('textarea').createTextRange();
if (range) {
setTimeout(range, 0, [end, end]);
} else { // IE style
var aRange = document.getElementById('textarea').createTextRange();
aRange.collapse(true);
aRange.moveEnd('character', end);
aRange.moveStart('character', end);
aRange.select();
}
}
e.preventDefault();
return false;
}, 0);
});
}
You can test it on my web application at www.gahwehsada.com
When you say
and nope, they don't have attributes: disabled="disabled" or readonly ;-)
Is this through viewing your html, the source code of the page, or the DOM?
If you inspect the DOM with Chrome or Firefox, then you will be able to see any attributes added to the input fields through javasript, or even an overlaying div
I just found another possible reason for this issue, some input textboxes were missing the closing "/", so i had <input ...> when the correct form is <input ... />. That fixed it for me.
In my case it was Bootstrap popup in opened state.
Text input was in another calendar popup on top of Bootstrap one, input got its focus back after removing tabindex="-1" attribute from Bootstrap modal.
iPhone6 chrome
Problem for me was placing the input field inside <label> and <p>
like this :
<label>
<p>
<input/>
</p>
</label>
I changed them to
<div>
<div>
<input/>
</div>
</div>
And it works for me .
After check this answer, Please check other answers in this page, this issue may have different reasons
Its worth adding that having the property pointer-events:none on your input label will also produce this unwanted behaviour.
It might be because of invalid for attribute in the label attribute
<input type="text" id="your_name" name="your_name">
<label for="your_name">Your Name</label>
<input type="text" id="your_email" name="your_name">
<label for="your_name">Your Name</label>
I have tried to update the for attribute in the second label to your_email instead of your_name and its works for me
<label for="your_email">Your Name</label>
This will also happen anytime a div ends up positioned over controls in another div; like using bootstrap for layout, and having a "col-lg-4" followed by a "col-lg=8" misspelling... the right orphaned/misnamed div covers the left, and captures the mouse events. Easy to blow by that misspelling, - and = next to each other on keyboard. So, pays to examine with inspector and look for 'surprises' to uncover these wild divs.
Is there an unseen window covering the controls and blocking events, and how can that happen? Turns out, fatfingering = for - with bootstrap classnames is one way...
I had the same problem. I eventually figured it out by inspecting the element and the element I thought I had selected was different element. When I did that I found there was a hidden element that had z-index of 9999, once I fixed that my problem went away.
the problem for me was that I was using class="modal fade", I changed it for class="modal hide". That solved the issue.
I had the same problem. Tore my hair for hours trying all sorts of solutions. Turned out to be an unclosed a tag.Try validate your HTML code, solution could be an unclosed tag causing issues
I had this issue using Bootstrap + contact form 7.
I for some reason I put the label as the container of the form and that was the issue for not being selectable on mobile.
<label>
<contact form>...</contact form>
</label>
Seemed to break all inputs except the first input and the submit.
I had the same issue and the fix was to remove the placeholders and I changed the design of the form to use labels instead of placeholders...
I had this issue caused by a sort of overlap of a div element with a bootstrap class ="row" over a "brother" div element with the class="col", the first hid the focus of the second div element.
I solved taking outer the div row element from that level of the divs' tree and so rebalancing bootstrap logical hierarchy based on the row and col classes.
I had this same issue just now in React.
I figured out that in the Router, Route. We cannot do this as it causes this issue of closing the mobile keyboard.
<Route
path = "some-path"
component = {props => <MyComponent />}
/>
Make sure and use the render instead in this situation
<Route
path = "some-path"
render = {props => <MyComponent />}
/>
Hope this helps someone
Daniel
Related
I have a simple chunk of code that I'm trying to make keyboard accessible while using the NVDA screen reader.
Specifically, I have a div with a role of "button", with another div with another role of "button" nested inside it. Each div has a different onkeydown event that gets fired when the user tabs to that div, and presses "enter".
This keyboard functionality all works as desired when I don't have the NVDA screen reader turned on.
When I do have the screen reader turned on, however, the nested keydown event no longer fires. Instead, just the parent event fires even when the nested event is one that has focus.
However, if I manually change NVDA out of "browse mode" and into "focus mode" (By pressing the NVDA key + spacebar), then the key events work as desired again.
Unfortunately, it's not acceptable for me to expect someone using NVDA to know to make the manual switch to "focus mode". It either needs to change to "focus mode" automatically, or it needs to work in "browse mode."
Here's the code:
HTML:
<div role="button"
tabindex="1"
onkeydown="keyEvent(event, outerDivAction)"
class="outerDiv">
Outer Div
<div role="button"
tabindex="1"
onkeydown="keyEvent(event, innerDivAction)"
class="innderDiv">
Inner Div</div>
</div>
<div class="result"></div>
JavaScript:
function outerDivAction(event) {
event.stopPropagation();
console.log('outer div');
$('.result').html('<p>outer div!</p>');
}
function innerDivAction(event) {
event.stopPropagation();
console.log('inner div')
$('.result').html('<p>inner div!</p>');
}
function keyEvent(event, callback) {
event.stopPropagation();
if (event.which === 13) {
callback(event);
}
}
$('.outerDiv').click(outerDivAction);
$('.innderDiv').click(innerDivAction);
You can also view a codepen here: http://codepen.io/jennEDVT/pen/Yprova
Any help that anyone can offer would be greatly appreciated!
p.s.
I know that if I take the nested div and move it so that it's no longer nested, but is rather a sibling of the first div, then everything works as desired. Unfortunately that's not an option. The div needs to be nested.
This is not a bug in NVDA.
First of all, you cannot have nested clickable elements. Specifically, you cannot have nested interactive content. You cannot nest links and you cannot nest buttons. You cannot nest links in buttons, and you cannot nest buttons in links. There are other kinds of interactive content worth looking into for future reference too.
You may find that your code is technically valid, but that is only because what you have written is a fib.
Instead of using the correct element (<button>) you have chosen to put role=button on <div>s. An HTML validator would pass your code because it is valid to nest <div>.
However, by giving them each role=button, you have instructed the user agent to treat them as <button> (minus all the benefits that come with them, like accessibility, key handlers, semantics, etc.).
Now let's go back and validate that code again as a user agent would see it (as nested <button>s). The W3C Nu HTML checker would fail it (I know because I ran a test):
Error: Start tag button seen but an element of the same type was already open.
My suggestion is:
to not nest them,
convert them to <button>s,
remove the invalid tabindex=1 (which you would not need),
remove the check for the key code as the <button> gives you that for free (including character 32),
make your <div class="result"> into an ARIA live region (there are some tips here),
and put a wrapper around the buttons to give you the visual effect you want.
Sample rejiggered code:
<div class="wrapper">
<button class="outerDiv">
Outer Div
</button>
<button class="innderDiv">
Inner Div
</button>
</div>
<div class="result" role="alert" aria-live="assertive"></div>
If it may interest you, the WAI-ARIA Authoring Practices (APG) has guidance on how to make various design patterns accessible. It also includes one on what you’re describing: Menu or menubar which includes code examples for menus with submenus.
Trying to accomplish the above result with jquery.googleSuggest.js is giving me a lot of trouble as can be seen here. Some of the original CSS of jquery UI seems to be shining tough. Anyone any hints on the most elegant way to fix this? (And how to add the grey "gle", after "goo" behavior in the screenshot above?)
HTML
<div class="suggestions_box">
<ul>
<li>f<b>acebook</b></li>
<li>f<b>unda</b></li>
</ul>
</div>
JS
var div = $("<div>").appendTo("#inputs")
, input = $("<input>").appendTo(div);
input.googleSuggest({ service: "web" });
Your custom css in the linked fiddle is creating problems. Removing all the css and adding external jquery-ui.css makes the dropdown appear correctly (as seen in this fork of your fiddle).
Basically, you only need:
// html placeholder for the input
<div id="inputs"></div>
and
// js init code
var input = $("<input>").appendTo($("#inputs"));
input.googleSuggest({ service: "web" });
Also, your other question has already been answered in this thread: How to implement a google suggest-like input field? It's a neat trick accomplished by overlaying two input fields one above the other one, with the lower one disabled and set to the value of first suggested entry.
I created a contentEditable div with a text portion and a link. Double clicking the link will select the link text.
<div contentEditable="true">
This is a text and This_is_a_link
</div>
Afterwards calling document.getSelection().getRangeAt(0).startContainer will return the div:
// => <div contenteditable="true">
Instead of the link. I cannot find a way to find which part of the div is selected.
See this jsfiddle (double click the "This_is_a_link" and there will be a console log with startContainer):
http://jsfiddle.net/UExsS/1/
(Obligatory JS code from the fiddle)
$(function(){
$('a').dblclick(function(e) {
setTimeout(function() {
console.log(window.getSelection().getRangeAt(0));
}, 500);
});
});
Note, that Chrome has the correct behavior, and running the above jsfiddle in Chrome will give textElement for startContainer.
Has anyone run into this issue? did you find a workaround?
Don't think its a bug of Firefox, just a different kind of implementation. When you double click the link, Firefox selects not only the text, but the whole a-tag, so the parent node of the selection is correctly set to the div container.
I added these few lines of code to your fiddle to proof that point:
var linknode = window.getSelection().getRangeAt(0).commonAncestorContainer.childNodes[1];
console.log(linknode);
console.log(window.getSelection().containsNode(linknode, false));
Forked fiddle: http://jsfiddle.net/XZ6vc/
When you run it, you'll see in the javascript console that linknode contains your link, and the check if the link is fully contained in the selection returns true.
This is also one possible solution to the problem, albeit not ideal one. Iterate over all the links in your contenteditable and check if one of them is fully contained in the selection.
Though one word of advice: Don't reinvent the wheel if you don't have to ;-) There's quite possibly some libraries / frameworks out there that fit your needs.
I've got the following list item:
<li>
<input value="someRadioButton" name="ctl00$mainContent$group" type="radio"
id="ctl00_mainContent_somelRadioButton" onclick="showSomeInfo()" />
<label for="ctl00_mainContent_someRadioButton">
<img class="extraPadding-Right-10" src="https://xxy.com/some_mark_37x23.gif" />
</label>
</li>
So what shows up is a radio button and an image next to it. When I am in FireFox, Chrome, and Safari clicking on that image fires the showSomeInfo() that's specified in the radio's onclick. I'm not sure why I guess because it's wrapped in a label and that label is relating to that radio button....
But anyway that's not my problem. I like that when you click the image, that javascript method showSomeInfo() is called. But the problem is that it works in all browsers except IE 8. If I open this page in IE 8, clicking on the image does nothing and I'm not sure why. I'm baffled at this one.
I was looking for an answer to this and wrote a quick dirty jquery handler for it:
$("label").click(function(){
if ($(this).attr("for") != "")
$("#" + $(this).attr("for")).click();
});
There's a slightly cleaner approach to change the markup that doesn't involve (ugly) CSS hacks or Javascript; change the <img> tag to a <span> tag with a background-image of the appropriate size. For example:
<li>
<input value="someRadioButton" name="ctl00$mainContent$group" type="radio"
id="ctl00_mainContent_somelRadioButton" onclick="showSomeInfo()" />
<label for="ctl00_mainContent_someRadioButton">
<span class="extraPadding-Right-10" style="background-image: url(https://xxy.com/some_mark_37x23.gif); width: 100px; height: 100px; display: inline-block" />
</label>
</li>
Replacing the width and height of your image appropriately.
The reason it works the way it does in Firefox et al is that that's what <label> is supposed to do when it's got a "for" attribute that points to an input field (by "id" value). If it doesn't work that way in IE, it's because Microsoft either interpreted the standard differently or simply failed to implement it correctly. (I don't see any clear language in the w3c reference I found to stipulate whether anything but text content of a label should get focus and transfer it.)
I've also discovered that if you have a hidden input with display:none or visibility:hidden and are relying on the label for selection it will not work in ie8.
My workaround was to have an overflow:hidden on the containing element and position the input outside of this area.
I Guess I have a better hack solution for this problem.
I will explain why for first.
Using jquery to hit the label click works, but not when you are using an Input File, because you will receive access denied.
Using css and display the image as a background it´s not good too because you need to have an image with the exactly size, which is not the case when the user uploads the Image or you have a lot of images with different sizes.
Ok now I´ll explain the idea of the hack:
You have a Label with an image inside, when you click the image, IE8 doesn´t fire the Label. But if you write some text into the Label, when you click the text IE8 fire the label.
The Idea is to put a span inside the label, with the size of the label (width and height)
Ok but if you don´t have text inside it won´t work, but if you change the background color it will work.
So what you need to do is:
Place a Span with the role size of the Label
Write a background color and make it transparent
Position the Span using relative position to put the Span exactly over the Label.
It´s a little hard to do it, but I guess it will cover many more situations.
An example of a Label firing the Input type File:
<label for="" id="lblInput" style="cursor: pointer; z-index:3;">
<img src="../Imagens/SemPerfil.jpg" ID="imgFoto" Style="max-width: 280px; max-height: 180px;z-index:2;" />
<span style="position:relative;
top:-180px;display:block;height:180px;width:280px;
z-index:1;background-color:Aqua;
-ms-filter:'progid:DXImageTransform.Microsoft.Alpha(Opacity=1)';
background: rgba(255, 255, 255, 0.0);" >
</span>
</label>
I hope it works and save you Like it saved-me
Are you sure you aren't simply looking at a typo?
Check "ctl00_mainContent_someRadioButton" vs. "ctl00_mainContent_somelRadioButton"
It looks like IE doesn't properly handle labels with img elements in them. The only reasonable ways I have been able to find for dealing with this problem are either using HTML component behaviors, Javascript handlers, or CSS hacks. I haven't tried all of these so I can't guarantee that they will work.
I tried some of the other solutions posted here and eventually amended them to get a working fix to your problem. My problem was similar, though the HTML looked a little different, with the LABEL tag wrapping both the image and the INPUT radio button.
The solution I include below will ensure that any onClick handlers fire correctly on the radio button itself. It also does this only once and not in browsers where the radio button label behaves normally.
This is the jQuery code I used to solve the problem in Internet Explorer 11:
$('LABEL > IMG').click(function () {
var inputId = $(this).parents('LABEL:first').attr("for");
if (inputId) $('#' + inputId).not(':checked').attr('checked', true).click();
});
The code above uses the jQuery method attr() to manipulate the checked property. If you're using jQuery 1.6 or higher you should modify this to use the jQuery method prop() instead.
This works for me with a group of radio inputs followed by labels containing an image. Basically used it instead of using for attribute in all browsers
inputs.each(function() {
$(this).click(function (e) {
// do stuff ...
});
// adding click handler to label containing image
$(this).next().on('click', function(event) {
// prevent 'for' attribute firing
event.preventDefault();
// check and trigger click on input
$(this).prev().prop("checked", true).trigger('click');
});
});
I'm trying to create a couple of buttons above a textarea to insert some HTML code -- a VERY poor-man's HTML editor. I have a couple of INPUT elements, and I'm using jQuery to set a click handler that will call's jQuery's append() or html() or text() functions.
The handler fires, it shows a debug alert(), but the text I'm trying to append doesn't show up in the textarea. When I inspect the textarea in Firebug, I see the text I'm appending as a child of the textarea -- but it's dimmed, as when an element's style is set to display:none. But Firebug's CSS inspector doesn't show any change to the display or visibility properties.
When I set the click handler to 'append()', and then click multiple times, in Firebug I see the text being added over and over again -- but each new chunk is still invisible. If I choose 'Edit HTML' in Firebug and then type some chars next to the appended text, the entire text block -- the text added by jQuery and the stuff I added in Firebug -- suddenly appear.
This also happens if I don't use a click handler, but call my append function using an inline handler like onclick="javascript:insert('bold');"
Anyone have any idea why the appended text is not displayed?
Here's the relevant code:
The HTML:
<input type='button' id='bold' value='B' onclick='javascript:insert("bold")' />
<textarea name='PersonalGreeting' id='PersonalGreeting'>default text</textarea>
The Javascript:
function insert( cmd ) {
switch ( cmd ) {
case 'bold':
$('#PersonalGreeting').append('<b>bold text here</b>');
break;
}
}
I would guess that jQuery is trying to append HTML DOM elements to the textarea.
Try using the val method to get and set the textarea's value, like this:
$('#PersonalGreeting').val($('#PersonalGreeting').val() + '<b>bold text here</b>');
The basic problem is that you can't put HTML inside a <textarea>. In fact, you can't append HTML elements to one at all. You could use the .val() method to change the text shown inside, but that won't make it bold. That will just make it have <b> showing as part of the text.
An off-the-shelf WYSIWYG editor like TinyMCE is free and easy to implement. Rather than reinvent the wheel (which is a lot harder than it might look), try an existing wheel out.
SLaks and VoteyDisciple are correct. You're usage of append is faulty as you are perceiving it as a string function.
From http://docs.jquery.com/Manipulation/append
Append content to the inside of every
matched element. This operation is the
best way to insert elements inside, at
the end, of all matched elements. It
is similar to doing an appendChild to
all the specified elements, adding
them into the document.
Reinventing the wheel on this one is likely more headache than its worth unless this is an attempt to create a superior, competing product or for your own experimentation.
Also, I would shy away from use of obtrusive JavaScript as you have shown in your example with onclick='javascript:insert("bold")' embedded in the input element. Instead, you'll have a more elegant solution with something like the following:
HTML
<input type="button" value="B" class="editor-command" >
<input type="button" value="I" class="editor-command" >
<input type="button" value="U" class="editor-command" >
JavaScript (not tested)
$(document).ready(function() {
var textarea = $('#PersonalGreeting')
$(".editor-command").each(function(i, node) {
textarea.val(textarea.val() + '<$>text here</$>'.replace(/\$/g, node.value);
});
});
If the main issue is the textarea not being visible, I would try this:
$('#PersonalGreeting').append('<b>bold text here</b>').show();
Might be worth a shot.
edit: In the vain of not trying to reinvent the wheel, I've had success with WYMEditor
You could do this:
$('#PersonalGreeting').append('[b]bold text here[/b]');
But that won't actually render the text as bold. To be honest I'm not actually sure how to render text as bold inside a textarea, I imainge some js trickery.