| von subjective |
Man kann auch explizit CSS-Dateien für Screenreader angeben. Von daher ist die semantische Form (mit fieldset/label) dafür die Beste, weil sie die genauesten Informationen enthält.
Tabellen machen nur Sinn, wenn du die relative Ausrichtung der Zellen nutzen willst. Dies ist nur für normale sehende User. Die Sache mit der Liste würde ich nie verwenden. |
| von nisita |
na eben.. und da ist die tabelle, und deine lösung nicht das, was ich will.. der unterschied ist aber ja, dass wenn ich es "falsch" mache, und tabellen benutze, dass das auch gründe hat, warum es "falsch" ist.. bei der dl-liste, sehe ich die bis jetzt noch nicht..
| zB in einem screanreader vorgelesen wird |
da kommt bei beides das gleiche raus.. deine lösung halt nebeinander.. meine untereinander.. -denn die struktur bleibt ja bei der dl-liste erhalten..
mfg
nisita |
| von HoRnominatoR |
| die frage ist halt, ob das "erlaubt" ist, bzw. im sinne von dem, wozu es eigentlich da war / ist.. -bzw. ob sowas "schlimm" ist.. |
| denn am ende geht es doch nur darum, wie es der user bekommt.. ob die lite eigentlich für was anderes da war, ist ja eigentlich egal.. |
was denn nun? willst du es richtig machen, oder ist es dir egal? das ist genau wie mit den tabellen: entweder du machst es richtig, wie es erlaubt und erdacht ist, oder es ist dir egal, du machst es falsch und verwendest sie fuer das layout.
und: ja, es geht darum, wie es der user bekommt, da darfst du nicht allein grafisch denken, sondern musst dir die struktur ansehen, wie es linearisiert wird, wie es zB in einem screanreader vorgelesen wird, wie es ein blinder auf seiner braillezeile lesen wuerde. |
| von nisita |
danke ersmtal für diese alternative.. finde die allerdings, das beim surfen ohne css-datei, das ganze nicht mehr sehr klar -auch ist fraglich,
rüberkommt.. -deswegen fande ich das mit der dl-liste eigentlich ganz gut.. -die frage ist halt, ob das "erlaubt" ist, bzw. im sinne von dem, wozu es eigentlich da war / ist.. -bzw. ob sowas "schlimm" ist.. denn am ende geht es doch nur darum, wie es der user bekommt.. ob die lite eigentlich für was anderes da war, ist ja eigentlich egal..
mfg
nisita |
| von sondermuelli |
| wieso sollte es? dann sind alle werte wunderbar untereinander gelistet und somit auch einander zugeordnet |
eben nicht, sonst würde ich das ja gar nicht bemängeln. es sieht dann nämlich so aus:
| name: <eingabefeld> passwort: <eingabefeld> |
bei zwei feldern mag das noch kein problem sein; wenn es ein paar mehr werden, wird das schon unübersichtlich, es sei denn, man setzt genügend br-tags, wovon ich wiederum nicht so der freund bin.
| ich hoffe mal, es stoert dich nicht, das nochmal mit mir zu diskutieren. |
nein, kein problem. 
|
| von subjective |
| Naja ein Formular kann ein tabellerisches Layout haben - eine Tabelle ist es deswegen noch lange nicht. Eigentlich gibt es ja auch "display: table" und co damit sich andere Elemente wie Tabllenteile verhalten. Nur kann dies ein viel genutzter Browser nicht. |
| von HoRnominatoR |
| im selfhtml-forum wurde das schon zur genüge diskutiert und unter anderem auch wildeste div-suppen etc. präsentiert. |
ok, da halte ich mich seltener auf, so mit ein oder zwei postings. werde ich mir aber mal zu gemuete fuehren, hoert sich interessant an.
| das ist natürlich richtig. die notwendigkeit des labels kann man in diesem fall auf jeden fall verneinen. ob es einen sinn macht sei dahingestellt, ich würde es als "betonung" der zugehörigkeit betrachten. |
es ist aber keine betonung, es ist eine direkte zuordnung die sich auf ein element bezieht, label->input. fuer mich enthaelt eine tabellenzelle einen beliebigen datensatz, definiert durch den header.
| bei einem user hingegen, der ohne css, mit eigenem stylesheet, oder mit einem browser, der das css nicht zu sehen bekommt, surft, verliert es auf dem bildschirm gegenüber der tabelle durchaus an struktur. |
wieso sollte es? dann sind alle werte wunderbar untereinander gelistet und somit auch einander zugeordnet, man kann immernoch tabstops benutzen oder einfach mit der maus das naechste, in der uebernaechsten zeile, nach dem label fuer entsprechendes element, angeordnete inputfeld bedienen.
1:
2:
3:
4: | ihr name:
<<input
ihr passwort:
<<input |
aber wenn man den bsplen des w3c glauben darf, ist das wohl pillepalle
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.9
ich bezog mich auch wesentlich auf einen artikel bei einfach-fuer-alle.de (http://einfach-fuer-alle.de/artikel/formulare/) den ich vor einiger zeit mal gelesen habe und nach dem ich mich seitdem auch richte.
ich hoffe mal, es stoert dich nicht, das nochmal mit mir zu diskutieren. (sehr gern habe ich zumindest die diskussion 'tabellen oder nicht?' (http://www.webwork-community.net/posting4711_40_0.html) verfolgt - egal wie oft ich sie schon aktiv/passiv miterlebt habe) |
| von sondermuelli |
seh ich genauso. warum nicht mal anders versuchen und eventuell bessere wege finden.
zudem habe ich bisher leider keine diskussion diesbezueglich mitbekommen. |
im selfhtml-forum wurde das schon zur genüge diskutiert und unter anderem auch wildeste div-suppen etc. präsentiert.
| wenn man das label noch hinzuzieht, waere das ja, unter deinen gesichtspunkten mit einer tabelle, sogar eine doppelte zuordnung |
das ist natürlich richtig. die notwendigkeit des labels kann man in diesem fall auf jeden fall verneinen. ob es einen sinn macht sei dahingestellt, ich würde es als "betonung" der zugehörigkeit betrachten. 
| ausserdem verliert es keineswegs seine struktur - stichwort linearisierung von dokumenten. |
rein semantisch und im hinblick auf screenreader etc. betrachtet hast du recht. bei einem user hingegen, der ohne css, mit eigenem stylesheet, oder mit einem browser, der das css nicht zu sehen bekommt, surft, verliert es auf dem bildschirm gegenüber der tabelle durchaus an struktur.
ich bin ja mal gespannt, wie sich nisita entscheidet. |
| von HoRnominatoR |
| aber hey, ich hab noch keine diskussion diesbezüglich mitbekommen, wo zwei parteien sich einander angeglichen hätten. wichtig ist doch letztendlich vor allem auch, dass man sich überhaupt gedanken macht, wie man es sinnvoll umsetzen kann und es wäre ja fast traurig, wenn sich immer alle auf _einen_ königsweg einigen würden. |
seh ich genauso. warum nicht mal anders versuchen und eventuell bessere wege finden.
zudem habe ich bisher leider keine diskussion diesbezueglich mitbekommen.
| und spätestens wenn in deiner variante das css wegfällt verliert das ganze seine für den user sichtbare struktur. |
sehe ich nicht so. wenn man das label noch hinzuzieht, waere das ja, unter deinen gesichtspunkten mit einer tabelle, sogar eine doppelte zuordnung, wenn man rein semantisch denkt, was unter anderem ja braillezeilen und screanreader tun (zuordnung durch label + zuordnung durch tabelle). zudem sollte man zu einer tabelle ja auch entsprechende tabellenkoepfe setzen. ausserdem verliert es keineswegs seine struktur - stichwort linearisierung von dokumenten. |
| von sondermuelli |
| tabellen sind ungeeignet, inputfelder werden durch ihr label bestimmt, nicht durch ihre zugehoerigkeit zu irgendeinem undefinierten datensatz. |
darüber kann man trefflich streiten - und wird auch immer wieder
das label hatte ich bereits ins spiel gebracht. und wie gesagt, den tabellenhaften charakter von formularen halte _ich_ für eindeutig gegeben. es wird der (einzutragende) wert aus dem eingabefeld in der rechten spalte, dem wert in der linken spalte zugewiesen.
und spätestens wenn in deiner variante das css wegfällt verliert das ganze seine für den user sichtbare struktur.
aber hey, ich hab noch keine diskussion diesbezüglich mitbekommen, wo zwei parteien sich einander angeglichen hätten. wichtig ist doch letztendlich vor allem auch, dass man sich überhaupt gedanken macht, wie man es sinnvoll umsetzen kann und es wäre ja fast traurig, wenn sich immer alle auf _einen_ königsweg einigen würden. |
| von HoRnominatoR |
weder noch. wenn du absolut semantische dokumente schreibst, stehen dir genug elemente zur strukturierung zur verfuegung:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10: |
<form>
<fieldset>
<legend>logindaten</legend>
<label for="name">name:<label>
<input id="name" type="text" name="name" />
<label for="passwort">passwort:<label>
<input id="passwort" type="text" name="passwort" />
</fieldset>
</form> |
einfach label und input als display:block definieren, width=50% und float:left - dann fliessen alle elemente schoen unter- bzw nebeneinander
edit:
@sondermuelli
tabellen sind ungeeignet, inputfelder werden durch ihr label bestimmt, nicht durch ihre zugehoerigkeit zu irgendeinem undefinierten datensatz. |
| von sondermuelli |
| für mich wäre die entscheidung ganz klar: nimm ne tabelle. und zwar nicht nur wegen der einfachen handhabbarkeit, sondern vor allem weil meiner ansicht nach formulare - auch dieses - eindeutig tabellarische daten sind. um die zugehörigkeit bezeichnung - eingabefeld noch semantisch zu untermalen, kannst du die bezeichnung ja noch in ein label-tag setzen. |
| von nisita |
hallo, wie jeder weiß sollen tabellen nur wenn dringend notwenig genutzt werden.. und wie manche vielleicht wissen, schreibe ich ja gerade mein xhtml-forum, und bin dabei auf ein problem gestoßen..
z.b. wenn bei der login seite.. wollte halt "benutzername" und "passwort" auf der selben höhe haben, wie die eingebaefelder dazu.. habe da ja nun mehrere möglichkeiten..
1.mit einer tabelle..
2.2 divs, eine flaotet rechts, andere links..
3.mit definitionslisten.. 1: | <dl><dt>Benutzername:</dt><dd>eingabefeldname</dd><dt>Passwort:</dt><dd>eingabefeldpw</dd></dl> |
zu1. struktur geht total verloren..
zu2. wie 1. nur, dass man wohl noch weniger "versteht".. (also ohne stylesheet..)
zu3. definitionslisten, sind nunmal nicht für sowas gedacht..
so, und was nun??? oder hat jmd. eine andere alternative???
mfg
nisita
PS:bei der loginseite, kann man sich streiten, ob es wirklich wichtig ist, dass beides nebeinander steht.. aber es gibt ja in einem forum noch mehr punkte, wo man sich diese frage stellen muss..
---
"Wir sollten lernen, uns allmählich vom Überfluss zu befreien, um zur Einfachheit unseres eigenen Wesens vorzudringen." Jean Gastaldi |
|
