Ausrichtung von Formularelementen
Rolf b
- formulare
- html
Vielleicht habe ich ja was nicht verstanden....
Das verlinkte Formular im Fiddle zeigt schön ausgerichtete Eingabefelder und Submit-Buttons (soll ein Testformular für einen Rest-Service werden). Was ich dafür aber machen musste, empfinde ich als blöde Fummelei. In den „guten“ alten Zeiten mit Table-Layout hätte ich einfach eine rahmenlose Table verwendet und der Brauser hätte es alles automatisch ausgerichtet.
<form id="form1" method="post">
<h1>Testaufrufe</h1>
<fieldset>
<legend>Aufrufparameter</legend>
<label><span>Telefonnummer:</span><input name="telefonnummer" type="text" required pattern="00\d{5,}" /></label>
<label><span>Buchungszeitpunkt:</span><input name="buchung" type="datetime" /></label>
<label><span>Neue Zustellung:</span><input name="zustellung" type="datetime" /></label>
<div class="buttons">
<button name="received">Received</button>
<button name="accepted">Accepted</button>
<button name="completed">Completed</button>
<button name="reset">Reset</button>
</div>
</fieldset>
</form>
label {display: block; margin: 5px }
label span {display: inline-block; width: 12em; }
label input { font: inherit; width: 20em; padding: 1px}
div.buttons {margin-left: calc(5px + 12em);margin-top:20px; }
Ist das, was ich gemacht habe, für neueres HTML idiomatisch richtig? Oder geht's eigentlich anderes?
Und bitte - keine Diskussionen über Accessibility, falsch konstruierte CSS Selektoren oder ähnliche Grundsatzthemen. Das Fiddle ist eine Bastelseite für EIN konkretes Thema und vernachlässigt darum den Rest.
Rolf
Hej Rolf,
Das verlinkte Formular im Fiddle zeigt schön ausgerichtete Eingabefelder und Submit-Buttons. Was ich dafür aber machen musste, empfinde ich als blöde Fummelei. In den „guten“ alten Zeiten mit Table-Layout hätte ich --einfach-- **umständlich **eine rahmenlose Table verwendet und der Brauser hätte es alles automatisch ausgerichtet.
Heute macht man das mit Flexbox und der Browser richtet es automatisch aus.
Und bitte - keine Diskussionen über Accessibility, falsch konstruierte CSS Selektoren oder ähnliche Grundsatzthemen. Das Fiddle ist eine Bastelseite für EIN konkretes Thema und vernachlässigt darum den Rest.
Wenn es denn so einfach wäre. In einem echten Formular sollten die Beschriftungen nämlich über den Feldern stehen, sonst wird es schwierig mit der Zugänglichkeit.
Wozu also mit einem Thema beschäftigen, das in der echten Welt, die zugänglich sein sollte, keine Rolle spielt? ;-)
Marc
Hallo,
In einem echten Formular sollten die Beschriftungen nämlich über den Feldern stehen, sonst wird es schwierig mit der Zugänglichkeit.
warum das denn? Wenn die Beschriftung und das zugehörige Formularfeld in einer Zeile nebeneinander stehen, sind sie IMO ebenso intuitiv zu erfassen und zu erkennen wie übereinander. Auch für assistive Techniken (Screenreader) erkenne ich keinen Unterschied, die Abfolge und Zuordnung bleibt ja gleich, ebenso die Tab-Folge.
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
In freier Wildbahn könnte ich nicht einmal sagen, welche Variante häufiger vorkommt.
So long,
Martin
Hej Der Martin,
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Im vorliegenden Beispiel ist das nicht so gut zu sehen, weil jsFiddle so ein schmales Fenster bereit stellt. Die Felder will man in aller Regel nicht 2000px breit haben, die Beschriftungen sind es in der Regel auch nicht. Daher können Beschriftung und Feld im echten Leben schon mal sehr weit auseinander liegen. Für Nutzer mit Tunnelblick (haben ein sehr kleines Gesichtsfeld) oder Nutzer von Vergrößerungssoftware entsteht dann das Problem, dass sie entweder die Beschriftung oder Feld sehen. Bei mehreren Feldern untereinander wird es so fast unmöglich zu sehen, welche Beschriftung zu welchem Feld gehört.
Gut, sie können das label anklicken. Dann sehen sie das Feld, aber nicht mehr die Beschriftung und wenn sie etwas vorschnell geklickt haben, haben sie sich nciht gemerkt, was sie angeklickt haben und müssen wieder zurückscrollen und noch mal klicken und sich diesmal merken, was sie angeklickt haben. Das Problem, obwohl es theoretisch funktioniert - das raubt Konzentration, die für das Ausfüllen des Formulars benötigt wird.
It's all one tank - finde leider das entsprechende tellerrand(?)-Video nicht mehr...
Marc
Hi,
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Im vorliegenden Beispiel ist das nicht so gut zu sehen, weil jsFiddle so ein schmales Fenster bereit stellt. Die Felder will man in aller Regel nicht 2000px breit haben, die Beschriftungen sind es in der Regel auch nicht. Daher können Beschriftung und Feld im echten Leben schon mal sehr weit auseinander liegen.
okay, das würde ich auch als Manko sehen. Aber das tut "man" doch auch nicht, oder? Also ich meine, auch bei Label+Input in einer Zeile zerrt man sie doch auch nicht weit auseinander, sondern macht den Abstand zwischen ihnen möglichst gering. Und weder Label noch Input-Feld deutlich breiter als nötig.
Für Nutzer mit Tunnelblick (haben ein sehr kleines Gesichtsfeld) oder Nutzer von Vergrößerungssoftware entsteht dann das Problem, dass sie entweder die Beschriftung oder Feld sehen.
Das ist nachvollziehbar - aber eben nur durch die große Lücke, nicht durch die horizontale Anordnung.
Gut, sie können das label anklicken. Dann sehen sie das Feld, aber nicht mehr die Beschriftung ...
Nee, das ist auch Mist. Ganz übel finde ich auch die Unsitte, die Beschriftung in das Eingabefeld zu setzen bzw. placeholder dafür zu missbrauchen. Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
Ciao,
Martin
@@Der Martin
Aber das tut "man" doch auch nicht, oder? Also ich meine, auch bei Label+Input in einer Zeile zerrt man sie doch auch nicht weit auseinander, sondern macht den Abstand zwischen ihnen möglichst gering. Und weder Label noch Input-Feld deutlich breiter als nötig.
Das heißt was? Man passt die Breite so an, dass der Text des längsten Labels gerade so passt?
Und wenn sich die Beschriftung ändert? Dann passt man das Stylesheet nochmal an?
Und bei einer mehrprachigen Website wird jede Sprachvariante gesondert gestylt?
Ganz übel finde ich auch die Unsitte, die Beschriftung in das Eingabefeld zu setzen bzw. placeholder dafür zu missbrauchen.
Letzteres davon ist übel. Ersteres nicht unbedingt …
Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
… denn das muss nicht so sein.
LLAP 🖖
Hallo,
Aber das tut "man" doch auch nicht, oder? Also ich meine, auch bei Label+Input in einer Zeile zerrt man sie doch auch nicht weit auseinander, sondern macht den Abstand zwischen ihnen möglichst gering. Und weder Label noch Input-Feld deutlich breiter als nötig.
Das heißt was? Man passt die Breite so an, dass der Text des längsten Labels gerade so passt?
das ist zumindest anzustreben. Und die Labels generell möglichst kurz, prägnant und aussagekräftig wählen. Dann sind auch die Unterschiede in der Länge nicht so groß.
Und wenn sich die Beschriftung ändert? Dann passt man das Stylesheet nochmal an?
Und bei einer mehrprachigen Website wird jede Sprachvariante gesondert gestylt?
Ich halte es für ungüstig, hier überhaupt eine Länge vorgeben zu müssen. Hier liegt - ungeachtet aller semantischer Aspekte - ein großer Vorteil der Verwendung von Gest^WTabellen: Die Spalten passen sich automatisch dem Inhalt an.
Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
… denn das muss nicht so sein.
Das ist ja auch ein Grenzfall im wahrsten Sinn des Wortes. Da steht die Beschriftung des Feldes nicht wirklich im Feld, sondern auf dem Rahmen, der dank ausreichend padding den Inhalt nicht stört. So finde ich das tatsächlich auch gut - funktional ebenso wie optisch.
Ciao,
Martin
@@Der Martin
Ich halte es für ungüstig, hier überhaupt eine Länge vorgeben zu müssen. Hier liegt - ungeachtet aller semantischer Aspekte - ein großer Vorteil der Verwendung von Gest^WTabellen:
Dass hier die Verwendung von table
nicht unberechtigt wäre, haben wir hier schon desöfteren diskutiert.
Die Spalten passen sich automatisch dem Inhalt an.
Wenn es denn die Viewportbreite erlaubt. Auf schmalen Viewport müssten Label und Eingabefeld untereinander angeordnet werden. Irgenwo wäre da ein Breakpoint zu setzen – nur wo? Der richtet sich wieder nach dem längsten Label. Dasselbe Problem – es wurde nicht gelöst, sondern an eine andere Stelle verschoben.
LLAP 🖖
Hej Gunnar,
@@Der Martin
Ich halte es für ungüstig, hier überhaupt eine Länge vorgeben zu müssen. Hier liegt - ungeachtet aller semantischer Aspekte - ein großer Vorteil der Verwendung von Gest^WTabellen:
Dass hier die Verwendung von
table
nicht unberechtigt wäre, haben wir hier schon desöfteren diskutiert.
Auch aus accessibility-Gründen spricht nichts gegen linearisierbare Layout-Tabellen, wenn sie richtig gemacht sind (kein Tabellen-Markup wie th, thead, usw)
Die Spalten passen sich automatisch dem Inhalt an.
Wenn es denn die Viewportbreite erlaubt. Auf schmalen Viewport müssten Label und Eingabefeld untereinander angeordnet werden. Irgenwo wäre da ein Breakpoint zu setzen – nur wo? Der richtet sich wieder nach dem längsten Label. Dasselbe Problem – es wurde nicht gelöst, sondern an eine andere Stelle verschoben.
Und wieder: das alles, nur um sich vor dem bekannten best-practice-Beispiel zu drücken ;-)
Marc
Also den Ausgabebereich des Fiddles kann man breiter ziehen und sieht dann, dass nur der Rahmen ums's fieldset breiter wird. Die Inputfelder nicht. Das liegt aber daran, dass ich das schnell zusammengeschustert habe.
Das Argument mit Multilingual und nötiger CSS Rekalibrierung ist natürlich relevant und spricht für eine Anordnung ÜBEReinander.
Offenbar bin ich durch etliche Jahre, in denen die Anzahl möglicher Zeilen auf 24 begrenzt war und Scrollen Zeit und MIPS gekostet hat, zu sehr auf das "nebeneinander" Layout geprägt. Das Standardlayout von Windows-Anwendungen ändert daran auch nicht viel. Es fällt mir tatsächlich schwer, Beschriftungen, die über den Feldern stehen, zu akzeptieren.
Jedenfalls danke für die Hinweise und ich schau mir wohl endlich mal die Flexboxen an. Davor habe ich bisher zurückgeschreckt.
Rolf
Hej Rolf,
Jedenfalls danke für die Hinweise und ich schau mir wohl endlich mal die Flexboxen an. Davor habe ich bisher zurückgeschreckt.
Was gar nicht nötig ist, wenn du die Beschriftung über die Inputs setzt ;-)
Aber ich will dich nicht abhalten, sondern ermuntern. Alles was du wissen musst passt auf eine Seite - na gut, eine Seite mit horizontalen Scrollbalken...
Marc
Hej Gunnar,
Ganz übel finde ich auch die Unsitte, die Beschriftung in das Eingabefeld zu setzen bzw. placeholder dafür zu missbrauchen.
Letzteres davon ist übel. Ersteres nicht unbedingt …
Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
… denn das muss nicht so sein.
Hübsch! Die Frage ist dennoch, ob es hilfreich ist, Schrift zu verkleinern. Geht jetzt sicher langsam in Richtung Korinthen kacken und ich weiß nicht mal, ob das nicht auch so noch triple A (WCAG 2.0 AAA) wäre... - manchmal muss man dann halt auch einfach etwas machen, was hübsch ist.
Ach noch was: die Spielerei nimmt Konzentration und kann dazu verleiten, nur um des Effektes willen oft in die Felder zu klicken - Korinthen halt... ;-)
Marc
@@marctrix
Hübsch! Die Frage ist dennoch, ob es hilfreich ist, Schrift zu verkleinern.
Beim Konrinthenkacken bin ich gerne dabei. Da wird nichts verkleinert; die Schrift wird bei einem leeren unfokussierten Eingabefeld erst vergrößert. ;-)
Ach noch was: die Spielerei nimmt Konzentration und kann dazu verleiten, nur um des Effektes willen oft in die Felder zu klicken - Korinthen halt... ;-)
UX ist mehr als Usability. ;-)
LLAP 🖖
Hej Gunnar,
@@marctrix
Ach noch was: die Spielerei nimmt Konzentration und kann dazu verleiten, nur um des Effektes willen oft in die Felder zu klicken - Korinthen halt... ;-)
UX ist mehr als Usability. ;-)
Kombiniere das (und all die anderen Mini-Animationen, die gerade modern werden) mal mit Dislexie (oder wie das auf deutsch buchstabiert wird) und multipliziere es mit einer beliebigen anderen Beeinträchtigung. Zum Beispiel Übernächtigung, um was harmloses vorzuschlagen, das jeder kennt.
Marc
Hallo Gunnar Bittersmann,
Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
… denn das muss nicht so sein.
Bei Verwendung von
<label class="fancy-input">foo <input></label>
sollte dazu kein JavaScript nötig sein. Und man spart die span-Elemente.
Bis demnächst
Matthias
@@Matthias Apsel
sollte dazu kein JavaScript nötig sein.
Wie willst du ohne JavaScript feststellen, ob eine Eingabe im Feld steht?
LLAP 🖖
Hallo Gunnar Bittersmann,
Wie willst du ohne JavaScript feststellen, ob eine Eingabe im Feld steht?
Indem ich pattern
in Verbindung mit der Pseudoklasse valid
verwende.
Bis demnächst
Matthias
@@Matthias Apsel
Wie willst du ohne JavaScript feststellen, ob eine Eingabe im Feld steht?
Indem ich
pattern
in Verbindung mit der Pseudoklassevalid
verwende.
Nö. Das wird für etwaige Validierung gebraucht. Es ist nicht gesagt, ob es für die Eingaben Einschränkungen gibt. Fürs Styling des Labels steht das hier nicht zur Verfügung.
LLAP 🖖
Hallo Gunnar,
Ganz übel finde ich auch die Unsitte, die Beschriftung in das Eingabefeld zu setzen bzw. placeholder dafür zu missbrauchen.
Letzteres davon ist übel. Ersteres nicht unbedingt …
Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
… denn das muss nicht so sein.
Wirklich interessante Idee. Kudos!
LG,
CK
Hallo Gunnar Bittersmann,
Ich habe mir erlaubt, einen Wikiartikel draus zu basteln.
Ich habe die transition ohne scale umgesetzt, das scheint mir für einen Artikel passender zu sein. Insgesamt gibt es sicher noch das eine oder andere zu verbessern, als da wären das Hinzufügen sinnvoller innerwiki-Links und eines kurzen Einleitungstextes. Außerdem fehlt mir noch eine Überschrift für den ersten Teil ebenso wie der endgültige Speicherort und Name des Artikels und natürlich Gunnars Zustimmung.
Für Hinweise bin ich dankbar.
Bis demnächst
Matthias
@@Matthias Apsel
und natürlich Gunnars Zustimmung.
☑︎ Mach ma.
LLAP 🖖
Hej Der Martin,
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Im vorliegenden Beispiel ist das nicht so gut zu sehen, weil jsFiddle so ein schmales Fenster bereit stellt. Die Felder will man in aller Regel nicht 2000px breit haben, die Beschriftungen sind es in der Regel auch nicht. Daher können Beschriftung und Feld im echten Leben schon mal sehr weit auseinander liegen.
okay, das würde ich auch als Manko sehen. Aber das tut "man" doch auch nicht, oder? Also ich meine, auch bei Label+Input in einer Zeile zerrt man sie doch auch nicht weit auseinander, sondern macht den Abstand zwischen ihnen möglichst gering. Und weder Label noch Input-Feld deutlich breiter als nötig.
Was ist denn möglichst gering? ;-)
So was lässt sich nicht festlegen, mitunter sind mehrere Worte nötig, um zu erklären, was in ein Feld gehört. Zum Beispiel wenn ein Alter angegeben werden muss und jemand muss volljährig sein.
Unter https://www.einfachfueralle.de/artikel/barrierefreie-formulare/design/ gibt es einen guten Artikel dazu. In diesem Bispiel ist das kürzeste Label "Label", das längste "Extralanges Label" - ich habe schon echte Formulare mit größeren Unterschieden gesehen und selbst in diesem Beispiel wird die Problematik klar.
Es ist sicher vertretbar, Formulare anders zu gestalten, wenn ein Formular mit sehr ähnlich langen Labels vorhanden ist und man "Zebrastreifen" einfügt und die Gesamtbreite des Formulars begrenzt. Das eignet sich aber weder als genereller Tipp, sondern nur in bestimmten Fällen. Außerdem sind das ziemlich viele "wenns" und "abers".
Man kriegt sicher vieles hin. Die Frage ist, ob man sich die Arbeit machen muss, nur um zu verhindern, ein best practice-Beispiel umzusetzen ;-)
Nee, das ist auch Mist. Ganz übel finde ich auch die Unsitte, die Beschriftung in das Eingabefeld zu setzen bzw. placeholder dafür zu missbrauchen. Denn dann ist die "Hilfe" weg, sobald ich das Feld focussiert habe oder bereits Inhalt drin steht.
Genau. Das ist eine Unsitte!
Marc
Hallo
Unter https://www.einfachfueralle.de/artikel/barrierefreie-formulare/design/ gibt es einen guten Artikel dazu.
Der Artikel ist wirklich lesenswert. Leider erzeugt der Aufruf im Firefox einen Fehler, weil das Zertifikat für alle möglichen Domains, darunter auch einfach-fuer-alle.de, gilt, aber nicht für einfachfueralle.de. Der Artikel ist per HTTPS auch auf einfach-fuer-alle.de erreichbar.
Ganz ohne Browserwarnung. ;-)
Tschö, Auge
Tach!
warum das denn? Wenn die Beschriftung und das zugehörige Formularfeld in einer Zeile nebeneinander stehen, sind sie IMO ebenso intuitiv zu erfassen und zu erkennen wie übereinander.
Nicht wirklich, wenn die linke Spalte und die rechte jeweils an einer senkrechten Linie linksbündig ausgerichtet sind. Dann bilden die Labels und die Felder jeweils eigene optische Blöcke untereinander aber der inhaltliche Zusammenhang von Label und Feld ist nur zu erkennen, wenn man nicht in der Zeile verrutscht. Das ist dasselbe Prinzip wie bei Code die Variablennamen und den Inhalt auszurichten.
foo = 42;
langername = 23;
Die Gleichheitszeichen alle in einer Flucht soll ein schönes Aussehen erzeugen, das macht es aber schwer, die eigentlichen Zusammenhänge zu erfassen. Besonders dann, wenn sehr lange Variablennamen für großen Abstand sorgen.
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Gelindert wird das, wenn die Label rechtsbündig ausgerichtet sind und damit wieder direkt neben dem Feld stehen.
dedlfix.
Hallo,
warum das denn? Wenn die Beschriftung und das zugehörige Formularfeld in einer Zeile nebeneinander stehen, sind sie IMO ebenso intuitiv zu erfassen und zu erkennen wie übereinander.
Nicht wirklich, wenn die linke Spalte und die rechte jeweils an einer senkrechten Linie linksbündig ausgerichtet sind. Dann bilden die Labels und die Felder jeweils eigene optische Blöcke untereinander aber der inhaltliche Zusammenhang von Label und Feld ist nur zu erkennen, wenn man nicht in der Zeile verrutscht. Das ist dasselbe Prinzip wie bei Code die Variablennamen und den Inhalt auszurichten.
foo = 42; langername = 23;
ich sehe, worauf du hinaus willst - aber das ist eigentlich nur dann problematisch, wenn die Labels (oder Variablennamen) in ihrer Länge sehr unterschieldich sind.
Besonders dann, wenn sehr lange Variablennamen für großen Abstand sorgen.
... und sie im Mix mit sehr kurzen auftreten.
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Gelindert wird das, wenn die Label rechtsbündig ausgerichtet sind und damit wieder direkt neben dem Feld stehen.
Ja, stimmt. Das ist dann aber vom Aussehen her ... ähm, gewöhnungsbedürftig. ;-)
So long,
Martin
Hej dedlfix,
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Gelindert wird das, wenn die Label rechtsbündig ausgerichtet sind und damit wieder direkt neben dem Feld stehen.
Dann wird es bei sehr starker Vergrößerung schwer, das erste Label zu finden, da sich unter dem legend eine gähnende Leere auftut...
Marc
Hallo marctrix,
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Gelindert wird das, wenn die Label rechtsbündig ausgerichtet sind und damit wieder direkt neben dem Feld stehen.
Dann wird es bei sehr starker Vergrößerung schwer, das erste Label zu finden, da sich unter dem legend eine gähnende Leere auftut...
Kannst du das näher erläutern? Hier scheint das gut zu funktionieren:
Das ist die größte Vergrößerung, die ich mit dem Firefox einstellen kann.
LG,
CK
Hej Christian,
Hallo marctrix,
Also worin siehst du den Nachteil oder gar das Problem, wenn sie nebeneinander stehen?
Gelindert wird das, wenn die Label rechtsbündig ausgerichtet sind und damit wieder direkt neben dem Feld stehen.
Dann wird es bei sehr starker Vergrößerung schwer, das erste Label zu finden, da sich unter dem legend eine gähnende Leere auftut...
Kannst du das näher erläutern? Hier scheint das gut zu funktionieren:
Gerne.
Das ist die größte Vergrößerung, die ich mit dem Firefox einstellen kann.
Du hast da ja gar kein legend ;-)
Menschen mit wenig Restsehfähigkeiten brauchen Vergrößerungsfaktoren, die deutlich über die Fähigkeiten der browser hinaus gehen. Das wird mit Bildschirmlupen erreicht, die z.B. auch die Menüs vergrößern.
Ein Arbeitskollege von mir hat das so groß eingestellt, dass dann nur noch ein paar wenige Buchstaben auf den Bildschirm passen. (Kannst du selber mit der Bildschirmlupen von Windows testen - zum ausprobieren reicht das).
Wenn du jetzt oben links eine Überschrift über dem Formular hast und dann linksbündig nach Labels suchst, wäre selbst in deinem Beispiel das "H" von Homepage u.U. das erste sichtbare Zeichen - diese Menschen sind zwar gewöhnt, horizontal scrollen zu müssen, um Texte zu lesen. Bei Rechtsbündigem Flattersatz ist es aber sehr mühsam die richtigen Zeilenanfänge zu finden. Und man muss sich dann auch noch merken, welches Feld schon ausgefüllt ist - auch wenn beim Ausfüllen mal das Telefon klingelt oder der Teekessel pfeift. Steht das Feld unter dem Label, ist zu sehen, ob man schon was rein geschrieben hat. ;-)
Mitunter werden Bildschirmlupen auch noch mit Benutzerdefinierten Farben kombiniert. Als normalsichtiger ist das extrem anstrengend und man sieht alles immer noch besser als die Betroffenen.
Dann auch noch die Zeilenanfänge suchen zu müssen ist eine ziemliche Leistung für das Gehirn!
Grüße,
Marc
Hallo marctrix,
Dann auch noch die Zeilenanfänge suchen zu müssen ist eine ziemliche Leistung für das Gehirn!
Danke, sehr einleuchtend. Am sinnvollsten sind die Labels also über dem Eingabefeld, linksbündig ausgerichtet.
LG,
CK
Hej Christian,
Dann auch noch die Zeilenanfänge suchen zu müssen ist eine ziemliche Leistung für das Gehirn!
Danke, sehr einleuchtend. Am sinnvollsten sind die Labels also über dem Eingabefeld, linksbündig ausgerichtet.
Yep.
Sonst sieht es so ungefähr aus:
Bildausschnitt "Neuer Beitrag"
Nach mehreren Screens runterscrollen (2-4) findet man dann schließlich das:
Zwei bilder sagen schließlich mehr, als zweitausend Worte. ;-) Marc
@@marctrix
Am sinnvollsten sind die Labels also über dem Eingabefeld, linksbündig ausgerichtet.
Yep.
Nope. (wo doch in diesem Thread schon mehrsprachige Webseiten angsprochnen wurden) ;-)
Zwei bilder sagen schließlich mehr, als zweitausend Worte. ;-)
Da ist Fliegenschiss auf meinem Monitor zwischen „mehr“ und „als“.
LLAP 🖖
Hallo,
Am sinnvollsten sind die Labels also über dem Eingabefeld, linksbündig ausgerichtet.
Yep.
Nope. (wo doch in diesem Thread schon mehrsprachige Webseiten angsprochnen wurden) ;-)
ja eben - also worauf willst du mit deinem Einwand hinaus? Etwa darauf, dass es Sprachen gibt, in denen von rechts nach links geschrieben und gelesen wird (z.B. Arabisch)?
Okay, aber das würde man doch IMO eher übergeordnet mit direction abhandeln, nicht mit der Textausrichtung im Einzelnen.
Zwei bilder sagen schließlich mehr, als zweitausend Worte. ;-)
Da ist Fliegenschiss auf meinem Monitor zwischen „mehr“ und „als“.
Wir scheinen den gleichen Monitor zu haben. *g*.
Ciao,
Martin
Hej Martin,
Da ist Fliegenschiss auf meinem Monitor zwischen „mehr“ und „als“.
Wir scheinen den gleichen Monitor zu haben. *g*.
Denselben? Klingt romatisch!
Marc
Denselben? Klingt romatisch!
Ist „romatisch“ das Gegenteil von „aromatisch“?
@@Der Martin
ja eben - also worauf willst du mit deinem Einwand hinaus? Etwa darauf, dass es Sprachen gibt, in denen von rechts nach links geschrieben und gelesen wird (z.B. Arabisch)?
Genau das.
Deshalb ist der Defaultwert von text-align
ja auch nicht left
, sondern start
.
LLAP 🖖
Hallo,
ja eben - also worauf willst du mit deinem Einwand hinaus? Etwa darauf, dass es Sprachen gibt, in denen von rechts nach links geschrieben und gelesen wird (z.B. Arabisch)?
Genau das.
dann lasse ich meinen Einwand trotzdem stehen, wenn auch vielleicht abgeschwächt ...
Deshalb ist der Defaultwert von
text-align
ja auch nichtleft
, sondernstart
.
... denn ich habe die Wirkung von direction:rtl so verstanden, dass quasi alle Rechts- oder Links-Angeben automatisch getauscht werden. Aber den Wert start für text-align kannte ich noch gar nicht, danke für den Hinweis.
Ciao,
Martin
Hej Gunnar,
@@marctrix
Am sinnvollsten sind die Labels also über dem Eingabefeld, linksbündig ausgerichtet.
Yep.
Nope. (wo doch in diesem Thread schon mehrsprachige Webseiten angsprochnen wurden) ;-)
Der Hinweis ist richtig - "oben links" gilt nur, wo von links nach rechts geschrieben wird - sonst "oben rechts" (oder wo auch immer zu lesen begonnen wird). Man sollte finden, wenn man in gewohnter Richtung sucht.
Zwei bilder sagen schließlich mehr, als zweitausend Worte. ;-)
Da ist Fliegenschiss auf meinem Monitor zwischen „mehr“ und „als“.
Da kann ich nichts dafür! Das war die Katze, die ich mir demnächst vielleicht anschaffe. ;-)
Marc
Hallo Marc,
Zwei bilder sagen schließlich mehr, als zweitausend Worte. ;-)
Da ist Fliegenschiss auf meinem Monitor zwischen „mehr“ und „als“.
Da kann ich nichts dafür! Das war die Katze, die ich mir demnächst vielleicht anschaffe. ;-)
du bist ein Katzenfreund? Das gibt mindestens einen zusätzlichen Sympathiepunkt. :-)
So long,
Martin
Hej Martin,
Zwei bilder sagen schließlich mehr, als zweitausend Worte. ;-)
Da ist Fliegenschiss auf meinem Monitor zwischen „mehr“ und „als“.
Da kann ich nichts dafür! Das war die Katze, die ich mir demnächst vielleicht anschaffe. ;-)
du bist ein Katzenfreund? Das gibt mindestens einen zusätzlichen Sympathiepunkt. :-)
Ich mag so ziemlich alles, was kreucht und fleucht. Wenn es kuschelt - umso besser!
Marc
Hallo,
du bist ein Katzenfreund? Das gibt mindestens einen zusätzlichen Sympathiepunkt. :-)
Ich mag so ziemlich alles, was kreucht und fleucht.
ganz so weit geht meine Begeisterung nicht. Beispielsweise habe ich eine ausgesprochene Abneigung gegen alles Getier, was mehr als vier Beine hat. Insekten, Spinnen ... alles "pfui". Aber auch Würmer und Schnecken sind nicht gerade meine besten Freunde.
Meine Favoriten im Tierreich sind wohl Katzen, Esel, Papageien und Delphine - wobei die Reihenfolge der Aufzählung kein Ranking darstellen soll. Das würde mir nämlich sehr schwerfallen.
Wenn es kuschelt - umso besser!
Gute Devise. Dem kann ich mich anschließen. :-)
Man sagt ja auch, Katzenfell sei gut bei Rheuma. Am besten wirkt es allerdings, wenn die Katze noch drin steckt und schnurrt. ;-)
So long,
Martin
Hallo
Ist das, was ich gemacht habe, für neueres HTML idiomatisch richtig?
Richtig: Ja. Die aktuelle sinnvollste Lösung? Nein.
Und bitte - keine Diskussionen über Accessibility,
Das läßt sich grade bei Formularen nicht ausblenden. Wenn nicht für dich, so doch für andere User, die auf dieses Thema stoßen.
Formulare sind mit die wichtigste Kommunikationsmöglichkeit zwischen Webseienbetreiber und Besuchern.
Wenn Besucher mit einem Formualar nicht zurecht kommt sind sie ganz schnell wieder weg, und zwar in der Regel dauerhaft. Durch ihre dann negative Propaganda werden weitere Besucher abgeschreckt. Regel: Ein vergraulter Besucher zieht fünf weitere nach sich.
Die oder gleich viele andere (wieder) zu gewinnen kostet 15 mal so viel wie den ersten gleich freundlich auf seiner Webseite zu empfangen.
Und Formulare enthalten viel Abschreckungspotential. Ich habe immer wieder mit Webseitenbetreibern zu tun, die sich (abhängig von der Geschäftsgröße) wöchentlich über 100 oder 1000 Anfragen über ihre Webseite freuen und dann erstaunt sind, dass sie im gleichen Zeitraum ähnlich viele Anfragen gar nicht erst erhalten haben, weil die Besucher über das Formular frustriert waren. Mehr als zwei Absendeversuche starten Besucher meist nur wenn der Webseitenbetreiber ein Alleinanbieter ist und seine Leistung sonst nicht zu bekommen ist. In der Regel ist die Konkurrenz aber nur einen Mausklick entfernt. Der Webseitenbetreiber bekommt davon gar nichts mit. Formular geht nicht und nach dem Frust macht sich niemand die Mühe, den Webseitenbetreiber auf anderem Weg über seinen Frust zu informieren. Dem Besucher wurde mit dem erfolglosen Ausfüllen des Formulars schließlich bereits genügend Zeit gestohlen.
Ein grundsätzliches Problem von Webseitenerstellern ist, dass die Browser Formulare von sich aus teilweise bereits stark unterschiedlich gestalten und unterstützen, Anpassungen aber gleichzeitig erschweren.
Nicht umsonst nimmt das Formular im reset.css ungefähr die Hälfe der Anweisungen ein.
Deshalb müssen grade eigene Formulare in möglichst vielen Browsern überprüft werden.
Die schlechte Nachricht:
Formulare erfordern deshalb schon von sich aus grundsätzlich viele CSS-Anweisungen.
Die gute Nachricht:
Du kannst dir einmal ein funktionierendes Layout erstellen sowie abspeichern und dann immer wieder sehr schnell darauf zurückgreifen. In der Regel passt du dann nur die Farben und vielleicht die Gesamtbreite etwas an und gut ist.
Deshalb lohnt es sich grade bei Formularen einmal etwas Zeit und Arbeit in eine funktionierende Lösung zu stecken, die dann in Minutenschnelle für jeden Webauftritt verwendet werden kann.
Weiterhin gibt es bestimmte Fehler, die Webseitenersteller ohne Rücksicht auf ihre Besucher immer wieder machen. Einige tauchen auch bei dir auf.
Zum Beispiel wird die Schriftgröße bei den meisten Formularen als viel zu klein empfunden. Dabei ist in der Regel genügend Platz für eine größere Schriftgröße vorhanden.
Buttons sollten, nicht nur für Touchscreens, so groß sein, dass sie problemlos angesteuert werden können. Grade auf hochauflösenden Tablets werden Buttons häufig wie auf Desktop-Bildschirmen angezeigt und sind nur schwer zu treffen.
Auf englische Texte (bei dir die Bezeichnung der Buttons) sollte auf deutschen Seiten verzichtet werden. Eine Webseite sollte immer komplett die Hauptsprache verwenden. Das vermeidet Mißverständnisse und wenn der Besucher nicht weiß, welchen Button er für eine bestimmte Aktion drücken muss ist er, wie bereits ob geschrieben, ganz schnell weg - und zwar dauerhaft.
Als Sprachkundiger schaltet man zudem innerlich immer komplett auf die Hauptsprache um. Vermischungen (zum Beispiel Punkt statt Komma, Einheit vor statt hinter der Zahl, Datumschreibweise) führen da regelmäßig zu Problemen und kosten den Besucher unnötig Zeit.
Fast alles, womit du dir vermeintlich die Arbeit erleichterst, ist für Besucher ein möglicher Stolperstein. Stichworte: placeholder, value, pattern und andere Überprüfungen. Manchmal auch autofocus, wenn sich oberhalb des ersten Eingabefelds Text befindet, der dann übersprungen / überscrollt wird.
Sowas
required pattern="00\d{5,}
ist zum Beispiel die reinste Abschreckung. Ohne Hinweise können die Besucher nur raten welche Schreibweise und welche Daten erforderlich sind. Und das mögen sie gar nicht. Bei Zwangsfeldern verstoßen Webseitenbetreiber zudem häufig gegen den Datenschutz. Daten dürfen nur erhoben werden, wenn sie auch erforderlich sind, nicht damit du einer Sammelleidenschaft frönen kannst. Telefonnummern sind in der Regel nicht erforderlich. Viele sensibilisierte Besucher meiden Seiten schon wenn dort eigentlich geschützte Daten erhoben werden.
Auf die internationale Vorwahl solltest du für deutsche Telefonnummern auch verzichten und für ausländische einfach erlauben und gut ist.
Wenn du zum Ausfüllen für Formularfelder bestimmte Wünsche hast bittest du einfach höflich darum. Und zwar so, dass der Besucher die Information auch beim Kontrolllesen problemlos aufnehmen kann.
Andere besucherfreundliche Lösungen wie linksbündigkeit wurden bereits angesprochen. Wenn mein Formular zum Beispiel starkt vergrößert wird rutschen Labels und Input wie bei schmalen Bildschirmen linksbündig untereinander.
Jetzt aber auch ein Beispiel wie der für ein Baukastensystem durchdachte HTML-Quelltext eines Formulars aussehen kann:
<form id="formular" class="formular" action="#" method="post">
<fieldset>
<legend>Legend</legend>
<div class="formlayout">
<div>
<!-- autofocus bei Bedarf löschen -->
<label for="telefonnummer">Telefonnummer</label>
<input id="telefonnummer" name="telefonnummer" type="tel" autofocus>
</div>
<div>
<label for="buchungszeitpunkt">Buchungszeitpunkt</label>
<input id="buchungszeitpunkt" name="buchungszeitpunkt" type="datetime">
</div>
<div>
<label for="neuezustellung">Neue Zustellung</label>
<input id="neuezustellung" name="neuezustellung" type="datetime">
</div>
<div class="buttons">
<button type="submit">Received</button>
<button type="reset">Accepted</button>
<button type="submit">Completed</button>
<button type="reset">Reset</button>
</div>
</div>
</fieldset>
</form>
Heißt, es gibt ein Grundgerüst
<form id="formular" class="formular" action="#" method="post">
<fieldset>
<legend>Legend</legend>
<div class="formlayout">
FORMULARFELDER
</div>
</fieldset>
</form>
das nur noch durch abgespeicherte Formularfelder aufgefüllt werden muss
<div>
<!-- autofocus bei Bedarf löschen -->
<label for="telefonnummer">Telefonnummer</label>
<input id="telefonnummer" name="telefonnummer" type="tel" autofocus>
</div>
<div>
<label for="buchungszeitpunkt">Buchungszeitpunkt</label>
<input id="buchungszeitpunkt" name="buchungszeitpunkt" type="datetime">
</div>
<div>
<label for="neuezustellung">Neue Zustellung</label>
<input id="neuezustellung" name="neuezustellung" type="datetime">
</div>
<div class="buttons">
<button type="submit">Received</button>
<button type="reset">Accepted</button>
<button type="submit">Completed</button>
<button type="reset">Reset</button>
</div>
Ich finde das zum Pflegen und Anpassen sehr übersichtlich. Die Felder sind schnell im Quelltext zu finden, es ist deutlich was zu einem Feld gehört und notwendige Anpassungen (id, Labelbezeichnung, for, name) schnell und einfach durchführbar.
Das notwenige CSS wird dann nur noch einmal erstellt und kann direkt einfach eingebunden / einkopiert werden - fertig.
Wobei ich Mobile First bevorzuge. Das Grundlayout für schmale Bildschirme verwendet nur altbewährte CSS-Anweisungen wie width oder display:block, so dass selbst für ältere Smartphones / Tablets kein Fallback erforderlich ist.
Ich habe mal eine temporäre Testseite mit deinen Buttons und Feldern auf meinem Spiel-Webspace erstellt:
Gruss
MrMurphy
@@MrMurphy1
Als Sprachkundiger schaltet man zudem innerlich immer komplett auf die Hauptsprache um. Vermischungen (zum Beispiel Punkt statt Komma, Einheit vor statt hinter der Zahl, Datumschreibweise) führen da regelmäßig zu Problemen und kosten den Besucher unnötig Zeit.
[…] Sowas
required pattern="00\d{5,}
ist zum Beispiel die reinste Abschreckung. Ohne Hinweise können die Besucher nur raten welche Schreibweise und welche Daten erforderlich sind.
Postel’s Law, 2. Teil: “…be liberal in what you accept from others.”
Es sollte egal sein, ob eine Nutzerin Punkt oder Komma als Dezimaltrennzeichen verwendet. (Auf Tausendertrennzeichen muss dann freilich verzichtet werden.)
Es sollte egal sein, ob ein Nutzer das Datum in der Reihenfolge JJJJ-MM-TT oder TT.MM.JJJJ angibt (solange das Jahr vierstellig angegeben wird).
Es sollte egal sein, ob eine Nutzerin bei Telefonnummern Leerzeichen, Klammern oder Bindestriche als Trennzeichen verwendet. Und auch, ob er eine Nummer als nationale (mit führender 0) oder internationale (mit + und Länderkennung am Anfang) angibt.
LLAP 🖖
Ihr seid sehr motiviert und habt mir dabei viel Stoff zum Nachdenken gegeben. Danke schön dafür. Aber ich möchte doch bitten, nicht zu sehr auf die Mängel des gezeigten Markups einzugehen.
Es ist ein reduziertes Markup - nur für die Fragestellung der Label/Input Ausrichtung. Deswegen argumentiert ihr ohne Kenntnis des eigentlichen Formulars.
Dazu kommt, dass das eine interne Testaufrufseite für einen internen Webservice wird. Deswegen kennt ihr die Rahmenbedingungen nicht, die zu dem Pattern führen (wobei das Thema "dem User das Pattern vorab klarmachen" durchaus wichtig ist), und die DatenDas Pattern an der Telefonnummer ist relevant für valide Eingaben. Andere Nummern können gar nicht in der Datenbank stehen, mithin würde der Service keine Daten finden. Der Webservice normalerweise wird nicht von Menschen, sondern von Programmen aufgerufen, und denen kann ich ein Date-Format fix vorgeben, statt zu erraten, was sie wohl gemeint haben könnten. Für die Testseite ist eine freie Wahl des Datumsformats daher nicht relevant.
Dass man ein vorausgesetztes Pattern auf der Formularseite erläutern muss, steht außer Frage und ich schlage mich auch gerade mit dem Thema herum, aus HTML5-Validierungen aussagekräftigere Fehlermeldungen zu produzieren als das, was der Browser anzeigt. Mir was das Thema bisher neu und darum muss ich dazu noch einlesen.
Die Buttons sind englisch beschriftet, weil das die Methodennamen des Webservice sind, die durch den Button ausgelöst werden.
Aber da ich das Bestreben vieler hier kenne, eine ganzheitliche Antwort zu liefern, hatte ich bewusst auf die Themen hingewiesen, die ich nicht diskutieren wollte. Weil das gezeigte Markup vorsätzlich soweit reduziert war, dass es NUR um das kleine Detail gehen sollte, wie man ordentlich und ohne sinnloses Extra-Markup Labels und Eingabefelder ausrichtet. Ergebnis war: nebeneinander anordnen ist doof für viele Leute und damit wurde die Frage für obsolet erklärt.
Die Flexbox-Lösung habe ich mir angeschaut. Danke für die Demonstration.
Die Frage mit der div-Klammerung um ein Label-Input Pärchen finde ich aber wieder sehr interessant. Ich hatte das für mich als DIV-Überschuss gesehen. Wozu Gruppen bilden, wenn da keine sind. Andererseits findet man dieses Pattern auf vielen Webseiten (aber deswegen muss es nicht gut oder best-practice sein). Mit Labels als eigenem Element muss ich den Input-Elementen eine Id und einen Namen geben, das fand ich lästig und hatte deshalb bewusst die Input-Elemente in die Labels eingebettet. Ist die <div> Lösung die allgemein favorisierte?
Gruß
Rolf
Hallo
Deswegen argumentiert ihr ohne Kenntnis des eigentlichen Formulars.
Das kannst du uns wohl kaum vorwerfen, wenn du uns die Infos vorenthälst. Im Endeffekt spielt das aber für meine Antwort keine Rolle. Ich hatte ja extra darauf hingewiesen,
Wenn nicht für dich, so doch für andere User, die auf dieses Thema stoßen.
dass die Antwort nicht nur von dir gelesen wird und nicht nur für dich gedacht ist. Du kannst dir dann aus meiner Antwort das für dich Interessante heraussuchen und andere User bekommen für sie hilfreiche Informationen.
Ich hatte das für mich als DIV-Überschuss gesehen.
Es geht nicht um div, sondern allgemein um Elemente / Container.
Die mit HTML5 / CSS3 weiter fortgeschrittene (in meinen Augen sinnvolle) Trennung von Inhalt und Gestaltung bedingt unter anderem, dass Elemente / Container, die nur der Gestaltung dienen so weit möglich vermieden werden sollen. Dabei wird gerne das "so weit möglich" übersehen.
Formulare zu gestalten ist sperrig und wird von den Browsern nicht grade unterstützt. Das hast du ja selbst grade durchlebt, beziehungsweise bist noch dabei.
Deshalb ist es in diesem Fall sinnvoll Elemente / Container zum Gruppieren zu verwenden. Und dafür sind div-Elemente noch immer zulässig. Die sind ja nicht verboten.
Im Gegensatz zum Verwenden von Tabellen und anderen Möglichkeiten ist das für mich zur Zeit die am wenigsten "falsche" Lösung. Damit lassen sich dann auch sehr vielfältige resposive Layouts erstellen.
Mit dieser Meinung stehe ich nicht allein auf weiter Flur. Ich habe die Lösung ja selbst vor einiger Zeit gefunden und inzwischen festgestellt, dass sie auch von vielen Kennern bevorzugt und, wie du selbst erkannt hast
Andererseits findet man dieses Pattern auf vielen Webseiten
auf vielen Webseiten benutzt.
Gruss
MrMurphy
Hej MrMurphy1,
Deswegen argumentiert ihr ohne Kenntnis des eigentlichen Formulars.
Das kannst du uns wohl kaum vorwerfen, wenn du uns die Infos vorenthälst.
Bei mir kam das nicht als Vorwurf an, eher als Warnung, sich nicht unnötig Arbeit zu machen. Aber es haben ja Leute miteinander diskutiert und es gab ja durchaus Nachfragen (z.B. warum Beschriftung und Eingabefeld untereinander).
Und ja, ich finde es sinnvoll, sich über Grundlegendes zu unterhalten und es öffentlich festzuhalten, auch wenn es den Ausgangsposter nicht betrifft.
Für mich war auch wieder mal was neues dabei. Man wird ja nicht dümmer von so was (mir war bisher nicht klar, dass Screenreader mit inputs in labeln Probleme haben - zum Glück mache ich das eh nicht gerne, weil auch ich das input nicht als Teil eines label begreifen kann und es die Gestaltungsmöglichkeiten sehr einschränkt).
Marc
@@marctrix
… und es die Gestaltungsmöglichkeiten sehr einschränkt).
<label>
<span>Beschriftung</span>
<input/>
</label>
hat dieselbe Struktur wie
<p>
<label>Beschriftung</label>
<input/>
</p>
Damit auch dieselben Gestaltungsmöglichkeiten.
LLAP 🖖
PS: Hier hab ich mal p
als gruppierendes Element genommen, das dürfte auch passen.
Hej Gunnar,
@@marctrix
… und es die Gestaltungsmöglichkeiten sehr einschränkt).
<label> <span>Beschriftung</span> <input/> </label>
hat dieselbe Struktur wie
<p> <label>Beschriftung</label> <input/> </p>
Damit auch dieselben Gestaltungsmöglichkeiten.
Recht hast du! - Irgendwie bin ich auf das span
nicht gekommen...
Jetzt zeig doch nicht, wie man es schlecht machen könnte und trotzdem gestylt kriegt - das war pädogogisch gesehen ein Schuss ins Knie ;-)
Marc
@@marctrix
Recht hast du! - Irgendwie bin ich auf das
span
nicht gekommen...
Rolf b aber. ;-)
Jetzt zeig doch nicht, wie man es schlecht machen könnte und trotzdem gestylt kriegt
Die Hintergrundfarben für die Boxen waren nicht zufällig gewählt.
Oops, a11y fail. Verlasse dich niemals auf Farbe als einziges Unterschiedungsmerkmal.
das war pädogogisch gesehen ein Schuss ins Knie ;-)
Ein falsches Argument für die richtige Sache ist ein Schuss ins Knie. ;-)
Kritiker widerlegen das Argument leicht und sehen damit die Sache insgesamt widerlegt. (Dafür gibt’s doch einen Begriff, der mir gerade nicht einfällt?)
LLAP 🖖
Hallo marctrix,
mir war bisher nicht klar, dass Screenreader mit inputs in labeln Probleme haben
Das Gerücht hält sich hartnäckig. https://forum.selfhtml.org/m1640197
Bis demnächst
Matthias
@@Rolf b
Aber ich möchte doch bitten, nicht zu sehr auf die Mängel des gezeigten Markups einzugehen.
Doch doch, dazu sind wir ja da.
Und wie MrMurphy1 schon sagte, bist du ja nicht der einzige, der Antworten liest. Und andere sollen sich doch nicht an unkorrigiertem Markup ein schlechtes Beispiel nehmen.
Deswegen argumentiert ihr ohne Kenntnis des eigentlichen Formulars. […] Aber da ich das Bestreben vieler hier kenne, eine ganzheitliche Antwort zu liefern, hatte ich bewusst auf die Themen hingewiesen, die ich nicht diskutieren wollte.
Du hättest im ersten Posting eher die Besonderheit deines Anwendungsfalls schildern sollen als unbegründet Dinge zu erwähnen, die du aus der Diskussion raushalten wolltest. Mit letzterem lockst du eher Leute an, die genau diese Dinge in die Diskussion reinbringen.
Die Frage mit der div-Klammerung um ein Label-Input Pärchen finde ich aber wieder sehr interessant. Ich hatte das für mich als DIV-Überschuss gesehen. Wozu Gruppen bilden, wenn da keine sind.
Ich hab da mal was hervorgehoben. Du siehst den Widerspruch?
Mit Labels als eigenem Element muss ich den Input-Elementen eine Id und einen Namen geben, das fand ich lästig und hatte deshalb bewusst die Input-Elemente in die Labels eingebettet. Ist die <div> Lösung die allgemein favorisierte?
Ganz abgesehen davon, dass input
in label
geschachtelt semantisch nicht stimmig ist (das Eingabefeld ist ja nicht Teil seiner Beschriftung), kommen einige Screenreader damit nicht klar.
Der Variante mit gruppierendem div
oder span
außenrum und label
mit for
und input
mit id
ist der Vorzug zu geben.
Nachtrag: p
als gruppierendes Element sollte auch passen.
LLAP 🖖
Ich bin nur der Empfehlung gefolgt...
Ich bin nur der Empfehlung gefolgt...
Zum „Widerspruch“: hätte ich wohl anders formulieren sollen. Warum unnötige Gruppen bilden, wenn die Gruppierung vom verwendeten Element ohnehin mitgebracht wird.
Aber offensichtlich wird die Empfehlung ja nicht empfohlen :D
Rolf
@@Rolf b
Warum unnötige Gruppen bilden, wenn die Gruppierung vom verwendeten Element ohnehin mitgebracht wird.
Das dachte sich Hixie im Fall dt
/dd
wohl auch und schmetterte die Einführung eines gruppierenden di
-Elements in HTML5 ab.
Er hätte kaum falscher liegen können.
LLAP 🖖
@@Gunnar Bittersmann
Warum unnötige Gruppen bilden, wenn die Gruppierung vom verwendeten Element ohnehin mitgebracht wird.
Das dachte sich Hixie im Fall
dt
/dd
wohl auch und schmetterte die Einführung eines gruppierendendi
-Elements in HTML5 ab.Er hätte kaum falscher liegen können.
Oh, da kommt Bewegung rein?
LLAP 🖖
Hallo Gunnar Bittersmann,
[Mit]
input
inlabel
geschachtelt […] kommen einige Screenreader […] nicht klar.
Das Gerücht hält sich hartnäckig. https://forum.selfhtml.org/m1640197 Wer da wohl jemanden gefragt hat, der sich mit sowas auskennt? ;-)
Bis demnächst
Matthias