Tabellen und Formulare
ridix
- barrierefreiheit
moin,
Vor kurzer Zeit habe ich ein Formular erstellt. Wie immer habe ich, ohne dabei viel zu überlegen eine Tabelle erstellt um das Formular optimal auszurichten.Doch nun stellt sich mir die Frage, ob man überhaupt noch ein Formular mit Tabellen ausrichten darf? Sollte man es unterlassen? Was für eine Alternative stellt sich mir?
MFG ridix
Hallo ridix,
Tabellen sind total "out", was CSS und moderne Webseiten angeht.
Schau dir mal hier bei SelfHtml das "Boxmodell" an und les dich in float und clear für Blocksätze ein (Div Boxen).
Gruß
Tabellen sind total "out", was CSS und moderne Webseiten angeht.
nein, tabellen waren niemals "out" - tabellen für tabellarische daten sind mehr als "in"
Doch nun stellt sich mir die Frage, ob man überhaupt noch ein Formular mit Tabellen ausrichten darf?
In einer Tabelle kann man die Positionierung der Zellen nicht per CSS ändern, anders als bei <div> mit float:left oder right.
Ich kann keinen Grund erkennen, warum die zugehörigen Texte zu den Eingabefeldern woanders stehen sollten als bei ihrem Feld.
Also lass es bei Tabellen. Wenn du unbedingt per CSS etwas machen möchtest (Breite, Schriftfarbe, Ausrichtung, ...) dann gib jedem <td> entsprechend seiner Stellung eine class=spalte01, ...02 usw.
Ich habe ohne Tabellen experimentiert und es kommt Schei... dabei heraus, wenn man zu stark zoomt. Dinge, die nebeneinander gehören, stehen dann untereinander. Es sei denn, man gibt dem umgebenden <div> eine feste Breite und imitiert eine Tabelle.
Nach dem Motto: "Warum einfach, wenn es auch umständlich geht?"
Kalle
In einer Tabelle kann man die Positionierung der Zellen nicht per CSS ändern, anders als bei <div> mit float:left oder right.
stimmt nicht ganz, die display-eigenschaften der tabellen-zellen lassen sich sehrwohl manipulieren
Ich kann keinen Grund erkennen, warum die zugehörigen Texte zu den Eingabefeldern woanders stehen sollten als bei ihrem Feld.
mit einem vernünftigen aufbau kann man folgendes machen
input
label
label input
input label
label
input
oder ganz anders - das geht mit tabellen nicht ;)
Also lass es bei Tabellen. Wenn du unbedingt per CSS etwas machen möchtest (Breite, Schriftfarbe, Ausrichtung, ...) dann gib jedem <td> entsprechend seiner Stellung eine class=spalte01, ...02 usw.
sehe ich nicht so
Ich habe ohne Tabellen experimentiert und es kommt Schei... dabei heraus, wenn man zu stark zoomt. Dinge, die nebeneinander gehören, stehen dann untereinander. Es sei denn, man gibt dem umgebenden <div> eine feste Breite und imitiert eine Tabelle.
dann hast du etwas falsch gemacht ;)
Nach dem Motto: "Warum einfach, wenn es auch umständlich geht?"
sag ich auch immer, also warum komplizierte tabellen - die dich in der freiheit die gestaltung zu beeinflussen einschränken und nicht gleich vernünftigen code?
Ich habe ohne Tabellen experimentiert und es kommt Schei... dabei heraus, wenn man zu stark zoomt. Dinge, die nebeneinander gehören, stehen dann untereinander.
Was ist daran schlimm? Das ist ein Feature von float im Vergleich zu Tabellen.
Ob das label nun links neben dem Eingabefeld liegt oder im Ausnahmefall, wenn eine Spaltendarstellung nicht möglich ist, darunter, ändert an der Funktionalität und Benutzbarkeit nichts.
Mathias
Ob das label nun links neben dem Eingabefeld liegt oder im Ausnahmefall, wenn eine Spaltendarstellung nicht möglich ist, darunter, ändert an der Funktionalität und Benutzbarkeit nichts.
wenn man mit relativen breitenangaben und schriftgrößen arbeitet, passiert auch das nicht
Was für eine Alternative stellt sich mir?
ordentliches html + css zu verwenden
http://forum.de.selfhtml.org/archiv/2008/10/t178016/#m1173158
http://forum.de.selfhtml.org/archiv/2008/4/t170239/#m1112679
Doch nun stellt sich mir die Frage, ob man überhaupt noch ein Formular mit Tabellen ausrichten darf?
Wenn es ein Formular für tabellarische Daten ist spricht nix dagegen
Hallo gast42!
Doch nun stellt sich mir die Frage, ob man überhaupt noch ein Formular mit Tabellen ausrichten darf?
Wenn es ein Formular für tabellarische Daten ist spricht nix dagegen
Ich bin noch keinem Formular begegnet, das _keine_ tabellarischen Daten enthalten hätte: Zu jedem Eingabefeld gehört ein LABEL-Element, welches gut in einer TH-(Table-Header)-Zelle aufgehoben ist und sich zeilen- oder spaltenweise auf ein Eingabefeld in einer TD-(Table-Data)-Zelle bezieht.
Natürlich kann man das auch gut mit einer Definitionsliste machen. Das wäre strukturell noch sinnvoller, da zu jeder Beschriftung (jedem LABEL-Element) ja immer nur genau ein Eingabefeld passt.
Wenn man aber etwa ein Datum mit drei Dropdowns für Tag, Monat und Jahr auswählen kann, so kann man die durchaus in drei verschiedene TD-Zellen packen, auf die sich eine TH-Zelle (spaltenweise mit rowspan="3", zeilenweise mit Default-rowspan="1") gemeinsam bezieht und in der ein LABEL-Element mit dem Text "Datum" sich nur auf das erste SELECT-Element für den Tag des Monats bezieht.
Der Missbrauch von Tabellen begönne nach meinem Dafürhalten erst, wenn diese drei Select-Elemente ihrerseits in einer verschachtelte Layout-Tabelle innerhalb der Datentabelle steckten.
Gruß Gernot
Hallo nochmal,
packen, auf die sich eine TH-Zelle (spaltenweise mit rowspan="3",
... hier meinte ich natürlich _spaltenweise mit colspan="3"_
Gruß Gernot
Ich bin noch keinem Formular begegnet, das _keine_ tabellarischen Daten enthalten hätte: Zu jedem Eingabefeld gehört ein LABEL-Element, welches gut in einer TH-(Table-Header)-Zelle aufgehoben ist und sich zeilen- oder spaltenweise auf ein Eingabefeld in einer TD-(Table-Data)-Zelle bezieht.
die meisten formulare beinhalten lediglich eine eingabemaske für daten, die nicht zwangsläufig in dieser form tabellarisch erfasst werden
man stelle sich ein kommentarfeld vor
benutzername
email
kommentar
jeder der das 1:1 so in der datenbank erfasst, ist wahnsinnig und verstößt wahrscheinlich gegen alle möglichen regeln des datenbankdesigns :) - wenn ich nicht irre aber widerspricht das jedenfalls der dritten normalform
die daten werden zerlegt und in getrennte tabellen gespeichert - der kommentar:
kommetarid benutzerid kommentartext
die benutzerdaten in eine andere tabelle:
benutzerid benutzername email
von der seite betrachtet entspricht die eingabemaske zwar "irgendwie" tabellarischen daten aber nicht zwangsläufig welchen die auch sinnvoll normailisiert wurden
Natürlich kann man das auch gut mit einer Definitionsliste machen. Das wäre strukturell noch sinnvoller, da zu jeder Beschriftung (jedem LABEL-Element) ja immer nur genau ein Eingabefeld passt.
nein, bei einer defintionsliste ist es sinn, dass zu jedem term beliebig viele definitionen existieren können, die nicht in zusammehang zueinander stehen bei tabellen sind es matritzen
zb
merkmale:
größen
1
2
3
farben
rot
blau
das ganze in einer tabelle abgebildet sähe so aus
merkmale
größe farbe
1 rot
2 rot
3 rot
1 blau
2 blau
3 blau
tabellarische daten sind nicht automatisch in defintionslisten transprotierbar und umgekehrt
eine zuordnung von lable zu input mittels dt -> dd ist genausowenig notwendig wie th -> td, da lable über das for-attribut ohnehin einen eindeutigen bezug herstellt
eine tabelle zur stukturierung eines formulars ist somit aus semantischer sicher nicht notwendig
Hallo suit,
eine zuordnung von lable zu input mittels dt -> dd ist genausowenig notwendig wie th -> td, da lable über das for-attribut ohnehin einen eindeutigen bezug herstellt
Das ist richtig, strukturell gesehen (mir widerstrebt hier als Linguisten der Ausdruck "semantisch") wäre das zwar meist doppelt gemoppelt ...
eine tabelle zur stukturierung eines formulars ist somit aus semantischer sicher nicht notwendig
... aber auch nicht falsch. Oft werden LABEL-Elemente ja auch von Links unterbrochen und da ergibt so eine Tabellenzeile (wahlweise auch ein DT- gefolgt von einem DD-Element innerhalb einer Definitionsliste) strukturell durchaus einen Sinn:
z.B.:
<tr>
<th>
<label for="termsAndConditionsRead">Ja, ich habe die</label>
<a href="agb.html">AGB</a>
<label for="termsAndConditionsRead">gelesen.</label>
</th>
<td>
<input type="checkbox" id="termsAndConditionsRead" name="termsAndConditionsRead" />
</td>
</tr>
Gruß Gernot
<label for="termsAndConditionsRead">Ja, ich habe die</label>
<a href="agb.html">AGB</a>
<label for="termsAndConditionsRead">gelesen.</label>
<label for="termsAndConditionsRead">Ja, ich habe die <a href="agb.html">AGB</a> gelesen.</label>
label darf auch a-elemente beinhalten
Hallo suit,
<label for="termsAndConditionsRead">Ja, ich habe die</label>
<a href="agb.html">AGB</a>
<label for="termsAndConditionsRead">gelesen.</label>
<label for="termsAndConditionsRead">Ja, ich habe die <a href="agb.html">AGB</a> gelesen.</label>
>
> label darf auch a-elemente beinhalten
Wenn dem tatsächlich so sein sollte, dann sollte man das schnellstens abschaffen:
Was hätte es für einen Sinn, wenn ich bei Klick auf ein in einem LABEL-Element enthaltenes A-Element unbeabsichtigt bereits ein Häkchen in einer Checkbox setze, mit der ich bestätige, dass ich die AGB, die zu lesen ich mit dem Klick erst beabsichtige, bereits gelesen habe?
So ein Formular wäre, abgesehen davon, dass es alles andere als barrierefrei wäre, auch juristisch anfechtbar; zumindest hierzulande und das ist auch gut so!
Gruß Gernot
--
[super me](http://community.de.selfhtml.org/my/visitenkarten/view.php?key=46)