Der Bearbeitungscursor wird in Chrome in contenteditable nicht angezeigt
Lesezeit: 7 Minuten
Wenn Sie diese Seite öffnen (s Live-Demo) mit Chrome:
<span id="myspan" contenteditable=true></span>
CSS:
#myspan { border: 0; outline: 0;}
JS:
$(myspan).focus();
das contenteditablespan hat Fokus (Sie können anfangen, Dinge zu schreiben und Sie werden sehen, dass es bereits Fokus hatte), aber wir sehen nicht das “I“Cursor bearbeiten.
Wie kann man dafür sorgen, dass dieser Cursor angezeigt wird? (Anmerkung : outline:0 benötigt wird, sowie die Tatsache, dass die Spanne auch ohne Leerzeichen leer ist).
Hinweis: Bei Firefox wird der Cursor angezeigt.
Versuchen Sie, eine Mindestbreite und eine Mindesthöhe anzugeben. Ein leerer Bereich hat eine gerenderte Breite und Höhe von Null, sodass nicht wirklich mit der Maus darübergefahren werden kann. Indem Sie eine Größe von wenigen Pixeln erzwingen, gibt es etwas, über das Sie mit der Maus fahren können.
– Woodrow Barlow
17. September 2014 um 18:36 Uhr
Vielleicht hilft dir diese Antwort auf eine andere Frage weiter: [stackoverflow.com/a/6249440/3298029][1] [1]: stackoverflow.com/a/6249440/3298029
@vee inline-block wird das Problem in Chrome nicht beheben.
– ich bin der Mann
23. Juni 2016 um 19:08 Uhr
das ist seltsam, es hat bei mir in Chrome Version 51.0.2704.103 (64-Bit) gut funktioniert. Vielleicht liegt es daran, dass ich auch Bootstrap verwendet habe? Verwenden block macht das eigentlich span verhalte dich wie ein div.
– Allee
24. Juni 2016 um 4:09 Uhr
Ein bisschen mehr Erklärung: Das liegt daran, dass Inline-Elemente zusammenbrechen 0 width ohne Inhalt, während Blockelemente dies sind 100% Breite standardmäßig. Deswegen inline-block Elemente sind ebenfalls von demselben Problem betroffen.
– Lukas
23. September 2016 um 14:30 Uhr
Das Problem ist nicht das span ist inlineEs ist das inline Elemente haben eine Breite von 0 wenn sie keinen Inhalt haben. Die Lösung besteht also darin, sicherzustellen, dass dem Element eine gewisse Breite gegeben wird, was hinzugefügt wird display: block; zufällig tut.
– Lukas
8. Oktober 2018 um 19:07 Uhr
Lukas
Ich habe links Polsterung hinzugefügt und der Cursor erscheint.
Vielleicht, weil die leere Spannweite eine Breite von hat 0. Wenn der Cursor erscheinen muss Innerhalb das Element, dann gibt es einfach keinen Platz dafür, es sei denn, Sie geben ihm eine Art Polsterung. Das ist zumindest nur eine Vermutung
– KyleMit ♦
17. September 2014 um 20:17 Uhr
Ich hatte ein anderes Spiel und Hinzufügen display: block und das Entfernen der anderen Zusätze funktioniert auch: jsfiddle.net/gs3p1a6r/10 Es scheint, dass Inline-Elemente ohne Inhalt nicht von betroffen sind min-width?
– Lukas
17. September 2014 um 20:19 Uhr
Aleksej Dubinsky
.cont_edit {
outline: 1px solid transparent;
}
Können Sie eine jsfiddle bereitstellen oder die Antwort in ein Code-Snippet umwandeln? Nützlich für zukünftige Referenzen. PS: Ich bin nicht derjenige, der runtergestimmt hat!
– Basj
10. Mai 2016 um 10:10 Uhr
Musste diese UND-Anzeige verwenden: block plus make both attribute !important wegen anderer widersprüchlicher CSS auf meiner Seite
– Turkinator
31. Oktober 2017 um 14:44 Uhr
KyleMit
Das hat eben mit der Art und Weise ein Leerzeichen zu tun ContentEditable Bereich gerendert wird. Um zu beweisen, dass es nicht um den Fokus geht, fügen Sie Ihrem bearbeitbaren div etwas Text hinzu und löschen Sie ihn dann. Wenn das letzte Zeichen weg ist, verschwindet der Cursor
Aus der Frage Festlegen der Caret-Position auf einen leeren Knoten innerhalb eines contentEditable-Elements
Das Auswahl-/Bereichsmodell basiert auf Indexen in den Textinhalt, wobei Elementgrenzen außer Acht gelassen werden. Ich glaube, dass es unmöglich sein kann, den Eingabefokus innerhalb eines Inline-Elements ohne Text zu setzen. Sicherlich kann ich bei Ihrem Beispiel den Fokus nicht auf das letzte Element setzen, indem ich auf oder die Pfeiltasten klicke.
Es funktioniert fast, wenn Sie jede Spanne auf einstellen display: block, obwohl es immer noch ein höchst seltsames Verhalten gibt, das von der Existenz von Leerzeichen im übergeordneten Element abhängt. Das Hacken der Anzeige, um mit Tricks wie Float, Inline-Block und Absolute Position inline auszusehen, führt dazu, dass IE jedes Element als separates Bearbeitungsfeld behandelt. Relativ positionierte Blockelemente nebeneinander funktionieren, aber das ist wahrscheinlich unpraktisch.
Sie können auch versuchen, ein Zeichen mit einer Breite von null hinzuzufügen, z ​
Die Lösung war, sich zu ändern <span> zu <div> (Ich habe gesehen, dass dies viele löst contenteditable Probleme in anderen Fragen hier und da) + a hinzuzufügen min-width.
Tatsächlich lässt sich mit folgendem Code die Größe der <div> wäre 0px x 18px ! Das erklärt, warum die Pflege (Bearbeitungscursor) würde ausgeblendet !
Das Problem, mit dem ich bei Chrome v89.0.4389.90 konfrontiert war, war das contenteditable Felder zeigten manchmal das blinkende Caret an focusin und manchmal nicht. Mir ist aufgefallen, dass es vor dem Fokussieren immer blinkt, wenn bereits Inhalt im Feld ist. Wenn kein Inhalt vorhanden ist, tritt manchmal das Verhalten “wird/wird nicht” auf.
Zuerst dachte ich, es muss einen widersprüchlichen Event-Handler geben, der den Fokus unberechenbar wegnimmt. Ich habe alle meine Ereignisbindungen und Timer deaktiviert. Immer noch das gleiche unregelmäßige Verhalten. Dann dachte ich, es könnte ein widersprüchliches CSS sein, also habe ich alle Stylesheets deaktiviert. Zumindest war das Verhalten jetzt konsistent: Das Caret blinkt 100% der Zeit, wenn das Feld Inhalt hat; das Caretzeichen blinkt nicht 100 % der Zeit, wenn das Feld keinen Inhalt hat.
Binds und Stylesheets habe ich wieder aktiviert. Mein div war schon eingestellt display: block; mit min-width, min-heightund padding im endgültigen berechneten Stilsatz festgelegt. Keine der anderen Antworten hier hat funktioniert. Ich habe eine placeholder an :empty:before das war ein möglicher Übeltäter. Ich habe das auskommentiert. Jetzt war das Verhalten wieder konsistent, so als ob das Stylesheet ausgeschaltet wäre. Seltsamerweise funktioniert das ausführbare Snippet auf SO mit demselben berechneten CSS-Stack. Ich möchte die behalten placeholderalso erfordert es weitere Recherchen mit meiner aktuellen Codebasis …
Die einzige Lösung, mit der ich 100 % der Zeit mit meinem aktuellen Problem arbeiten konnte, bestand darin, das Einfügezeichen zwangsweise in leere Felder zu platzieren, indem ich ein Leerzeichen erstellte und es sofort danach entfernte. Das Beste, was ich für eine Problemumgehung tun kann, bis die Ursache behoben ist.
//force caret to blink inside masks
let force_caret = function() {
if (!this.textContent) {
this.textContent=" ";
let r = document.createRange(),
s = window.getSelection();
r.setStart(this.childNodes[0], 0);
r.collapse(true);
s.removeAllRanges();
s.addRange(r);
this.textContent="";
}
}
//binds
let els = document.querySelectorAll("[contenteditable]");
for (let i = 0; i < els.length; i++) {
els[i].addEventListener('focusin', force_caret, false);
}
Versuchen Sie, eine Mindestbreite und eine Mindesthöhe anzugeben. Ein leerer Bereich hat eine gerenderte Breite und Höhe von Null, sodass nicht wirklich mit der Maus darübergefahren werden kann. Indem Sie eine Größe von wenigen Pixeln erzwingen, gibt es etwas, über das Sie mit der Maus fahren können.
– Woodrow Barlow
17. September 2014 um 18:36 Uhr
Vielleicht hilft dir diese Antwort auf eine andere Frage weiter: [stackoverflow.com/a/6249440/3298029][1] [1]: stackoverflow.com/a/6249440/3298029
– dh
17. September 2014 um 18:39 Uhr
@WoodrowBarlow siehe hier: jsfiddle.net/gs3p1a6r/4 oder jsfiddle.net/gs3p1a6r/4/embedded/result, produziert immer noch den Fehler. Es ist fokussiert, aber der Cursor wird nicht angezeigt
– Lukas
17. September 2014 um 18:46 Uhr
Ich verstehe, ich dachte, du meinst den Mauszeiger, aber du meinst das blinkende Ding. sieht so aus, als hätte Doctus es gelöst.
– Woodrow Barlow
17. September 2014 um 19:06 Uhr