Feld mit contenteditable=true als Dropdown oder Date picker?

[Klaus1]

Hallo,

ich spiele gerade mit dem Attribut contenteditable="true", um Felder innerhalb einer Tabelle bearbeiten zu können. Funktioniert eigentlich prima, aber kann ich auch eine Auswahlbox vorgeben z.B. mit einer Datalist oder auch das Datum zusätzlich über einen Date picker auswählen lassen? Oder muss ich das wieder aufwendiger in Javascript nachbauen?

LG Klaus

[x51398]

Hallo,

Du kannst die Elemente "input" mit dem Typ "date" und "datalist" verwenden.

Viele Grüße Basti

[Klaus1]

Dann liegt es wohl an meinem existierenden CSS oder Tabelle-JS, im JSFiddle klappts mit der Datalist, aber in meiner Tabelle nicht.

Wobei ich auch nicht wirklich glücklich damit bin. Ich hatte gehoff,t dass es erst beim Klick zu einem Input-Feld wird und nicht schon vorher. So muss ich auch mit CSS das Input-Feld so umbauen, dass es wie reiner Text aussieht. Und ich bekomme nur einen Vorschlag angezeigt, wenn ich etwas eingebe. Nichts oder ein Leerzeichen reichen nicht.

LG Klaus

[Klaus1]

Und leider ist auch noch das Tabellenfeld außerhalb des Input-Felds bearbeitbar. Stellt sich die Frage, ob es nicht doch einfacher ist, auf alle contenteditable zu verzichten, überball Inputfelder zu setzen und über die Styles so aussehen zu lassen, als ob es reine Textfelder wären?

LG Klaus

[Rolf B]

Hallo Klaus1,

Ich hatte gehofft dass es erst beim Klick zu einem Input-Feld wird und nicht schon vorher.

Die Maus (oder der Tap mit dem Finger) ist nicht die einzige Art, wie man in einer Webseite navigieren kann. Vergiss die Leute mit Tastatur oder Assistenzsystemen nicht.

Darüber hinaus solltest Du deinen Usern einen visuellen Hinweis geben, wo sich Eingabefelder befinden. Wenn die Eingabefelder unfokussiert wie plain text aussehen, woher weiß man dann, dann etwas editierbar ist?

Frei nach "Pille" McCoy: „Ich bin eine Webseite, kein Suchrätsel“

Oder: „Don't make me think“ (Steve Krug, Das intuitive Web, ISBN 978-3826697050)

Rolf

[Klaus1]

Hallo Rolf,

Die Maus (oder der Tap mit dem Finger) ist nicht die einzige Art, wie man in einer Webseite navigieren kann. Vergiss die Leute mit Tastatur oder Assistenzsystemen nicht.

Mit der Tab-Taste kommt auch in jedes contenteditable-Feld rein. Da es eine interne Anwendung ist, darf ich bestimmte Dinge, wie Browser und Version, Betriebssystem etc voraussetzen.

Darüber hinaus solltest Du deinen Usern einen visuellen Hinweis geben, wo sich Eingabefelder befinden. Wenn die Eingabefelder unfokussiert wie plain text aussehen, woher weiß man dann, dann etwas editierbar ist?

Mein MouseOver wird beim FF standardmäßig ein "Click to edit" eingeblendet. Das habe ich mit CSS eingedeutscht und etwas verschönert.

[contenteditable]:hover:after {
	position: absolute;
	background: #cccc99;
	color: #000;
	content: ' Anklicken zum Bearbeiten';
	padding-left: 15px;
	padding-right: 15px;
	border-radius:10px;
	font-style: italic;
	font-size: 12px;
	font-family: sans-serif;
	color: #444;
}

Wirklich böse ist, dass der Anwender hinter ein Input-Feld klicken kann und dieses dann löschen. Da ist es womöglich tatsächlich einfacher und flexibler, bei jedem TD ein onClick zu definieren und eine JS-Funktion aufzurufen, der dann ein Overlay genau über das TD-Feld mit dem Input-Feld (oder was auch immer) legt. Natürlich auch mit einem OnBlur, der den Wert übernimmt und das Overlay wieder versteckt. Oder?

LG Klaus

[Rolf B]

Hallo Klaus1,

Mouseover verschlimmberssert die Sache nur, denn damit hängst Du außer den Tastaturanwendern auch noch die Touchscreenanwender ab.

Da es eine interne Anwendung ist, darf ich bestimmte Dinge, wie Browser und Version, Betriebssystem etc voraussetzen.

Ja. Aber du darfst deine Anwender trotzdem nicht zu unnötigem Denken zwingen. Das lenkt von der Arbeit ab. Mach deine Eingabefelder klar erkennbar.

Die Akrobatik mit input <-> text Tausch kannst Du meiner Meinung nach einfach bleiben lassen. Zeige alle Felder, die man eingeben kann, als input-Felder an. Dann kann man durchtabben und JS ist komplett unnötig.

Die Darstellung eines input-Feldes ohne Input-Rahmen geht mit Hilfe der Pseudoklassen-Kombination :not(:focus)

input[type=text]:not(:focus) {
   border-color: transparent;
   background-color: #bbb
}

Inputfelder die keinen Fokus haben zeigen nun keinen Rand, dafür sind sie grau schattiert (was natürlich nur ein Vorschlag ist). Sobald der Cursor im Feld ist, verschwindet das Grau und es erscheint der Rahmen (plus der Fokus-Outline des Browsers). Wenn Du andere input-Typen hast, die das auch nutzen sollen, dann kannst Du dafür Selektoren hinzufügen. Nur input ohne type solltest Du nicht ohne 3 Sekunden Nachdenken benutzen, denn damit beeinflusst Du ggf. Buttons oder Check-/Radioboxen.

Mit <select> Dropdowns geht es auch, und auch datalists sind dann kein Thema. Das Aufklappen einer datalist erfolgt mit Alt-Pfeilnachunten oder klick auf das kleine Dreieck. Problem ist nur, dass eine Datalist vorgefiltert wird, d.h. wenn die Werte Bar, Foo und Zonk möglich sind, du aber ein T eingibst, wird Dir nichts angeboten. Willst Du die ungefilterte Liste sehen, musst du das Feld leeren und dann Alt-Unten drücken.

Beispiel: https://jsfiddle.net/Rolf_b/fur7h52v/2

Rolf

[Klaus1]

Aber du darfst deine Anwender trotzdem nicht zu unnötigem Denken zwingen. Das lenkt von der Arbeit ab. Mach deine Eingabefelder klar erkennbar.

Wie die Leute wohl mit Excel umgehen konnten... (nicht ganz ernst gemeint 😉 )

Beispiel: https://jsfiddle.net/Rolf_b/fur7h52v/2

Dein Beispiel beinhaltet leider keine Tabellen und kein contenteditable="true".

Meine Frage zielte ja konkret auf Tabellenfelder ab, die mit contenteditable editierbar sind und ob ich dort die Möglichkeit habe, die Form der Eingabe zu beeinflussen. Insbesondere zu limitieren. Wenn in einem Feld nur ja und nein oder ein Auswahl an Standorten erlaubt sein soll, darf der Anwender nicht vielleicht oder ungültige Standorte eingeben können. Und er sollte natürlich nicht Inhalte zerstören können, indem er Eingabefelder löschen kann.

Ich bin mir vollkommen bewusst, dass die von mir gebauten Anwendungen leider nicht dem Responsive Design entsprechen. Dafür ist das Kind leider schon lange in den Brunnen gefallen. Vielleicht beim nächsten kompletten Redesign der Seiten. Wenn man z.B. wegen einer neuen PHP-Version sowieso wieder alle Seiten anpacken muss.

LG Klaus

[Auge]

Hallo

Aber du darfst deine Anwender trotzdem nicht zu unnötigem Denken zwingen. Das lenkt von der Arbeit ab. Mach deine Eingabefelder klar erkennbar.

Wie die Leute wohl mit Excel umgehen konnten... (nicht ganz ernst gemeint 😉 )

Ob die wohl auch in Excel ein anderes Verhalten erwarten als in einem Browser?

Beispiel: https://jsfiddle.net/Rolf_b/fur7h52v/2

Dein Beispiel beinhaltet leider keine Tabellen und kein contenteditable="true".

Die Eingabefelder des Beispiels mit den Elementen für die gewünschte Tabelle zu umgeben, ist doch wohl keine Raketenwissenschaft, oder? Zudem wurde gleich in der ersten Antwort deine Frage …

Meine Frage zielte ja konkret auf Tabellenfelder ab, die mit contenteditable editierbar sind und ob ich dort die Möglichkeit habe, die Form der Eingabe zu beeinflussen.

… implizit mit nein beantwortet. Es gibt also exakt keinen Grund, darauf zurückkommen zu sollen.

Wenn in einem Feld nur ja und nein oder ein Auswahl an Standorten erlaubt sein soll, darf der Anwender nicht vielleicht oder ungültige Standorte eingeben können. Und er sollte natürlich nicht Inhalte zerstören können, indem er Eingabefelder löschen kann.

Benutze echte Formularfelder, mit denen du das alles – auch ganz ohne JavaScript – steuern kannst, oder lass' es und lebe mit der somit größeren Wahrscheinlichkeit von Fehlengaben.

Ich bin mir vollkommen bewusst, dass die von mir gebauten Anwendungen leider nicht dem Responsive Design entsprechen. Dafür ist das Kind leider schon lange in den Brunnen gefallen. Vielleicht beim nächsten kompletten Redesign der Seiten. Wenn man z.B. wegen einer neuen PHP-Version sowieso wieder alle Seiten anpacken muss.

Auf einen Wechsel auf der Backendseite zu warten, um das Frontend umzubauen, halte ich für keine gute Idee. In dem Fall gibt es tausend wichtigere Aufgaben und der Umbau des Frontends bleibt schlussendlich unerledigt liegen.

Tschö, Auge