Problem mit div Tag

[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.