Problem mit div Tag

[jbaben]

Hallo,

mit dem gezeigten HTML-Code habe ich ein Problem mit der Änderung vom Abstand zwischen den beiden Eingabe-Feldern. Das hintere Eingabe-Feld soll nur mit einem gerineren Abstand und auf gleicher Höhe folgen. von welchem Wert hängt der Abstand ab ?

<div style="margin:24px 0; display:flex; align-items:flex-start; gap25:px;">
    <div style="flex:1;">
      <strong>City/Town:</strong><br>
      <input type="text" name="addr_city" maxlength="30"
             style="width:79%; height:52px; font-size:30px; font-family:'Courier New',monospace;
                    letter-spacing:3px; text-transform:uppercase; padding:8px 5px;
                    border:3px solid #000; background:white;">
    </div>
    <div style="width:170px;">
      <strong style="display:block; text-align:center; margin-bottom:4px;">Postal code</strong>
      <input type="text" name="addr_postalcode" maxlength="4" placeholder=""
             style="width:100%; height:52px; font-size:30px; font-family:'Courier New',monospace;
                    text-align:left; padding:8px 5px; border:3px solid #000; background:white;">
       </div>
  </div>

Juergen B.

[Ryuno-Ki]

Moin jbaben,

mit dem gezeigten HTML-Code habe ich ein Problem mit der Änderung vom Abstand zwischen den beiden Eingabe-Feldern. Das hintere Eingabe-Feld soll nur mit einem gerineren Abstand und auf gleicher Höhe folgen. von welchem Wert hängt der Abstand ab ?

<div style="margin:24px 0; display:flex; align-items:flex-start; gap:25px;">
    <div style="flex:1;">
      <strong>City/Town:</strong><br>
      <input type="text" name="addr_city" maxlength="30"
             style="width:79%; height:52px; font-size:30px; font-family:'Courier New',monospace;
                    letter-spacing:3px; text-transform:uppercase; padding:8px 5px;
                    border:3px solid #000; background:white;">
    </div>
    <div style="width:170px;">
      <strong style="display:block; text-align:center; margin-bottom:4px;">Postal code</strong>
      <input type="text" name="addr_postalcode" maxlength="4" placeholder=""
             style="width:100%; height:52px; font-size:30px; font-family:'Courier New',monospace;
                    text-align:left; padding:8px 5px; border:3px solid #000; background:white;">
       </div>
  </div>

(Ich hab das gap: 25px korrigiert hier).

Du legst für das hintere <div> eine Breite von 170px fest (flex-basis wäre meiner Meinung nach angemessener). Damit greift flex:1; beim vorderen <div> und nimmt den restlichen Raum ein.

Innerhalb des ersten <div> wird das <input /> eine Breite von 79% einnehmen. Hier könntest du beispielsweise auch auf 100% gehen. Dann wäre das gap für den Abstand verantwortlich.

Gruß,

[Gunnar Bittersmann]

@@Ryuno-Ki

Ich hätte mit meiner Minus-Bewertung wohl warten sollen, bis ich den Grund dafür dazugeliefert habe. Jetzt hat dir irgendwer noch einen Pluspunkt verpasst – unverdient, wie ich finde. Deine Antwort doktort an Symptomen des Übels herum, ohne auf die grundsätzlichen Probleme einzugehen. Nicht wirklich hilfreich.

🖖 Live long and prosper

[Ryuno-Ki]

Moin Gunnar,

Ich hätte mit meiner Minus-Bewertung wohl warten sollen, bis ich den Grund dafür dazugeliefert habe.

Das Thema hatten wir jetzt bereits einige Male. Ich vertrete eine andere Auffassung was helfen angeht.

Jetzt hat dir irgendwer ncoh einen Pluspunkt verpasst – unverdient, wie ich finde.

🤷

Deine Antwort doktort an Symptomen des Übels herum, ohne auf die grundsätzlichen Probleme einzugehen. Nicht wirklich hilfreich.

Es war immerhin kein TailwindCSS. Inline-Styles hier waren insofern hilfreich, als dass ich den Code direkt in eine HTML-Seite injizieren konnte, ohne mich auch noch um CSS-Konflikte sorgen zu müssen. Sauberer Stil geht anders. Aber dann sollte Web-Technologie ja auch insofern zugänglich sein, als dass eins nicht erst studiert haben muss, um sie einsetzen zu können.

Wenn es um „sauberes Markup” ginge, würde ich eine entsprechende Frage erwarten.

Ich verweise auf mein Eingangs-Statement in der Antwort.

Gruß,

[Gunnar Bittersmann]

@@Ryuno-Ki

Wenn es um „sauberes Markup” ginge, würde ich eine entsprechende Frage erwarten.

Es geht immer um sauberes Markup, denn das ist die Grundlage für alles andere. Insbesondere für das Funktionieren der Webseite.

Und nein, man kann entsprechende Fragen dazu nicht erwarten. Wenn Juergen label gekannt hätte, hätte er es eingesetzt, nicht danach gefragt. Die Berichtungung von fehlerhaften Markup gehört zu einer guten Antwort dazu.

🖖 Live long and prosper

[Ryuno-Ki]

Moin Gunnar,

Wenn es um „sauberes Markup” ginge, würde ich eine entsprechende Frage erwarten.

Es geht immer um sauberes Markup, denn das ist die Grundlage für alles andere. Insbesondere für das Funktionieren der Webseite.

Mit dem Mindset hätte sich XHTML durchgesetzt 😇 Versteh mich nicht falsch, ich bin durchaus ein Freund davon. Nur: die Realität sieht anders aus.

Und nein, man kann entsprechende Fragen dazu nicht erwarten. Wenn Juergen label gekannt hätte, hätte er es eingesetzt, nicht danach gefragt.

Warten wir doch auf eine Reaktion von Juergen, bevor es zu Vermutungen kommt.

Die Berichtungung von fehlerhaften Markup gehört zu einer guten Antwort dazu.

Ich bin eher an einer praktischen Antwort interessiert. Die „gute”, wenngleich lobenswert, fügt mir zu viel Clutter hinzu.

Gruß,

[Gunnar Bittersmann]

@@Ryuno-Ki

Es geht immer um sauberes Markup, denn das ist die Grundlage für alles andere. Insbesondere für das Funktionieren der Webseite.

Mit dem Mindset hätte sich XHTML durchgesetzt 😇

Mit „sauber“ meine ich hier nicht stilistische Feinheiten. Ich ziehe auch XML-Syntax vor, würde Attribute ohne explizite Wertzuweisung o.ä. aber nicht als Fehler ankreiden.

Fehlende label sind aber keine stilistische Feinheit, denn das betrifft das Funktionieren der Webseite. Ohne zugeordnete Beschriftung sind die Eingabefelder für etliche Nutzer unbedienbar – und das gehört in einer Antwort gesagt.

🖖 Live long and prosper

[Gunnar Bittersmann]

@@jbaben

mit dem gezeigten HTML-Code habe ich ein Problem

Mehrere.

Zunächst einmal haben die Eingabefelder keine Beschriftung. Visuell ist das was, es fehlt aber die Zuodnung, damit die Beschriftung auch zugänglich ist. Die stellst du mit label-Element mit for-Attribut und id fürs Eingabefeld her, siehe Benutzereingaben zugänglich gestalten: Beschriftungen.

Warum sollen die beiden Eingabefelder nebeneinander stehen? Generell ist das keine gute Idee; Eingabefelder sollten untereinander stehen. In begründeten Ausnahmefällen mag man davon abweichen; den sehe ich hier aber nicht.

Ein Oberbegriff für city und town und auch noch kleinere Gemeinden ist locality. Vielleicht magst du den verwenden?

Das nächste Problem sind die Inline-Styles. Die machen den Code unübersichtlich. Außerdem musst du dieselben Formatierungen für jedes Eingabefeld angeben. Stil-Angaben im externen Stylesheet oder im style-Element lösen beide Probleme.

Was genau willst du erreichen? Das PLZ-Eingabefeld soll so breit wie angegeben sein, das für den Ort die restliche Breite einnehmen?

Es war mir zu mühsam, deinen Code aufzuräumen, neu bauen ging schneller: Codepen: flexbox.
Einige Formatierungen von dir hab ich übernommen, den Rest überlasse ich dir.

Ein paar Augenblicke hab ich aber doch gebraucht, das mit Flexbox zu implementieren. Mit Grid geht’s einfacher: Codepen: grid.

Was noch zu tun ist:

• Die 4ch Breite für die PLZ sind zu knapp bemessen; da sollten ein paar mehr Zeichen reinpassen, nicht wahr?
• Bei schmalem Viewport (Browserfenster) wird das Feld für den Ort zu schmal, dann sollten beide Eingabefelder untereinander stehen. (Wie bei breitem Viewport eigentlich auch, s.o.)

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar,

ich bin mit deiner Antwort nicht so glücklich, allerdings befürchte ich auch, dass man mit einer stichfesten Lösung nie wirklich glücklich ist.

Erstens:

Mit Grid geht’s einfacher

Finde ich nur begrenzt richtig. Bei schmalen Viewports kann man im Flexbox-Layout mit flex-wrap arbeiten, bei Grid-Layout braucht man @media- oder @container-Abfragen, und dann wird es wieder umständlicher.

Mit Flex ist es allerdings auch nicht wirklich einfach, wenn man einen Umbruch bei schmalen Viewports bei einer bestimmten Anzahl Zeichen erreichen will. Ob das responsiv als Grid eleganter geht? Ich habe jetzt ziemlich gefummelt und ob das nun didaktisch wertvoll ist, beginne ich zu bezweifeln.

Immerhin ist die gewünschte Feldbreite am Feld zeichengenau einstellbar 😀

Letztlich ist das alles ein Beleg für deine Aussage, dass man keine Felder nebeneinander setzen sollte.

Zweitens: Man sollte darauf hinweisen, dass das Setzen einer Border das automatische Outlining des fokussierten input-Elements abschaltet. Die input-Elemente sollten daher einen outline bekommen, wenn sie fokussiert sind.

.form-field input:focus {
   outline: 2px solid black;
}

Man sollte auch darauf hinweisen, dass der text-transform nur die Anzeige in Großschrift umsetzt. Der Server bekommt nach wie vor die gemischte Schreibweise, d.h. bevor man das in der DB speichert, sollte nochmal in Großschreibung konvertiert werden. In PHP wohl am besten mit mb_strtoupper - es wundert mich gerade, dass die Intl-Funktionen keinen locale-basierendes toUpper für Strings haben.

Drittens: Was ist der Zweck von

label:not(:has(input)) {
	display: block;
	width: fit-content;
}

Labels, die kein input-Element enthalten (hier also alle) sollen display:block sein. Wozu? Die inputs sind so breit wie das Flex-Item, damit stehen sie auch im inline-Modus unter dem Label und fit-content ist implizit. Ein label-Element, dass sein belabeltes Control enthält, wird doch ohnehin nicht empfohlen.

Ich bin ja bekanntlich ein Fiddler, hier ist meine Modifikation.

Rolf

[Auge]

Hallo

Drittens: Was ist der Zweck von

label:not(:has(input)) {
	display: block;
	width: fit-content;
}

Labels, die kein input-Element enthalten (hier also alle) sollen display:block sein. Wozu? … Ein label-Element, dass sein belabeltes Control enthält, wird doch ohnehin nicht empfohlen.

Vielleicht, weil es bei einigen die Input-Elemente eben doch innerhalb des Labels notiert sind und dann Gunnars Regel nicht automatisch angewendet werden soll und wird.

Tschö, Auge

[Rolf B]

Hallo Auge,

Vielleicht, weil es bei einigen die Input-Elemente eben doch innerhalb des Labels notiert sind

Ja, das habe ich schon verstanden. Aber sein Beispiel-HTML macht das nicht und Gunnar empfiehlt diese Form auch nicht, weil nicht jeder Screenreader damit klar kommt (ich meine, das war der Grund).

Deswegen frage ich, warum eine unbenutzte und für das Beispiel irrelevante Regel im Stylesheet steht.

Rolf

[Auge]

Hallo

Vielleicht, weil es bei einigen die Input-Elemente eben doch innerhalb des Labels notiert sind

Ja, das habe ich schon verstanden. Aber sein Beispiel-HTML macht das nicht und Gunnar empfiehlt diese Form auch nicht, weil nicht jeder Screenreader damit klar kommt (ich meine, das war der Grund).

Deswegen frage ich, warum eine unbenutzte und für das Beispiel irrelevante Regel im Stylesheet steht.

Damit Leser, die auf diese Lösung stoßen, aber eben doch verschachtelte Label-Input-Konstruktionen benutzen, damit nicht auf die Nase fallen?

Tschö, Auge

[Gunnar Bittersmann]

@@Rolf B

Mit Grid geht’s einfacher

Finde ich nur begrenzt richtig. Bei schmalen Viewports kann man im Flexbox-Layout mit flex-wrap arbeiten, bei Grid-Layout braucht man @media- oder @container-Abfragen, und dann wird es wieder umständlicher.

Die brauche ich bei Flexbox (bislang) auch: Flexbox, wrap. Mir ist noch nicht eingefallen, wie man’s ohne hinbekommt, dass das Ortseingabefeld aus schmalen Viewports nicht hinausragt.

Bei Grid und Container-Query braucht man wohl ein zusätzliches Element, da Container und Grid nicht dasselbe Element sein können, weil man mit Container-Query nur Nachfahren beeinflussen kann?

---

Letztlich ist das alles ein Beleg für deine Aussage, dass man keine Felder nebeneinander setzen sollte.

Dabei ging es aber nicht um developer convenience, sondern um user experience und accessibility.

---

Zweitens: Man sollte darauf hinweisen, dass das Setzen einer Border das automatische Outlining des fokussierten input-Elements abschaltet.

Da hast ein „nicht“ vergessen: Man sollte nicht? darauf hinweisen, dass das Setzen einer Border nicht? das automatische Outlining des fokussierten input-Elements abschaltet. Eins davon muss sein; beide gehen auch, macht dann aber weniger Sinn.

Die input-Elemente sollten daher einen outline bekommen, wenn sie fokussiert sind.

Haben sie per Browserdefault, und border und outline sind zwei Paar Schuhe und beeinflussen sich nicht gegenseitig.

---

In PHP wohl am besten mit mb_strtoupper - es wundert mich gerade, dass die Intl-Funktionen keinen locale-basierendes toUpper für Strings haben.

Ugh, ist PHP wirklich derart verkommen? In CSS geht das: Locale matters, Slides 4–5 und Codepen. In JavaScript auch, IIRC.

---

Drittens: Was ist der Zweck von

label:not(:has(input)) {
	display: block;
	width: fit-content;
}

Labels, die kein input-Element enthalten (hier also alle) sollen display:block sein. Wozu? Die inputs sind so breit wie das Flex-Item, damit stehen sie auch im inline-Modus unter dem Label und fit-content ist implizit.

Wenn beide Felder (auf breitem Viewport) nebeneinander sind, das ist das so, ja. Wenn sie (auf schmalen Viewport und besser auch auf breitem) untereinanderstehen, soll das PLZ-Feld ja nicht die volle Breite einnehmen und suggerieren, man könne/solle da einen Roman eintippen.

Ein label-Element, dass sein belabeltes Control enthält, wird doch ohnehin nicht empfohlen.

Bei Radiobuttons und Checkboxen schon. Da bietet sich die Verschachtelung an; andernfalls müsste man sich per CSS um die Lücke zwischen Radiobutton/Checkbox und Label kümmern. Es soll ja nicht sein, dass nichts passiert, wenn man dazwischen clickt.

Aber auch in dem Fall ist label { display: block; width: fit-content } sinnvoll. :not(:has(input)) im Selektor war Quatsch; ich hab das mal in den Codepens entfernt.

🖖 Live long and prosper

PS: Jetzt musste ich schon wieder den Unicode-Codepoint für n raussuchen, um das Posting abschicken zu können.

[Gunnar Bittersmann]

@@Rolf B

Ich habe jetzt ziemlich gefummelt und ob das nun didaktisch wertvoll ist, beginne ich zu bezweifeln.

Ich glaube, die Zweifel sind berechtigt. 😉

Die Berechnung könnte einem bei der nächsten Änderung wieder um die Ohren fliegen. Und beim Nachvollziehen, was da vor sich geht, fängt man selbst, wenn’s der eigene Code ist, nach ein paar Tagen wieder bei Null an.

Ein Mediaquery/Containerquery ist da wohl doch der wartungsfreundlichere Code.

---

Ich bin ja bekanntlich ein Fiddler

Bedauerlich. Was hast du für einen Monitor? Auf einem Riesending kann man sich JSFiddle vielleicht so einrichten, dass man damit klarkommt. Auf meinem 13-Zoller ist JSFiddle für mich unbedienbarer Scheiß.

🖖 Live long and prosper