Member Avatar for shadiadiph

I have a div that the user can edit problem is when I select the div the initial cursor is always the same height as the div??? Also if i enter no text and click on it i have to leave the div and click before I can enter the div again????

HTML

<div id="editabletxt" name="editabletxt" contenteditable="true"></div>

CSS

#editabletxt{   
 width:560px; 
 height:100px;
 line-height:20px;
 display:block;
 overflow:auto;
 outline: 0px solid transparent;
 word-wrap: break-word;
 text-align:left;
 font-size:80%;
 font-weight:normal;   
 background:#fff;
 -moz-border-radius: 10px;
 -webkit-border-radius: 10px;
 border-radius: 10px;    
 border: 1px solid #dbe1e6;
 padding:4px 4px 4px 4px;
}
  • 1 Contributor
  • 3 Replies
  • 444 Views
  • 19 Hours Discussion Span
  • Latest Post Latest Post by shadiadiph

Dani AI

Generated

Short answer for : this is a cross‑engine quirk — Firefox has historically drawn either a full‑height block caret or no visible caret when a contenteditable element is empty (there’s no text line box to anchor a normal caret), while WebKit/Chromium and IE handle empty editors differently. This was reported as a Firefox regression. (bugzilla.mozilla.org)

Two reliable, practical fixes that avoid the “giant caret” and the “no caret until you type” behaviours:

  • CSS placeholder trick (no DOM changes): add a zero‑width character via a :empty pseudo so the editor is never truly empty:

    [contenteditable]:empty:before {
content: "\200B"; /* zero‑width space */
display: inline;
}

    This forces a line box so the caret draws normally. (stackoverflow.com)

  • Programmatic caret placement: on focus create a Range and collapse it to the start/end so a real caret is created (works when browsers don’t paint a caret until selection exists):

    function placeCaretAtEnd(el){
el.focus();
var r = document.createRange();
r.selectNodeContents(el);
r.collapse(false);
var s = window.getSelection();
s.removeAllRanges();
s.addRange(r);
}

    This approach is cross‑browser. (stackoverflow.com)

For the IE wrapping / double‑spacing issues, prefer the modern properties and predictable line metrics: use overflow-wrap: break-word (alias word-wrap: break-word for older IE), set white-space: normal, and prefer min-height rather than forcing a fixed height so empty editors still produce a text line. (developer.mozilla.org)

Cautions: pseudo‑element tricks can create odd blank lines in some IE versions (test IE11), and if you insert a ZWSP in the DOM remove it on first real input to avoid invisible characters. If problems persist, initialize the editor with a single <br> or programmatically insert/remove a placeholder on focus/blur. (stackoverflow.com)

Member Avatar for shadiadiph

i only seem to be getting the big caret issue in mozilla in ie google chrome it is ok.
one issue i have in ie is with the word wrap it gives a double line space without it it is fine. in mozilla without word wrap the text doesn't break into lines at all??

I think IE shouldn't be allowed to be sold to anyone lol

Member Avatar for shadiadiph

Fixed almost everythin already by trial and error the only problem I have now is in mozilla it can't find the initial cursor position properly and it is the entire height of the div when you first select it??

Edited by shadiadiph because: n/a
Member Avatar for shadiadiph

Ok I got it almost working only a few issues now.

1) when i clcik in the editable area in chrome there is no initial caret (cursor) until I type something.
2) On mozilla and seamonkey the caret (cursor) initially appears to be the same height as the div until I type.

Any ideas??

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.