nicht angemeldet
Gunnar Bittersmann
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Der Martin
Gunnar Bittersmann
Guten Abend miteinander,
ich habe folgende Seite erstellt, mit dem aufgenommene Alben erfasst werden sollen.
Wie bereits nach Aufrufen der Seite ersichtlich ist, gibt es drei Bereiche:
Matthias Apsel
Orlok <div class="rubrik">
<span class="legende">ALBUM</span>
...weiterer HTML-Code...
</ul>
</div>
<div class="rubrik">
<span class="legende">TRACKLIST</span>
...weiterer HTML-Code...
</div>
<div class="rubrik">
<span class="legende">WEITERES</span>
...weiterer HTML-Code...
</div>
Mein Problem besteht nun beim untersten (dritten) div, weil die Größenangabe für die acht, auf zwei Zeilen aufgeteilten Textfelder ignoriert wird:
div:nth-child(3n) ul li
{
width: 25%
}
Was habe ich beim Selektor falsch gemacht?
Vielen Dank für eure Hilfe.
Gruß Enrico
Hallo
Was habe ich beim Selektor falsch gemacht?
Nix.
Zum Testen kannst du ja mal eine Hintergrundfarbe hinzufügen. Die Hintergrundfarbe funktioniert bei fast allen Elementen, deshalb ist sie zum Testen gut geeignet.
Dein Problem sind die HTML-/CSS-Grundlagen, um die du dich bislang erfolgreich gedrückt hast.
Grundsätzlich sollten Tabellen nicht zum Layouten mißbraucht werden.
Ein Problem (neben anderen): Die führen ein Eigenleben und CSS-Anweisungen wirken nur eingeschränkt.
Gleiches gilt natürlich wenn Elemente mit "display: table" oder "display: table-cell" beeinflußt werden. Deshalb verhalten sich die li-Elemente in deinem Fall wie Tabellenzellen.
Die li werden zwar selektiert, aber die Eigenschaft "width: 25%" hat halt, wie bei Tabellenzellen auch, keine Auswirkungen.
Deshalb solltest du auf "display: table-cell", "display: table" und ähnliches verzichten. Grade Anfänger schaffen sich dadurch nur Probleme.
Gruss
MrMurphy
Hallo MrMurphy,
Danke für Deine Antwort.
Dein Problem sind die HTML-/CSS-Grundlagen, um die du dich bislang erfolgreich gedrückt hast. Grundsätzlich sollten Tabellen nicht zum Layouten mißbraucht werden.
Die Ausrichtung der Formularfelder für die Tracklist ist in Tabellenform, also wähnte ich eine Tabelle hier richtig, dem ist aber nicht so, wie ich jetzt gelernt habe.
Du meinst, dann sollte ich flex-box etc. verwenden?
Gut, mache ich und schaue, dass ich das ohne Tabelle/n bzw. display:table etc hin bekomme.
Grß Enrico
Hallo
Die Ausrichtung der Formularfelder für die Tracklist ist in Tabellenform, also wähnte ich eine Tabelle hier richtig, dem ist aber nicht so, wie ich jetzt gelernt habe.
Richtig. Man muss unterscheiden zwischen Tabellendaten (die sehr selten vorkommen) und Tabellenansicht.
Die Tabellenansicht von nicht Tabellendaten, meist von Listen, ist häufig sinnvoll und erhöht die Übesichtlichkeit. So auch in deinem Formular.
Um eine Tabellenansicht zu erzeugen gibt es wiederum mehrere Möglichkeiten. Welche davon die sinnvollste ist läßt sich ohne Kenntnis der Webseite kaum beurteilen. Außerdem müsste man wissen wie sich die Seite auf Smartphones und Tablets verhalten soll.
Außerdem hängt die Entscheidung von den Nebenwirkungen der genutzten Möglichkeiten ab. Die gibt es bei fast allen HTML-Elementen und CSS-Eigenschaften.
Du kannst durchaus "display: table-cell" zur tabellenartigen Darsellung verwenden. Allerdings musst du dann mit den Nebenwirkungen zurechtkommen.
Ähnliches gilt aber auch für andere Möglichkeiten wie Flexbox, float oder inline-block. Die haben alle Vor- und Nachteile.
Du meinst, dann sollte ich flex-box etc. verwenden?
Ich selbst würde Flexbox und / oder float verwenden. Allerdings würde ich den Quelltext auch anders aufbauen.
Gruss
MrMurphy
@@Enrico
ich habe folgende Seite erstellt, mit dem aufgenommene Alben erfasst werden sollen.
Die erste Frage wäre: Was hast du beim HTML falsch gemacht?
<div class="rubrik"> <span class="legende">ALBUM</span>
Frei nach wahsaga: Ich möchte so gern eine Überschrift sein. Bitte lass mich ein h1-Element sein! (Oder h2 wenn es auf der Seite schon eine Hauptüberschrift gibt.)
<div class="rubrik"> <span class="legende">TRACKLIST</span>
Frei nach wahsaga: Ich möchte so gern eine Überschrift sein. Bitte lass mich ein h2-Element sein!
h2, nicht ein weiteres h1 (bzw. alles eine Hierarchieebene tiefer), denn „Album ist die Überschrift für alles, auch für „Tracklist“ und auch für „Weiteres“.
Anstelle der div bieten sich andere HTML5-Elemente zur Strukturierung an – passend zur Hierarchieebene verschiedene: fürs Album header, für die Unterbereiche section.
Sollte dann so aussehen:
<header>
<h1>Album</h1>
..weiterer HTML-Code...
</header>
<section>
<h2>Tracklist</h2>
..weiterer HTML-Code...
</section>
<section>
<h2>Weiteres</h2>
..weiterer HTML-Code...
</section>
Mit CSS sorgst du dafür, dass header und section gleich gestylt werden und auch h1 und h2 dieselbe Schriftgröße bekommen (so das denn gewünscht sein soll).
Und auch, dass die Überschriften in Großbuchstaben erscheinen (text-transform: uppercase) – Großbuchstaben gehören nicht ins Markup.
Fortsetzung folgt …
LLAP 🖖
@@Gunnar Bittersmann
Fortsetzung folgt …
Mal in den Quelltext geschaut:
<meta http-equiv="content-language" content="de">
Das ist unnötig. Die Angabe der Sprache erfolgt so:
<html lang="de">
•
<meta http-equiv="content-script-type" content="text/javascript; charset=utf-8"> <meta http-equiv="content-style-type" content="text/css; charset=utf-8"> <meta http-equiv="content-type" content="text/html; charset=utf-8">
Die Meta-Angaben sind wohl überflussig; JavaScript ist als Scriptsprache ebenso Standard wie CSS als Stylingsprache. Und wofür soll die dritte gut sein?
•
<style> @charset "utf-8";
@charset sollte in einem HTML-Dokument nicht vorkommen, sondern nur in einem externen Stylesheet – und auch dort nicht unbedingt.
•
-webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box
Die Präfixe können weg.
-webkit-box-shadow: none; -moz-box-shadow: none
Warum setzt du in der letzten Zeile vor } eigentlich kein ; ans Ende? Du machst dir das Leben bei späteren Änderungen nur unnötig schwer, wenn du dort noch Zeilen hinzufügst und das ; vergisst.
•
<ul> <li class="pflicht">Albumtitel </li> <li class="volleBreite"><input id="albumtitel" type="text" value="" class="volleBreite"></li> <li class="pflicht"> Art </li> <li><select id="art"><option value="0">Single</option><option value="1">Mini-Album</option><option value="2">Album</option></select></li>
Eine Liste kann man gelten lassen. Aber: „Albumtitel“ und zugehöriges Eingabefeld wäre ein Listenpunkt, ebenso wie „Art“ und zugehöriges Eingabefeld sowie „Veröffentlicht am“ und zugehöriges Eingabefeld.
Außerdem sollten „Albumtitel“, „Art“ und „Veröffentlicht am“ Beschriftungen (label) für die Eingabefelder sein: zum einen, damit das Eingabefeld den Fokus bekommt, wenn man aufs zugehörige Label clickt. Und vor allem, damit die Zuordnung der Beschriftung zum zugehörigen Eingabefeld nicht nur visuell für Sehende, sondern auch für Nutzer von Screenreadern gegeben ist.
Die Zuordnung erfolgt im HTML entweder über das for-Attribut mit dem Wert der ID des Eingabefeldes
<label for="albumtitel>Albumtitel</label>
<input id="albumtitel" required>
oder indem das input-Element in das label-Element geschachtelt wird.
Pflichtfelder kennzeichnest du mit dem required-Attribut (wie eben gemacht).
Sämtliche entsorgst du bitte; die gehören nicht in den HTML-Quelltext. Abstände regelst du per CSS.
Auch darstellungsbezogene Klassennamen wie "volleBreite" solltest du nicht verwenden.
•
<select id="tag"><option> 01 </option><option> 02 </option><option> 03 </option>…<option> 31 </option></select> <span class="fett">.</span> <select id="monat"><option> Jan </option><option> Feb </option><option> Mär </option>…<option> Dez </option></select> <span class="fett">.</span> <select id="jahr"><option> 2015 </option></select>
Es ist ein Datum. Also ein Eingabefeld. Nicht drei. Drei getrennte Dopdown-Menüs für Tag/Monat/Jahr sind nicht nutzerfreundlich.
(Davon, dass man dort einen 30. Februar oder 31. März eingeben kann, mal ganz abgesehen.)
Zur Datumseingabe bietet HTML einen speziellen Typen und Browser spezielle UI-Elemente an. Nutze sie!
<label for="veröffentlicht_am">Veröffentlicht am</label>
<input id="veröffentlicht_am" type="date" min="2015-01-01" max="2015-12-31">
•
<table cellspacing="0" id="tracklist" data-anzahlSongs="0"> <tr> <td class="pflicht">Songtitel</td> <td> Musik von</td> <td>Text von</td> <td colspan="2">Gastmusiker</td> </tr> <tr id="s1"> <td class="volleBreite"><input type="text" value="" class="volleBreite"></td> <td> <input type="text" value=""> </td> <td><input type="text" value=""> </td> <td><input type="text" value=""> </td> <td> <input type="button" value=" + " onclick="zeileHinzufuegen()"> <input type="button" value=" - " onclick="zeileLoeschen(this)"> </td> </tr> </table>
Eine Tabelle dafür ist völlig OK. cellspacing nicht. Abstände per CSS.
Die erste Zeile sind die Spaltenüberschriften; also keine td-Elemente, sondern th. Außerdem sollten die im thead stehen.
Und „Gastmusiker“ ist auch nicht die Überschrift für die Buttons. (Wenn die eine bräuchten, dann sowas wie „Aktionen“?)
Ach ja, Buttons. Dafür gibt es button-Elemente.
<table id="tracklist" data-anzahlSongs="0">
<thead>
<tr>
<th class="pflicht">Songtitel</th>
<th>Musik von</th>
<th>Text von</th>
<th>Gastmusiker</th>
<th></th>
</tr>
</thead>
<tbody>
<tr id="s1">
<td><input type="text" value=""></td>
<td><input type="text" value=""></td>
<td><input type="text" value=""></td>
<td><input type="text" value=""></td>
<td>
<button type="button" onclick="zeileHinzufuegen()">+</button>
<button type="button" onclick="zeileLoeschen(this)">−</button>
</td>
</tr>
</tbody>
</table>
Und fürs Minuszeichen bitten keinen Strichjungen, sondern eben ein Minuszeichen '−' U+2212, in HTML als − verfügbar (wie eben gemacht).
•
Bei „Weiteres“ hast du zusammengehörige Beschriftungen und Eingabefelder schon in jeweils einem li-Element, gut so. Auch hier müssen die Label noch label werden.
Und br-Elemente brauchst du auch keine, das lässt sich mit CSS auch erreichen, z.B. display: block (falls das erforderlich sein sollte und das Eingabefeld nicht so schon die ganze zur Verfügung stehende Breite beansprucht (was man auch mit width: 100% erzwingen kann) und deshalb schon unter der Beschriftung steht.
LLAP 🖖
Hallo,
Es ist ein Datum. Also ein Eingabefeld. Nicht drei. Drei getrennte Dopdown-Menüs für Tag/Monat/Jahr sind nicht nutzerfreundlich.
absolut richtig.
(Davon, dass man dort einen 30. Februar oder 31. März eingeben kann, mal ganz abgesehen.)
Ein Datums-Eingabefeld, in dem der 31. März abgewiesen wird, macht auch nicht wirklich einen überzeugenden Eindruck. ;-)
So long,
Martin
Hallo Gunnar,
Zur Datumseingabe bietet HTML einen speziellen Typen und Browser spezielle UI-Elemente an. Nutze sie!
Unsupported für Safari, Firefox und Opera Mini. Support für IE erst ab Edge (und da auch nur teilweise).
Das zu empfehlen ist sehr zweifelhaft; man benötigt dann zwingend einen Polyfill. Was wiederum dafür sorgt, dass man JS voraussetzen muss oder den Usern aufbürden muss, das Datum in dem Format YYYY-mm-dd einzugeben, also höchstwahrscheinlich ganz anders als die lokalen Gepflogenheiten es vorsehen.
Wenn du also Date/Datetime-Input-Felder empfiehlst vergiss bitte nicht, auf die aktuell noch gravierenden Nachteile hinzuweisen.
LG,
CK
@@Christian Kruse
Zur Datumseingabe bietet HTML einen speziellen Typen und Browser spezielle UI-Elemente an. Nutze sie!
Unsupported für Safari, Firefox und Opera Mini. Support für IE erst ab Edge (und da auch nur teilweise).
Das zu empfehlen ist sehr zweifelhaft; man benötigt dann zwingend einen Polyfill.
Nein. Eben nicht. Der Fallback ist bereits da: Browser, die type="date" nicht verstehen, ignorieren das type-Attribut, zeigen also ein ganz normales Eingabefeld an.
Was wiederum dafür sorgt, dass man JS voraussetzen muss oder den Usern aufbürden muss, das Datum in dem Format
YYYY-mm-ddeinzugeben, also höchstwahrscheinlich ganz anders als die lokalen Gepflogenheiten es vorsehen.
Nein, nichts dergleichen. In das Eingabefeld kann der Nutzer eingeben, was er will. Es obliegt der serverseitigen Auswertung, das als Datum zu parsen.
Wenn du also Date/Datetime-Input-Felder empfiehlst vergiss bitte nicht, auf die aktuell noch gravierenden Nachteile hinzuweisen.
Die da wären??
LLAP 🖖
Hallo,
Das zu empfehlen ist sehr zweifelhaft; man benötigt dann zwingend einen Polyfill.
Nein. Eben nicht. Der Fallback ist bereits da: Browser, die
type="date"nicht verstehen, ignorieren dastype-Attribut, zeigen also ein ganz normales Eingabefeld an.
ACK. Geradezu ein Paradebeispiel für Progressive Enhancement: Es gibt eine Grundfunktionalität, auf die man sich mehr oder weniger verlassen kann, und wenn darüber hinausgehendes Potential zur Verfügung steht, wird es genutzt, sonst eben nicht.
Was wiederum dafür sorgt, dass man JS voraussetzen muss oder den Usern aufbürden muss, das Datum in dem Format
YYYY-mm-ddeinzugeben, also höchstwahrscheinlich ganz anders als die lokalen Gepflogenheiten es vorsehen.Nein, nichts dergleichen. In das Eingabefeld kann der Nutzer eingeben, was er will. Es obliegt der serverseitigen Auswertung, das als Datum zu parsen.
So wie jede Eingabe interpretiert und validiert werden muss. Wobei die Validierung darin bestehen kann, Eingaben einfach als fehlerhaft abzuweisen, die nicht dem erwarteten Muster entsprechen (ja, solche Programmierer soll's geben); angenehmer für den Nutzer ist natürlich, wenn verschiedene Varianten der Notation erkannt und akzeptiert werden. Beim Datum etwa zwei- oder vierstellige Jahreszahlen, ein- oder zweistellige Tages- und Monatsnummern, verschiedene Trennzeichen. Knifflig wird's allerdings, die amerikanische Notation (Monat/Tag/Jahr) eindeutig als solche zu erkennen. Ich würde mal sagen, das ist nicht sicher möglich.
So long,
Martin
Hallo Gunnar,
Zur Datumseingabe bietet HTML einen speziellen Typen und Browser spezielle UI-Elemente an. Nutze sie!
Unsupported für Safari, Firefox und Opera Mini. Support für IE erst ab Edge (und da auch nur teilweise).
Das zu empfehlen ist sehr zweifelhaft; man benötigt dann zwingend einen Polyfill.
Nein. Eben nicht. Der Fallback ist bereits da: Browser, die
type="date"nicht verstehen, ignorieren dastype-Attribut, zeigen also ein ganz normales Eingabefeld an.
Beleuchten wir das mal aus den Blickwinkeln technische Machbarkeit, User-Experience und Kunden-Akzeptanz.
Aus technischer Sicht muss man um das umzusetzen einen Date-Parser schreiben, der die verschiedenen Formate und deren Abwandlungen zweifelsfrei erkennt und das Datum richtig parsed. Du musst also zuerst mal unterscheiden können zwischen den Reihenfolgen der Angaben:
DMYYMDMDYDie Schreibweisen verteilen sich auf die Welt, teilweise wird im gleichen Land beides verwendet. Das ist völlig unrealistisch, das ist eindeutig nicht erkennbar. Nehmen wir z.B. Brasilien und die USA: Brasilien verwendet überwiegend dd/mm/yyyy. Die USA verwendet überwiegend mm/dd/yy und mm/dd/yyyy. Hier ist also schon ein Konflikt, der nicht eindeutig detektierbar ist. Aber wir brauchen gar nicht über Landesgrenzen gehen. Schauen wir uns mal Canada an. Dort gibt es (neben anderen Schreibweisen) DD/MM/YYYY, MM/DD/YYYY, YY/MM/DD - zack, wieder ein paar Konflikte, die nicht detektierbar sind.
Es gibt noch mehr Probleme, wenn wir uns die Schreibweisen in Europa betrachten. Das zu recherchieren verbleibt dem geneigten Leser.
Betrachten wir das aus Usability-Sicht: statt eines Date-Pickers haben wir nun also einfach nur ein Textfeld, in die ein Datum eingegeben werden soll. Die User-Reaktion kann sich jetzt auf zweierlei Art äussern: er trägt Gedankenlos das Datum in seinem gewohnten Format ein. Bei einer Zweideutigkeit aufgrund des Formats muss dem User entweder das Datum erneut vorgesetzt werden mit der Information, dass das Datum so zweideutig ist oder es ist schlicht das falsche (sprich das nicht vom User gemeinte) Datum. Geile UX, muss man schon sagen...
Die zweite mögliche Reaktion ist Verwirrung. „In welchem Format soll ich das eingeben? Was erwartet der Software-Entwickler?“ Auch nicht sonderlich sinnvoll.
Eine Möglichkeit dem entgegen zu wirken wäre es, einen Hinweis-Text einzublenden, welches Format erwartet wird. Das müsste man via JS einblenden wenn das type="date"-Atttribut nicht unterstützt wird. Schön ist anders, der Komfort geht vollständig flöten.
Alles in allem: technisch nicht sinnvoll umsetzbar, es sei denn man stellt den User vor eine ziemlich hohe Hürde.
Aus der Sicht des Kunden kann ich aus Erfahrung sagen: ich habe noch keinen Kunden getroffen, der ein einfaches Text-Eingabefeld für ein Datum akzeptiert hat. Ich musste das immer rechtfertigen und habe den Kunden nur mit einem Polyfill und dem Hinweis, dass das Textfeld nur noch bei Nicht-JS-Usern auftaucht zufriedenstellen können.
Mein Fazit bleibt: die Verwendung von Date-Time-Input-Feldern ist problematisch und bleibt mit gravierenden Nachteilen verbunden.
LG,
CK
@@Christian Kruse
Aus technischer Sicht muss man um das umzusetzen einen Date-Parser schreiben, der die verschiedenen Formate und deren Abwandlungen zweifelsfrei erkennt und das Datum richtig parsed.
Nein. Man kann sich vorher klarmachen, dass das gar nicht geht.
Ein Parser kann ohne weitere Information nicht wissen, ob 01-02-03 (mit was für Trennzeichen auch immer) für den 3. Februar 2001, den 1. Februar 2003 oder (völlig abwegig) den 2. Januar 2003 steht.
Das kann ein Mensch (ohne Kontext) aber auch nicht. Der müsste auch rückfragen.
Bei einer Zweideutigkeit aufgrund des Formats muss dem User entweder das Datum erneut vorgesetzt werden mit der Information, dass das Datum so zweideutig ist oder es ist schlicht das falsche (sprich das nicht vom User gemeinte) Datum.
Natürlich wäre ersteres zu tun. Wenn man denn Datumseingaben in beliebigen Formaten zulassen will.
Vielleicht will man das aber nicht. Sondern dem Benutzer sagen, in welchem Format[^1] man die Eingabe erwartet. Das kann je nach Zielgruppe durchaus unterschiedlich sein. Bei einer internationalen Seite könnte man Sprachinformation und Geolocation auswerten, um bestmöglich zu raten.
Sagte ich gerade, dem Benutzer sagen, in welchem Format man die Eingabe erwartet? Ja. Es gibt einen Unterschied zur Diskussion über die Eingabe von Telefonnummern. Dort ist eine Nummer eindeutig, egal in welchem Format der Nutzer sie eingibt.
Eine Möglichkeit dem entgegen zu wirken wäre es, einen Hinweis-Text einzublenden, welches Format erwartet wird. Das müsste man via JS einblenden wenn das
type="date"-Atttribut nicht unterstützt wird.
Nein, das placeholder-Attribut wäre dafür prädestiniert.
Mein Fazit bleibt: die Verwendung von Date-Time-Input-Feldern ist problematisch und bleibt mit gravierenden Nachteilen verbunden.
Problematisch, ja. Nicht mehr und nicht weniger problematisch als bei Namen zu erkennen, was given name (mit Absicht auf englisch, da es keine deutsche Entsprechung dafür gibt) und was Familienname ist.
LLAP 🖖
Hallo Gunnar,
Aus technischer Sicht muss man um das umzusetzen einen Date-Parser schreiben, der die verschiedenen Formate und deren Abwandlungen zweifelsfrei erkennt und das Datum richtig parsed.
Nein. Man kann sich vorher klarmachen, dass das gar nicht geht.
Du hast aus dem Kontext gerissen zitiert. Zu dem Ergebnis war ich in dem vorhergehenden Beitrag auch gekommen.
Bei einer Zweideutigkeit aufgrund des Formats muss dem User entweder das Datum erneut vorgesetzt werden mit der Information, dass das Datum so zweideutig ist oder es ist schlicht das falsche (sprich das nicht vom User gemeinte) Datum.
Natürlich wäre ersteres zu tun. Wenn man denn Datumseingaben in beliebigen Formaten zulassen will.
Vielleicht will man das aber nicht. Sondern dem Benutzer sagen, in welchem Format[^1] man die Eingabe erwartet.
S.o. - aus dem Kontext gerissen. Zu dem Ergebnis bin ich aufgrund meiner Ausführungen auch gekommen.
Sagte ich gerade, dem Benutzer sagen, in welchem Format man die Eingabe erwartet? Ja. Es gibt einen Unterschied zur Diskussion über die Eingabe von Telefonnummern. Dort ist eine Nummer eindeutig, egal in welchem Format der Nutzer sie eingibt.
Natürlich, ich habe nichts gegenteiliges gesagt.
Eine Möglichkeit dem entgegen zu wirken wäre es, einen Hinweis-Text einzublenden, welches Format erwartet wird. Das müsste man via JS einblenden wenn das
type="date"-Atttribut nicht unterstützt wird.Nein, das
placeholder-Attribut wäre dafür prädestiniert.
Um dich mal zu zitieren: das placeholder-Attribut sollte keine Beschriftung ersetzen. Denn es hat den entscheidenden Nachteil, dass es ausgeblendet wird, sobald der User etwas eingibt (oder gar ein Wert bereits beim Laden im Feld steht). Hier das Attribut zu verwenden ist keine gute Idee.
Mein Fazit bleibt: die Verwendung von Date-Time-Input-Feldern ist problematisch und bleibt mit gravierenden Nachteilen verbunden.
Problematisch, ja.
Nicht mehr und nicht weniger habe ich gesagt. Ich sagte nicht es sei nicht einsetzbar, ich verwende sie ja auch häufig in meiner Software. Nur die bedenkenlose Empfehlung wie du sie abgegeben hast war nicht sinnvoll. Der Einsatz ist zur Zeit noch problematisch und man muss viele Nebenwirkungen beachten. Das zu erwähnen ist wichtig, denn ein eventueller Anfänger wird sich dem nicht bewusst sein.
LG,
CK
@@Christian Kruse
Um dich mal zu zitieren: das
placeholder-Attribut sollte keine Beschriftung ersetzen. Denn es hat den entscheidenden Nachteil, dass es ausgeblendet wird, sobald der User etwas eingibt (oder gar ein Wert bereits beim Laden im Feld steht). Hier das Attribut zu verwenden ist keine gute Idee.
Die Beschriftung des Eingabefeldes wäre sowas wie „Veröffentlicht am“ (um beim Beispiel des TO zu bleiben). Das soll nicht in ein placeholder-Attribut.
Sowas wie „z.B. 25.08.1975“[^1] könnte durchaus darin untergebracht werden:
“The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format.” [HTML5]
Die Frage ist: Muss der Nutzer noch über das Format informiert werden, wenn er schon etwas eingegeben hat?
Der Einsatz ist zur Zeit noch problematisch und man muss viele Nebenwirkungen beachten. Das zu erwähnen ist wichtig, denn ein eventueller Anfänger wird sich dem nicht bewusst sein.
ACK.
LLAP 🖖
Hallo Gunnar,
Sowas wie „z.B. 25.08.1975“[^1] könnte durchaus darin untergebracht werden:
Du hast recht, ich hätte mich präziser ausdrücken sollen. Ein Placeholder allein ist IMHO nicht genug.
LG,
CK
@@Christian Kruse
Ein Placeholder allein ist IMHO nicht genug.
Der Versuch, den Placeholdertext permanent anzuzeigen, scheitert an den arg beschränkten Eigenschaften, die das Pseudoelement bzw. die Pseudoklasse unterstützt.
Da ersetzte Elemente wie input keinen generierten Inhalt haben dürfen, geht auch input::before { content: attr(placeholder) } nicht.
Aber warum sollte Placeholder erstmal nicht reichen? Das Feld ist initial leer, der Hinweis wird angezeigt. Nutzer tippt ein Datum ein, in den meisten Fällen wohl im angegeben Format. Falls nicht, würde das vermutlich einen Nutzer auch nicht davon abbringen, das Formular abzuschicken.
Wenn die serverseitige Auswertung mit der Nutzereingabe nichts anfangen kann, wird eine Meldung ausgegeben. Die enhält noch einmal den Hinweis auf das einzuhaltende Format undd bleibt permanent stehen.
Die Meldung kann (lies: sollte) so formuliert sein, dass nicht der Nutzer als der Dumme dasteht, bspw. „Unser System kann leider nur Datumseingaben im Format TT.MM.JJJJ (bspw. 25.08.1975) oder JJJJ-MM-TT (bspw. 1975-08-25) entgegennehmen.“
In Wirklichkeit ist das System natürlich doch toleranter; auch 25.8.1975 ohne führende Null wird akzeptiert, auch 25/8/1975.
LLAP 🖖
Hallo Gunnar Bittersmann,
Es gibt auch Fälle, in denen unvollständige Datümer entgegen genommen werden müssen, zum Beispiel, wenn man bei einer Geburtstagserinnerungsseite das Geburtsjahr eines Geburtstagskindes nicht kennt.
Bis demnächst
Matthias
@@Matthias Apsel
Es gibt auch Fälle, in denen unvollständige Datümer entgegen genommen werden müssen, zum Beispiel, wenn man bei einer Geburtstagserinnerungsseite das Geburtsjahr eines Geburtstagskindes nicht kennt.
Die HTML-Spec kennt yearless dates, aber keinen Einhabefeldtypen dafür, hm.
LLAP 🖖
Hallo Gunnar,
Weil dann das passiert, was ich schon zig mal gesehen habe: der User tippt das erste Zeichen ein und weiss dann nicht mehr weiter und muss die Eingabe löschen um sich das Pattern zu merken.
LG,
CK
@@Christian Kruse
Weil dann das passiert, was ich schon zig mal gesehen habe: der User tippt das erste Zeichen ein und weiss dann nicht mehr weiter und muss die Eingabe löschen um sich das Pattern zu merken.
Das ist die Frage: Kann sich der Nutzer das erwartete Datumsformat wirklich nicht 3 Sekunden lang merken? Es geht ja lediglich um die Reihenfolge von Tag, Monat und Jahr, evtl. auch ob das Jahr vierstellig angegeben werden muss.
Der Nutzer „weiss dann nicht mehr weiter“ finde ich doch etwas weit hergeholt.
Du denkst, wenn „TT.MM.JJJJ“ in der Beschriftung neben/über dem Eingabefeld stünde, würde der Blick des Nutzers ständig zwischen der Beschriftung und dem Eingabefeld hin- und herspringen? Als ob der Nutzer nach jedem eingetippten Zeichen vergleichen würde, ob seine Eingabe dem Muster entspricht‽
Ich denke, der Nutzer erfasst einmal das Format und gibt dann das Datum ein, ohne das Format dabei weiterhin angezeigt zu benötigen.
Wer nun recht hat oder nicht, zeigt uns … – ein Nutzertest.
LLAP 🖖
Hallo Gunnar,
Weil dann das passiert, was ich schon zig mal gesehen habe: der User tippt das erste Zeichen ein und weiss dann nicht mehr weiter und muss die Eingabe löschen um sich das Pattern zu merken.
Das ist die Frage: Kann sich der Nutzer das erwartete Datumsformat wirklich nicht 3 Sekunden lang merken?
Falsche Frage. Er merkt es sich meiner Erfahrung nach gar nicht erst, sondern tippt einfach drauf los. Um dann zu merken, dass er es sich hätte merken sollen. Das ist die Erfahrung aus meinem Alltag in der Entwicklung von Büro-Software, in der es sich quasi ständig um Eingabefelder dreht... ;-)
Wer nun recht hat oder nicht, zeigt uns … – ein Nutzertest.
Nun, wie gesagt: das ist ja nicht aus der hohlen Hand, sondern ich habe diese Erfahrung gemacht im Zusammenspiel mit Nutzern.
LG,
CK
@@Christian Kruse
Das ist die Frage: Kann sich der Nutzer das erwartete Datumsformat wirklich nicht 3 Sekunden lang merken?
Falsche Frage. Er merkt es sich meiner Erfahrung nach gar nicht erst, sondern tippt einfach drauf los. Um dann zu merken, dass er es sich hätte merken sollen.
Wann ist „dann“? Wenn er auf den Submit-Button geclickt hat? (Bzw. das Formular anderweitig abgeschickt hat?)
Dann steht das Format ja permanent bei Eingabefeld, wie ich schon sagte.
LLAP 🖖
@@Christian Kruse
Wann ist „dann“?
Sobald der Placeholder verschwindet.
Aus den Augen, aus dem Sinn? Mag auch sein. Der Nutzertest wird’s zeigen.
Könnte aber schwierig werden, hier passende Versuchspersonen zu finden.
Hierzulande wird wohl jeder TT.MM.JJJJ oder T.M.JJJJ oder TT.MM.JJ oder T.M.JJ oder eingeben. Freaks wie ich auch JJJJ-MM-TT. JJ-MM-TT wohl nicht. Und M/T/JJ schon gar nicht.
Damit ist bei dieser Nutzergruppe keine Fehldeutung möglich. Wenn erste Zahl viestellig, dann Reihenfolge Jahr – Monat – Tag, andernfalls Tag – Monat – Jahr.
Im deutschsprachigen Raum besteht das Problem gar nicht.
In ganz Europa nicht.
Auf fast der ganzen Welt nicht. Nur ein einzelnes Land tanzt aus der Reihe (und zieht seinen nördlichen Nachbarn mit in den Sumpf).
LLAP 🖖
Hallo Gunnar,
Hierzulande wird wohl jeder TT.MM.JJJJ oder T.M.JJJJ oder TT.MM.JJ oder T.M.JJ oder eingeben. Freaks wie ich auch JJJJ-MM-TT. JJ-MM-TT wohl nicht. Und M/T/JJ schon gar nicht. […] Im deutschsprachigen Raum besteht das Problem gar nicht.
Dir als Berliner sollte bewusst sein, dass es durchaus viele US-Amerikaner in Deutschland allgemein und in Berlin im speziellen gibt. Mit dieser Aussage wäre ich vorsichtig ;-)
In ganz Europa nicht.
Haalt! Das Internet endet nicht an der Landesgrenze.
Auf fast der ganzen Welt nicht. Nur ein einzelnes Land tanzt aus der Reihe (und zieht seinen nördlichen Nachbarn mit in den Sumpf).
Die Daten-Formate sind vielfältiger als man glaubt, siehe oben verlinkte Tabelle.
LG,
CK
@@Christian Kruse
Dir als Berliner sollte bewusst sein, dass es durchaus viele US-Amerikaner in Deutschland allgemein und in Berlin im speziellen gibt.
Und mache davon sprechen auch nach Jahren immer noch kaum ein Wort Deutsch. Die können mit einer deutschsprachigen Seite sowieso nichts anfangen.
Von den anderen kann man erwarten, dass die auf einer deutschsprachigen Seite das im deutschsprachigen Raum gängige Datumsformat verwenden.
Auf englischsprachigen Seiten sieht das anders aus.
Auf fast der ganzen Welt nicht. Nur ein einzelnes Land tanzt aus der Reihe (und zieht seinen nördlichen Nachbarn mit in den Sumpf).
Die Daten-Formate sind vielfältiger als man glaubt, siehe oben verlinkte Tabelle.
MMM DD YYYY und MMMM DD YYYY in der Tabelle zählen nicht mit, wir reden hier ausschließlich über numerische Datumsangaben. Und dann bleibt nur eine Handvoll Länder, die mit in den Sumpf gezogen wurden und das unsinnigste aller Datumsformate verwenden.
LLAP 🖖
Moin,
ich bin voll und ganz bei dir. Man möchte einfach einen unnötigen Round-Trip vermeiden, der dann im Endeffekt nur dazu dient, dem Benutzer mitzuteilen, dass seine/ihre Eingabe so nicht stimmt.
Bei Datum-/Zeiteingaben verwende ich ein <input type="range" min="1" max="31"/> (Beispiel für Tag). Das wird dann clientseitig korrigiert, so dass der Benutzer gleich ein Feedback hat.
Hallo
Wenn die serverseitige Auswertung mit der Nutzereingabe nichts anfangen kann, wird eine Meldung ausgegeben. Die enhält noch einmal den Hinweis auf das einzuhaltende Format und bleibt permanent stehen.
Die Meldung kann (lies: sollte) so formuliert sein, dass nicht der Nutzer als der Dumme dasteht, bspw. „Unser System kann leider nur Datumseingaben im Format TT.MM.JJJJ (bspw. 25.08.1975) oder JJJJ-MM-TT (bspw. 1975-08-25) entgegennehmen.“
Nur eine Idee, aber wenn man die Benutzereingaben in einem bestimmten Format haben möchte, könnte man auch darüber nachdenken das ganze so umzusetzen, dass sich umständliche Erklärungen von vorneherein erübrigen, indem man die entsprechenden UI-Elemente dem gewünschten Format gemäß anpasst.
Sprich, wenn ich zum Beispiel möchte, dass der Benutzer Adressdaten eingibt, dann stelle ich auch kein mehrzeiliges Eingabefeld zur Verfügung, sondern teile den übergeordneten Informationszusammenhang in seine Bestandteile auf und stelle Eingabefelder für Straße, Stadt und Postleitzahl separat bereit.
Statt also das Datum als Ganzes abzufragen, könnte man auch hier separat beschriftete und von der Größe her angepasste Eingabefelder für Tag, Monat und Jahr bereitstellen:
Tag Monat Jahr
+-----+ +-----+ +----------+
| | | | | |
+-----+ +-----+ +----------+
Die Anzeige könnte man natürlich noch an das erwartete Format des Benutzers anpassen:
Year Month Day
+----------+ +-----+ +-----+
| | | | | |
+----------+ +-----+ +-----+
Dass der Benutzer hier einen geringen Mehraufwand hat, da er mit TAB oder Maus zwei Eingabefelder mehr selektieren muss, ist denke ich nur eine sehr geringfügige Beeinträchtigung der Usability, erst recht verglichen mit der Situation, dass der Benutzer aufgrund einer „falsch formatierten Eingabe“ die selbige wiederholen muss.
Aber wie gesagt, nur eine Idee...
Gruß,
Orlok
@@Orlok
Sprich, wenn ich zum Beispiel möchte, dass der Benutzer Adressdaten eingibt, dann stelle ich auch kein mehrzeiliges Eingabefeld zur Verfügung, sondern teile den übergeordneten Informationszusammenhang in seine Bestandteile auf und stelle Eingabefelder für Straße, Stadt und Postleitzahl separat bereit.
Das sind auch verschiedene Daten. (Bei Straße und Hausnummer wiederum: kommt drauf an.)
Statt also das Datum als Ganzes abzufragen, könnte man auch hier separat beschriftete und von der Größe her angepasste Eingabefelder für Tag, Monat und Jahr bereitstellen:
Die ganze Diskussion entsprang daraus, dass ich eben das gereade nicht für sinnvoll erachte:
Es ist ein Datum. Also ein Eingabefeld. Nicht drei. Drei getrennte Dopdown-Menüs für Tag/Monat/Jahr sind nicht nutzerfreundlich.
LLAP 🖖
Hallo
Das sind auch verschiedene Daten. (Bei Straße und Hausnummer wiederum: kommt drauf an.)
Naja, warum die Bestandteile einer Anschrift/Adresse jetzt verschiedener sein sollen als die Bestandteile eines Datums sehe ich noch nicht so ganz, denn für beide Fälle gilt, dass jede Information für sich genommen ohne die anderen weitestgehend nutzlos ist:
Die Angabe „Goethestraße 15“ wird mir ohne die Information, in welchem Ort sie sich befindet, genauso wenig bringen wie eine Datumsangabe, bei der Tag, Monat oder Jahr fehlt.
Die ganze Diskussion entsprang daraus, dass ich eben das gereade nicht für sinnvoll erachte:
Es ist ein Datum. Also ein Eingabefeld. Nicht drei. Drei getrennte Dopdown-Menüs für Tag/Monat/Jahr sind nicht nutzerfreundlich.
Ja, hätte ich mal den ganzen Thread gelesen. ;-)
Also auch wenn ich die Beeinträchtigung durch die Aufteilung der Datumsangabe auf mehrere Eingabefelder im Vergleich nicht für so gravierend halte, muss ich dir dennoch recht geben, dass dies keine optimale Lösung darstellt, und dass man sich hier eine Aufteilung der Eingabe auch tatsächlich sparen und dennoch die Information über das gewünschte Eingabeformat mehr oder weniger idiotensicher transportieren kann.
Schließlich bietet CSS die entsprechenden Möglichkeiten, auch ein einziges Eingabefeld und dessen Umgebung so zu gestalten, dass in Verbindung mit einer passenden Beschriftung das gewünschte Format deutlich wird, auch ohne placeholder-Text, den der Benutzer nach der Eingabe der ersten Zahl gegebenenfalls schon wieder vergessen hat.
Dies könnte man etwa durch eine (leichte) farbliche Abstufung des Hintergrundes erreichen:
+----+ +----+ +--------+
| TT | | MM | | JJJJ |
+------------------------+
Datum: |: : : : : :|
+------------------------+
+----+ +----+ +--------+
Gruß,
Orlok
@@Orlok
dass in Verbindung mit einer passenden Beschriftung das gewünschte Format deutlich wird, auch ohne placeholder-Text,
Da liegt das Problem. Sowas wie „TT.MM.JJJJ“ sollte in der Beschriftung nicht auftauchen, denn wenn ein UA für <input type="date"> ein eigenes UI-Element rendert, wäre diese Beschriftung unpassend.
Dies könnte man etwa durch eine (leichte) farbliche Abstufung des Hintergrundes erreichen:
Ja, bei dicktengleicher Schrift sollte das mit der Einheit ch möglich sein.
BTW, Selectors Level 4 sieht ein Pseudoattribut :placeholder-shown vor. Demnächst in Ihrem Browser …
LLAP 🖖
@@Orlok
Dass der Benutzer hier einen geringen Mehraufwand hat, da er mit TAB oder Maus zwei Eingabefelder mehr selektieren muss, ist denke ich nur eine sehr geringfügige Beeinträchtigung der Usability
Außerdem haben viele (die meisten?) Nutzer weder Tab-Taste noch Maus.
erst recht verglichen mit der Situation, dass der Benutzer aufgrund einer „falsch formatierten Eingabe“ die selbige wiederholen muss.
Die Situation tritt womöglich gar nicht auf.
LLAP 🖖
Hallo Gunnar Bittersmann,
Problematisch, ja. Nicht mehr und nicht weniger problematisch als bei Namen zu erkennen, was given name (mit Absicht auf englisch, da es keine deutsche Entsprechung dafür gibt) und was Familienname ist.
Rufname‽
Bis demnächst
Matthias
Hallo Matthias,
Problematisch, ja. Nicht mehr und nicht weniger problematisch als bei Namen zu erkennen, was given name (mit Absicht auf englisch, da es keine deutsche Entsprechung dafür gibt) und was Familienname ist.
Rufname‽
im Ansatz nicht schlecht - nur bezeichnet der Begriff "Rufname" im Deutschen auch den "primären" Vornamen für den Fall, dass jemand mehrere "given names" hat. Ich habe schon in einigen Formularen den Zusatz gesehen: "Bei mehreren Vornamen bitte Rufnamen unterstreichen".
Insofern: Ja, die Richtung stimmt, aber so ganz genau passt es dann doch nicht.
So long,
Martin
Hallo Der Martin,
Ich habe schon in einigen Formularen den Zusatz gesehen: "Bei mehreren Vornamen bitte Rufnamen unterstreichen".
Ja, stimmt. Früher wurde der Rufname unterstrichen, heute gibt es keinen "primären" Vornamen mehr. Die Namensträger können selbst bestimmen, mit welchem ihrer Namen sie gerufen werden wollen. Bei mir und bei meinem ältesten Sohn ist der Rufname nicht der erste. Diese Regelung gilt mindestens schon seit 1995, denn da war ich überrascht, dass der Rufname auf der Geburtsurkunde nicht unterstrichen werden durfte.
Bis demnächst
Matthias
Moin,
Ich habe schon in einigen Formularen den Zusatz gesehen: "Bei mehreren Vornamen bitte Rufnamen unterstreichen".
Ja, stimmt. Früher wurde der Rufname unterstrichen, heute gibt es keinen "primären" Vornamen mehr.
nein? Dann bin ich mit meinem Wissen nicht auf dem aktuellen Stand.
Die Namensträger können selbst bestimmen, mit welchem ihrer Namen sie gerufen werden wollen.
Das war doch vorher auch so, und durch die Unterstreichung eines Namens drücken sie diese Entscheidung aus. Wie machen sie diese Entscheidung heute kenntlich?
Bei mir und bei meinem ältesten Sohn ist der Rufname nicht der erste.
So einen haben wir auch in der Verwandtschaft: Mein Cousin, Jahrgang 1981, heißt Carsten René, und seine Eltern haben damals sogar Carsten zum Rufnamen erklärt. Zwecklos. Er wird fast ausschließlich René gerufen.
Diese Regelung gilt mindestens schon seit 1995, denn da war ich überrascht, dass der Rufname auf der Geburtsurkunde nicht unterstrichen werden durfte.
Und was stattdessen?
So long,
Martin
Hallo Martin,
nein? Dann bin ich mit meinem Wissen nicht auf dem aktuellen Stand.
Und zwar ziemlich lange, denn…
Die Namensträger können selbst bestimmen, mit welchem ihrer Namen sie gerufen werden wollen.
Das war doch vorher auch so, und durch die Unterstreichung eines Namens drücken sie diese Entscheidung aus. Wie machen sie diese Entscheidung heute kenntlich?
Das BSI sagt dazu: Rufnamen gibt es in der BRD seit 1960 nicht mehr. Alle Vornamen sind gleichberechtigt und können nach belieben benutzt werden. Unterstrichen wird nicht. (Und tatsächlich, 1982 wurde auch kein Name auf der Geburtsurkunde unterstrichen)
LG,
CK
@@Christian Kruse
Zur Datumseingabe bietet HTML einen speziellen Typen und Browser spezielle UI-Elemente an. Nutze sie!
[lange Diskussion]
Kann man eigentlich nachträglich noch die Betreffs von Postings ändern, so wie Tags (auch für nachfolgende Antworten)?
Eigentlich müsste der ganze Subthread angefangen mit dem Posting, auf das ich gerade antworte, unter „Datumseingabe“ laufen.
LLAP 🖖
Hallo Gunnar,
Kann man eigentlich nachträglich noch die Betreffs von Postings ändern, so wie Tags (auch für nachfolgende Antworten)?
Aktuell nur von Hand für jedes Posting einzeln.
LG,
CK
@@Christian Kruse
Kann man eigentlich nachträglich noch die Betreffs von Postings ändern, so wie Tags (auch für nachfolgende Antworten)?
Aktuell nur von Hand für jedes Posting einzeln.
Feature request?
Wenn es Zeit ist, den Betreff zu ändern, kann man ja noch nicht wissen, dass es Zeit gewesen sein würde, den Betreff zu ändern.
Ergibt die Zeiform einen Sinn?
Was ich sagen will: Man kann ja beim Verfassen einer Antwort nicht ahnen, ob sich daraus ein längerer Subthread entwickelt, der mit dem ursprünglichen Thema nichts zu tun hat und seinen eigenen Betreff verdient hätte. Und wenn der Subthread da ist, ist es zu spät.
LLAP 🖖
Hallo Gunnar,
Feature request?
Scheint mir eine sinnvolle Erweiterung zu sein, ja. Mach ruhig mal einen auf.
LG,
CK