wie erstellen? tabellenlose formulare ohne feste Breite

[Skeeve]

Moin!

Ich weiß nicht, wie ich das hinbekommen soll. Wenn man mit Tabellen fürs Layout von Formularen arbeitet, dann ist es keon Problem:

  
<!-- vereinfachte Darstellung -->  
<form>  
  <table>  
    <tr>  
      <td>  
        Labeltext Frage 1  
      </td>  
      <td>  
        <input name="Frage1">  
      </td>  
    </tr>  
    <tr>  
      <td>  
        Labeltext Frage 2  
      </td>  
      <td>  
        <input name="Frage2">  
      </td>  
    </tr>  
  </table>  
</form>  

Nun würde ich gerne auf solche Tabellen verzichten und habe nach Möglichkeiten dazu im Netz gesucht. Das zugrundeliegende HTML gefällt mir auch. Das sähe in etwa so aus:

  
<form>  
  <fieldset>  
    <label for="idFrage1">  
      Labeltext Frage 1  
    </label>  
    <input name="Frage1" id="idFrage1">  
    <label for="idFrage2">  
      Labeltext Frage 2  
    </label>  
    <input name="Frage2" id="idFrage2">  
  </fieldset  
</form>  

Allerdings finde ich das CSS, das dazu geboten wird, furchtbar. Es wird grundsätzlich mit float für die labels gearbeitet und es werden feste Breiten vorgegeben.weil immer feste Breiten vorgegeben werden. Auf einer Seite steht gar: "attempts at relative widths using ems or percentages were met with browser rendering problems"

Nun frage ich Euch, als ausgewiesen Spezialisten: Wie macht Ihr das? Wie formatiert Ihr Formulare, ohne Tabellen zu verwenden?

-- Skeeve

[D.R.]

Hallo,

Allerdings finde ich das CSS, das dazu geboten wird, furchtbar. Es wird grundsätzlich mit float für die labels gearbeitet und es werden feste Breiten vorgegeben.

Sofern diese „feste Breite“, passend zur Schrift in „em“ angegeben wird, sehe ich da keine Probleme.

Nun frage ich Euch, als ausgewiesen Spezialisten: Wie macht Ihr das? Wie formatiert Ihr Formulare, ohne Tabellen zu verwenden?

Mit float und festem Breiten in „em“. Alternativ kann man natürlich auch weitgehend auf Formatierungen verzichten.

mfg. Daniel

[Skeeve]

Moin!

Sofern diese „feste Breite“, passend zur Schrift in „em“ angegeben wird, sehe ich da keine Probleme.

Angeblich schon. Siehe verlinkte Seite.

-- Skeeve

[wahsaga]

hi,

Sofern diese „feste Breite“, passend zur Schrift in „em“ angegeben wird, sehe ich da keine Probleme.
Angeblich schon. Siehe verlinkte Seite.

Die dortige Aussage

"attempts at relative widths using ems or percentages were met with browser rendering problems"

ist nicht sonderlich konkret - eher das Äquivalent einer "funzt nicht"-Problembeschreibung.

Ob es problematisch ist und in wie fern, dürfte auf den Einzelfall ankommen.
Versuch macht kluch :-)

gruß,
wahsaga

[D.R.]

Hallo,

Sofern diese „feste Breite“, passend zur Schrift in „em“ angegeben wird, sehe ich da keine Probleme.
Angeblich schon. Siehe verlinkte Seite.

Ich habe die Seite nicht erstellt ;-)

mfg. Daniel

[Gernot Back]

Hallo Skeeve,

Ich weiß nicht, wie ich das hinbekommen soll. Wenn man mit Tabellen fürs Layout von Formularen arbeitet, dann ist es keon Problem:

Nun würde ich gerne auf solche Tabellen verzichten...

Nun frage ich Euch, als ausgewiesen Spezialisten: Wie macht Ihr das? Wie formatiert Ihr Formulare, ohne Tabellen zu verwenden?

Wieso denn bei Formularen auf Tabellen verzichten? Gerade Formulare sind doch der klassische Fall von tabellarischen Daten und da sind Tabellen, wenn man mal von der Definitionsliste als Alternative absieht, geradezu zwingend geboten: Du hast TH- bzw. DT-Elemente, welche die LABEL-Elemente aufnehmen und INPUT- bzw. SELECT-Elemente, die in TD- bzw. DD-Element mit strukturellem ("semantischem") Markup gut aufgehoben sind.

Gruß Gernot

[wahsaga]

hi,

Gerade Formulare sind doch der klassische Fall von tabellarischen Daten und da sind Tabellen, wenn man mal von der Definitionsliste als Alternative absieht, geradezu zwingend geboten: Du hast TH- bzw. DT-Elemente, welche die LABEL-Elemente aufnehmen und INPUT- bzw. SELECT-Elemente, die in TD- bzw. DD-Element mit strukturellem ("semantischem") Markup gut aufgehoben sind.

Wenn man Text und Formularelement ins Label verfrachtet, dann hat man m.E. schon genug "Zusammenhang" hergestellt.
Da nochmal 'ne Tabelle drumzuschustern, sehe ich weniger ein.

gruß,
wahsaga

[Gernot Back]

Hallo wahsaga,

Wenn man Text und Formularelement ins Label verfrachtet, dann hat man m.E. schon genug "Zusammenhang" hergestellt.
Da nochmal 'ne Tabelle drumzuschustern, sehe ich weniger ein.

aber wär's denn strukturell ("semantisch") schädlich? Was spräche dagegen, wenn es darüber hinaus auch noch der bündigen Optik dient?

Gruß Gernot

[wahsaga]

hi,

Da nochmal 'ne Tabelle drumzuschustern, sehe ich weniger ein.

aber wär's denn strukturell ("semantisch") schädlich? Was spräche dagegen, wenn es darüber hinaus auch noch der bündigen Optik dient?

Mehr Markup als nötig?

gruß,
wahsaga

[Gernot Back]

Hallo wahsaga,

aber wär's denn strukturell ("semantisch") schädlich? Was spräche dagegen, wenn es darüber hinaus auch noch der bündigen Optik dient?

Mehr Markup als nötig?

Es gibt Typen von INPUT-Elementen, die meist in Gruppen auftreten. Die Checkbox und der Radiobutton sind solche Kandidaten. Die schreien dann geradezu danach, nicht nur jeweils ihr eigenes Label zu haben sondern auch eine gemeinsame, übergreifende Bezeichnung für ihre Gruppe.

Nun magst du einwenden, dass dazu das FIELDSET- in Verbindung mit dem LEGEND-Element gedacht ist, aber wenn TH-Elemente in Tabellen das gleiche leisten und darüber hinaus auch noch die Gleichrangigkeit bzw. hierarchische Abstufung zu anderen Gruppen von bzw. zu einzelnen Eingabefeldern kennzeichnen, sind diese doch sowieso auch aus reinen Markup-Gesichtspunkten geboten und man kann dann eher auf das FIELDSET-Element verzichten.

Gruß Gernot

[David]

Hallo Skeeve,

ich verpacke das ganze in eine Liste (ol):

  
<form>  
  <fieldset>  
    <ol class="inputs">  
      <li>  
        <label for="idFrage1">Labeltext Frage 1</label>  
        <input type="text" name="Frage1" id="idFrage1">  
      </li>  
      <li>  
        <label for="idFrage2">Labeltext Frage 2</label>  
        <input type="text" name="Frage2" id="idFrage2">  
      </li>  
      <li>  
        <label for="idFrage3">Labeltext Frage 3</label>  
        <input type="text" name="Frage3" id="idFrage3">  
      </li>  
    </ol>  
  </fieldset>  
</form>  

Das ist semantisch - denke ich - ok.

Die Listitems bekommen eine relativ große line-height; dadurch werden die labels und die Eingabeelemente vertikal schön zueinander ausgerichtet. Damit sich das li-Element mit dem label vergrößert wird overflow:auto definiert. Das führt im Internet Explorer leider nicht zum gewünschten Ergebnis (bis 6 auf jeden Fall, 7 weiß ich gerade nicht auswendig), deshalb wird mittels eines beliebigen Hacks für den IE wieder overflow:visible definiert.

  
form ol.inputs li {  
  line-height: 2em;  
  overflow: auto;  
}  
* html form ol.inputs li {  
  overflow: visible;  
}  

Die labels werden gefloatet und bekommen eine Breite in Prozent oder em. Dazu richte ich den Text rechtsbündig aus, damit die Labels optisch besser mit den Eingabeelementen zusammenhängen.

  
form ol.inputs label {  
  float: left;  
  padding: .2em 2%;  
  text-align: right;  
  width: 40%;  

die Eingabeelemente bekommen den entsprechenden margin-left und display:block, außerdem setze ich die selbe font-size wie für die umgebenden Elemente.

  
form ol.inputs input,  
form ol.inputs select,  
form ol.inputs textarea {  
  display: block;  
  font-size: 1em;  
  margin-left: 44%;  
}  

Es gab übrigens mal eine Untersuchung, die gezeigt hat, dass Formulare, bei denen die labels über den inputs stehen, am schnellsten zu bedienen seien. Den Link habe ich gerade nicht zur Hand. Also einfach für labels, inputs, selects und textareas display:block definieren.

schönen Gruß,
David

[David]

Hatte da noch was für den IE vergessen:
Man muss den Listitems auch noch eine Höhe zuweisen.

  
* html form ol.inputs li {  
  overflow: visible;  
  height: 1px;  
  ^^^^^^^^^^^^  
}  

schönen Gruß,
David