Tabellen in Formularen

[Jörg]

Guten Tag,

ich habe eine reine HTML Frage.

Wenn ich einen User aus mehreren tabellen Informationen auswählen lassen möchte, die er in einem Formular dann an den Server senden soll, wäre folgende Notation dann valides html?

<form action="Script URL" method="GET|POST">
    <table>
        <tr><td></td></tr>
    </table>
    <table>
        <tr><td></td></tr>
    </table>
    <table>
        <tr><td></td></tr>
    </table>
<input type="submit" value="Absenden" />
</form>

Jörg

[Gunnar Bittersmann]

@@Jörg

Wenn ich einen User aus mehreren tabellen Informationen auswählen lassen möchte, die er in einem Formular dann an den Server senden soll, wäre folgende Notation dann valides html?

<form action="Script URL" method="GET|POST">
    <table>
        <tr><td></td></tr>
    </table>
    <table>
        <tr><td></td></tr>
    </table>
    <table>
        <tr><td></td></tr>
    </table>
<input type="submit" value="Absenden" />
</form>

Ja.

Aber warum <input type="submit" value="Absenden" />?

Besser <button type="submit">Absenden</button>. Wobei type="submit" Default ist, also entfallen kann.

😷 LLAP

[Jörg]

Hi Gunnar,

Ja.

Ok, gut zu wissen. Danke. 👍

Aber warum <input type="submit" value="Absenden" />?

Besser <button type="submit">Absenden</button>. Wobei type="submit" Default ist, also entfallen kann.

Gibts einen Grund dafür, dass das besser ist?

Jörg

[Gunnar Bittersmann]

@@Jörg

Aber warum <input type="submit" value="Absenden" />?

Besser <button type="submit">Absenden</button>. Wobei type="submit" Default ist, also entfallen kann.

Gibts einen Grund dafür, dass das besser ist?

Mehrere.

Da wäre nunächst einmal sprechender Code. <input type="submit"> sieht man nicht auf den ersten Blick an, dass es sich nicht um ein Eingabefeld, sondern um einen Button handelt. Dazu muss man schon noch einen zweiten Blick werfen – aufs Attribut. <button> hingegen ist selbsterklärend.

Noch entscheidender ist aber, dass die Beschriftung des Buttons nicht wie bei <input type="submit" value="Absenden" /> in einem Attribut steckt, sondern im Elementinhalt: <button>Absenden</button>. Das hat mehrere Vorteile:

Eine Buttonschriftung kann Markup enthalten:
<button><b>Jetzt</b> absenden!!!</button>
oder
<button>Absenden <img src="pfeil.svg" alt=""/></button>
oder
<button>Absenden <svg>…</svg></button>

Außerdem ignorieren automatische Übersetzer womöglich Attributwerte. (Was auch dafür spricht, eher aria-labelledby statt aria-label einzusetzen.)

Das trifft auch auf Alternativtexte für Bilder (alt-Attribute) zu. Da hat es ein Schnellschuss von Marc Adreesen in die HTML-Spezifikation geschafft. Inhalt in Attributen ist nie™ eine gute Idee, s.a. dieses Posting.

Dieser Sprachdesignfehler ist jetzt nicht mehr auszumerzen. Bei anderen Elementen wie object wurde es dann richtig gemacht: textuelle Alternative als Elementinhalt.

😷 LLAP

[Jörg]

Oh, das sind wirklich viele Vorteile, da habe ich dann jetzt Einiges zu ändern, denn ich verwende bisher immer den Typ:input.

Ich habe noch eine Frage zum Thema:

Wie bekomme ich den Button innerhalb des form-elements horizontal mittig plaziert? Bisher hatte ich den einfach auch in einer Tabellenzeile, da war das dann easy.

Nun hätte ich den Button aber gerne außerhalb der Tabelle und da schaff ichs bisher nur mit margin-left und das kann ja keine Lösung für mich sein.

Jörg

[Gunnar Bittersmann]

@@Jörg

Wie bekomme ich den Button innerhalb des form-elements horizontal mittig plaziert?

Nun hätte ich den Button aber gerne außerhalb der Tabelle und da schaff ichs bisher nur mit margin-left und das kann ja keine Lösung für mich sein.

Doch. Nur halt nicht mit festem Wert, sondern: auto. Und du musst auch margin-right setzen.

margin: auto zentriert Blockelemente. Also den button zu einem solchen gemacht:

button {
  display: block;
  margin: auto
}

Schön wär’s gewesen, man hätte hier einfach aufs Wiki verweisen können. Aber irgendwer hat den Artikel verunstaltet. ☹️

😷 LLAP

[Jörg]

Hi Gunnar,

button {
  display: block;
  margin: auto
}

Joa, danke. Würde auch funktionieren, wenn nicht die komplette Seite innerhalb einer Tabelle stecken würde (da hab ich keinen Einfluss drauf) und ein text-align:left der tabelle das margin:auto dadurch verhindert.

Jörg

[Matthias Scharwies]

Servus! @Gunnar Bittersmann @Der Martin @all

margin: auto zentriert Blockelemente. Also den button zu einem solchen gemacht:

button {
  display: block;
  margin: auto
}

Schön wär’s gewesen, man hätte hier einfach aufs Wiki verweisen können. Aber irgendwer hat den Artikel verunstaltet. ☹️

Ja, ich habe die Verbergen-Vorlage, die den Zugriff auf die Unterkapitel verhindert hatte, entfernt. Das kam aus einer Zeit als SELFHTML nur die beste Lösung präsentieren wollte und den Rest „depublizieren“ wollte. Das hatten wir bei input type="image" auch.

Ich wollte eigentlich margin: 0 auto; durch die logische Eigenschaftenmargin-inline: auto; ergänzen, möchte den Artikel aber nun neu aufbauen.

Chris Coyier zeigt oft, wie er versucht zu einer Lösung zu kommen und dokumentiert dabei auch seine Zwischenschritte. Problem ist ja, dass man sowohl für margin: auto als auch text-align:center immer zusätzliche CSS-Eigenschaften benötigt. Da die aber oft sowieso vorhanden sind, würde ich die gar nicht ausschließen, sondern eben dokumentieren wollen.

bis jetzt:

Beachten Sie: Diese Vorgehensweise sollte nur verwendet werden, wenn …

• die Breite des Inhalts vorher bekannt ist

Künftig: Was haltet ihr nach jedem Beispiel von:

Fazit

• margin: auto benötigt zusätzlich
• eine Breitenangabe des Inhalts (die z.B. bei body oft schon vorhanden ist.)

Für ein Feedback wäre ich dankbar - ich würde das dann in der Faschingswoche umsetzen.

Herzliche Grüße

Matthias Scharwies

---

Ich schau immer mal in der alten Doku und träume ja davon, die zum einem Jubiläum als statische Kopie wieder zu veröffentlichen. Dieser Abschnitt zeigt, dass das eben nicht (mal mit nenm Disclaimer) zu empfehlen ist:

Wie kann ich Inhalte genau in der Mitte des Anzeigefensters positionieren?

Um Blockelemente zu zentrieren, setzen Sie den linken und rechten Seite Außenabstand auf den Wert auto:

margin-left:auto;
margin-right:auto;

Beachten Sie, dass der Internet Explorer 6 diese Angaben nur dann interpretiert, wenn die Seite im Seite standardkonformen Modus dargestellt wird.

Soll ein Element sowohl horizontal als auch vertikal zentriert werden, bietet sich eine Lösung mit absoluter Seite Positionierung an:

---

[Tabellenkalk]

Hallo,

---

Ich schau immer mal in der alten Doku und träume ja davon, die zum einem Jubiläum als statische Kopie wieder zu veröffentlichen. Dieser Abschnitt zeigt, dass das eben nicht (mal mit nenm Disclaimer) zu empfehlen ist:

Wenn ich mich nicht irre, gab es die auch mal in Buchform. Wenn davon ein Foto existiert, könnte das ja stattdessen gezeigt werden!?

Gruß
Kalk

[Raketenwilli]

HTML-Formal nicht falsch, aber die Semantic ist fürchterlich, die Sprachausgabe ein Grauen. Oft ist es besser, <label> zu verwenden, was vor allem dann gilt, wenn die Tabelle nur missbraucht wird, um die Einrückungen vorzunehmen.

HTML:

    <label for="zuname">Nachname:</label>  
    <input type="text" name="nachname" id="nachname" maxlength="40">
    <br>
    <label for="zuname">Vorname:</label>  
    <input type="text" name="vorname" id="vorname" maxlength="40">
    <br>
    <label for="sendbutton"></label>
    <button id="sendbutton">senden</button>
    

(Das „for“ bezieht sich auf die ID des Input-Elements)

CSS:

label[for=nachname],
label[for=vorname],
label[for=sendbutton]
{
    display: inline-block;
    width:   10rem;
}

Ein Vorteil ist auch, dass die Ausgabe auf einem schmalen Screen (Smartphone!) umgebrochen wird, wenn beides nicht auf eine Zeile passt.

Möglicherweise willst Du das aber für alle erzwingen (Manche Inputs sind ja schmal…): Dann kannst Du mit Media-Rules hantieren:

@media all {
  label[for=nachname],
  label[for=vorname]
  {
    display: block;
  }
}

@media only screen and (min-width: 60rem) {
  label[for=nachname],
  label[for=vorname]
  {
    display: inline-block;
    width:   10rem;
  }

  label[for=sendbutton] {
    display: none;
  }
}

(Ich habe das „blind“, also ohne Tests notiert. Der Quelltext kann fehlerhaft sein, die Werte musst Du sowieso anpassen.)

[Gunnar Bittersmann]

@@Raketenwilli

HTML-Formal nicht falsch, aber die Semantic ist fürchterlich

Nicht für tabellarische Daten.

Oft ist es besser, <label> zu verwenden

Eingabefelder sollten selbstverständlich beschriftet sein. Nicht nur oft, sondern immer.

was vor allem dann gilt, wenn die Tabelle nur missbraucht wird, um die Einrückungen vorzunehmen.

Das hatte ich im hiesigen Fall nicht so verstanden. Ich denke, es ist sowas gemeint:

<form>
  <table>
    <tbody>
      <tr>
        <td>
          <label …>…</label>
          <input …/>
        </td>
        <td>
          <label …>…</label>
          <input …/>
        </td>
      </tr>
      <tr>
        <td>
          <label …>…</label>
          <input …/>
        </td>
        <td>
          <label …>…</label>
          <input …/>
        </td>
      </tr>
    </tbody>
  </table>
  <button>…</button>
</form>

---

label[for=nachname],
label[for=vorname]
{
    display: inline-block;
    width:   10rem;
}

Die Beschriftungen sollten besser über den Eingabefeldern stehen, nicht links davon.

😷 LLAP

[Raketenwilli]

Eingabefelder sollten selbstverständlich beschriftet sein. Nicht nur oft, sondern immer.

Nicht nur Innenminister wollen eine Löschtaste haben - Dir würde ich gerne eine geben, um die Millionen von falschen/veralteten Beispielen aus dem Web zu putzen, in denen Tabellen für die Positionierung von Formularelementen und deren Beschriftung missbraucht werden… (Nachtrag: Meine Generation war sehr fleißig, als es im vorigen Jahrtausend anders kaum oder nicht ging und wurde dann auch noch abgeschrieben als es besser ging.)

Deshalb habe ich die Glaskugel benutzt. Ob ich mit der Vermutung richtig liege weiß (bis jetzt) nur der TO.

[Gunnar Bittersmann]

@@Raketenwilli

… nur der TO.

TO, wir fahrn nach Łódź!

😷 LLAP

[Raketenwilli]

@@Raketenwilli

… nur der TO.

TO, wir fahrn nach Łódź!

Klar. Auf ein lokales Heineken.

[Raketenwilli]

Mist!

    <label for="zuname">Nachname:</label>  
    <input type="text" name="nachname" id="nachname" maxlength="40">
    <br>
    <label for="zuname">Vorname:</label>  
    <input type="text" name="vorname" id="vorname" maxlength="40">
    <br>
    <label for="sendbutton"></label>
    <button id="sendbutton">senden</button>
    

Besser:

     <label for="nachname">Nachname:</label>  
     <input type="text" name="nachname" id="nachname" maxlength="40">
     <br>
     <label for="vorname">Vorname:</label>  
     <input type="text" name="vorname" id="vorname" maxlength="40">
     <br>
     <label for="sendbutton"></label>
     <button id="sendbutton">senden</button>

(Eines der „for“-Attribute hatte den falschen Wert.)

Edit Rolf B: Nein, zwei. Ich habe das zweite mal korrigiert.

[Gunnar Bittersmann]

@@Raketenwilli

(Eines der „for“-Attribute hatte den falschen Wert.)

Protip: Als angemeldeter Nutzer kann man seine Beiträge nachträglich editieren. 😉

😷 LLAP

[Raketenwilli]

Protip: Als angemeldeter Nutzer kann man seine Beiträge nachträglich editieren.

Länger als mit dem Cookie?

[Gunnar Bittersmann]

@@Raketenwilli

Protip: Als angemeldeter Nutzer kann man seine Beiträge nachträglich editieren.

Länger als mit dem Cookie?

Hm, weiß nicht. Ich kann. Das könnte aber an meinen Moderator-Rechten liegen.

😷 LLAP

[Rolf B]

Hallo Gunnar,

ja, mit Mod-Recht kann man immer editieren.

Für die Normalsterblichen hängt es, glaube ich, daran, ob eine Antwort vorliegt. Unbeantwortete Beiträge können 30 Minuten lang editiert werden, aber wenn eine Antwort da ist, kann man nicht mehr editieren. Es gibt da auch keine unterschiedlichen Einstellungen für Gäste und User. Aber ob eine Antwort den Edit verhindert, ist eine Verwaltungs-Einstellung, aus deren Text ich nicht recht schlau werde.

Da steht die Option Default-Wert, und dahinter in Klammern der Wert, der als Default gilt und woher er kommt. So weit, so logisch. Bei der ersten Radiogruppe scheint es auch zu passen. Aber was heißt bei der zweiten Radiogruppe "ja"? Editierbar bis zur ersten Antwort oder immer editierbar? Ja! Ähhh…

@Christian Kruse, wie muss man das deuten?

Rolf

[Raketenwilli]

Scheinbar (gemäß meiner Erfahrung) gilt für unangemeldete Autoren mit Cookie:

• Editierbar bis zur [zum Speichern der] ersten Antwort, dazu kommt aber eine Zeitbegrenzung.

[Rolf B]

Hallo Raketenwilli,

ich denke, das gilt für angemeldete User genauso.

Rolf

[Matti Mäkitalo]

Hallo,

hast du einen bestimmten Grund, warum du eine Tabelle mit CSS und br's nachbaust, obwohl du auch einfach CSS Grid verwenden könntest?

VG Matti

[Raketenwilli]

hast du einen bestimmten Grund, warum du eine Tabelle mit CSS und br's nachbaust,

Ich „baue“ ja mit Absicht und Bedacht gerade KEINE Tabelle…