Umbruch verhindern

[Merlin S]

Hallo!

Ich habe ein Problem, und zwar möchte ich bei dem Code Ausschnitt

<fieldset>
<legend>Einsatz</legend><label>Einsatzstichwort: </label><input list="Vögel" placeholder="Suche...">
<label>| Nummer: </label><input type="number" min="0">
</fieldset>

den Umbruch zwischen den label-Elementen und den input-elementen verhindern. Also konkret soll bei dem Teil

[A]<label>Einsatzstichwort: </label><input>[B]<label>| Nummer: </label>[C]<input>[D]

bei ausreichender Breite alles von A bis D in einer Zeile stehen und wenn es zu schmal wird soll der Umbruch bei B und nicht bei C erfolgen.

Ich habe dazu schon die Selfhtml-Seite durchsucht und auch gegoogelt, jedoch nichts gefunden. Kann mir bitte jemand da helfen? Vielen Dank!

Liebe Grüße

Merlin

aus Wien

[Gunnar Bittersmann]

@@Merlin S

Ich hab mal den Code in deinem Posting als solchen formatiert. Wie’s geht, steht in der Hilfe unter „Code“.

Bei der Auswahl der Kategorien bist du von css auf datenbank mausgerutscht?

---

<label>Einsatzstichwort: </label><input list="Vögel" placeholder="Suche...">

Ein label allein macht noch keine Beschriftung. Es muss auch mit dem Eingabefeld verknüpft sein: über for- und id-Attribute:

<label for="stichwort">Einsatzstichwort: </label><input id="stichwort" list="Vögel" placeholder="Suche...">

(Statt "stichwort" kannst du auch was anderes nehmen. Wichtig ist, dass es bei for und id gleich ist und dass es eindeutig ist, also dasselbe nicht bei anderen Label/Eingabefeld-Paaren nochmal auftritt.)

Gut ist das aber immer noch nicht: Das placeholder-Attribut ist so gut wie immer ein Fehler! Siehe heutiges Türchen im HTMHell-Adventskalender.

Zu deinem CSS-Problem später mehr.

🖖 Живіть довго і процвітайте

[Merlin S]

Hallo Gunnar!

Vielen Dank für deine Antwort.

Bitte entschuldige das mit der Code-Formatierung, das mit den drei Wellen wusste ich nicht. Auch das mit den Kategorien war komisch, die hat mir das System einfach so vorgeschlagen. Welche Tags wären hier denn angebracht?

Ich weiß, dass die for- und id-Attribute zur Verknüpfung notwendig sind, aber das ist doch nur Auswirkungen auf die Übermittlung und Auswertung der Daten, oder nicht? Haben diese Attribute auch eine Auswirkung auf den Umbruch?

Das placeholder-Attribut ist bei der ganzen Sache eigentlich nicht so wichtig. Wenn es ein Fehler ist, dann werde ich es weglassen.

Bei der Sache geht es übrigens um ein Formular, das überall, egal ob Laptop oder Smartphone, egal ob Online oder Offline, sogar auf einem Stick, laufen soll und es soll die eingegebenen Daten auch nicht zurücksenden, da ich vorgesehen habe, das Formular am Ende auszudrucken bzw. über die PDF-Speicherfunktion des Druck-Programmes zu exportieren. Wenn du möchtest, kann ich es mal als Ganzes anhängen.

Gruß

Merlin

[Rolf B]

Hallo Merlin S,

Ich weiß, dass die for- und id-Attribute zur Verknüpfung notwendig sind, aber das ist doch nur Auswirkungen auf die Übermittlung und Auswertung der Daten, oder nicht?

Gerade nicht. Für die Übermittlung der Daten an den Server ist das name-Attribut von Bedeutung. Mit for und id stellst Du die Verbindung zwischen Label und belabeltem Element her.

Das ist nicht nur für Assistenztechniken von Belang. Eine Checkbox oder ein Radio-Element ist klein und gemein und versteckt sich gerne vor zittrigen Mäusen oder vor dicken Fingern auf einem kleinen Touch-Display. Mit einem Label, das korrekt verknüpft ist, macht man einfach ein genügend großes Label dazu und die Trefferquote wird deutlich besser. Gleiches gilt für Eingabefelder aller Art.

Rolf

[Merlin S]

Hallo Rolf!

Vielen Dank für deine schnelle Antwort. Das Problem der zu kleinen Checkboxen und Radios ist auch mit bereits aufgefallen, ich habe es gelöst indem ich einfach das input-Element in den Label reinverschoben habe und bei mir (Windows 10 und OneUI 5, diverse Browser) funktioniert das jetzt auch ohne for und id sehr gut.

Außerdem geht es oben um ein input ohne derartigem Attribut und wie ich bereits Gunnar geschrieben habe, geht es bei der Sache um ein Formular, das überall, egal ob Laptop oder Smartphone, egal ob Online oder Offline, sogar auf einem Stick, laufen soll und es soll die eingegebenen Daten auch nicht zurücksenden, da ich vorgesehen habe, das Formular am Ende auszudrucken bzw. über die PDF-Speicherfunktion des Druck-Programmes zu exportieren. Wenn du möchtest, kann ich es mal als Ganzes anhängen.

Gruß

Merlin

[Rolf B]

Hallo Merlin S,

ich habe es gelöst indem ich einfach das input-Element in den Label reinverschoben habe und bei mir (Windows 10 und OneUI 5, diverse Browser) funktioniert das jetzt auch ohne for und id sehr gut.

Ja, in diesem Kontext tut es das. Es gibt aber wie gesagt Narratoren, die damit nicht klar kommen. Wenn Dein Nutzerkreis so ist, dass diese Art des Zugangs nicht gebraucht wird, brauchst Du for/id nicht.

Sei nur gewarnt, dass die Annahme, ein bestimmter Nutzerkreis "komme nicht vor", eine Tretmine ist, die dann explodiert, wenn Du es am wenigsten brauchen kannst. Das Hinzufügen von for und id tut nicht weh.

Rolf

[Gunnar Bittersmann]

@@Merlin S

bei ausreichender Breite alles von A bis D in einer Zeile stehen

Darüber reden wir noch mal.

und wenn es zu schmal wird soll der Umbruch bei B und nicht bei C erfolgen.

Dazu musst du wohl Label und Eingabefeld in einem Element gruppieren (p oder div), welches auf display: inline gesetzt wird: Beispiel 1.

Die Trennlinie ist mit border gemacht. Die sieht aber beim Umbruch auf schmalen Viewports fehl am Platz aus. Bei genügendem Abstand brauchst du die auch nicht.

Dann ist die Lösung mit Flexbox die bessere Wahl, da man den Abstand dann mit gap machen kann: Beispiel 2.

---

Generell sollte man aber Eingabefelder nicht nebeneinander, sondern untereinander platzieren. Und die Labels über die Eingabefelder, nicht daneben.

🖖 Живіть довго і процвітайте

[JürgenB]

Hallo Gunnar,

Dazu musst du wohl Label und Eingabefeld in einem Element gruppieren (p oder div), welches auf display: inline gesetzt wird: Beispiel 1.

was spricht gegen

<label>Einsatzstichwort: <input list="Vögel"></label>

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

label ohne for kollidiert mit fehlerhaften Screenreadern, die es leider gibt.

Gunnar, eine Flexbox in einer Flexbox nur für den Gap? Warum dann nicht einfach margin-right:1em auf dem label?

Oder besser noch das, was Du ohnehin vorschlugst: display:block auf's Label und grundsätzlich das Label über das input-Element. Die p's können dann mit Flexbox nebeneinander.

Wenn nämlich die Beschriftung vor dem input steht, sieht es nach Umbruch - find ich - total scheußlich aus, weil die inputs nicht übereinander sind.

Ich hatte noch kurz an ein Grid im Container mit Containerquery gedacht, das bei den richtigen Breiten von 4 auf 2 auf 1 Spalte schaltet. Nachteilig ist dann nur, dass man den Umbruchpunkt für die Texte passend ausmessen muss 🙄. Also eher meh…

Rolf

[Gunnar Bittersmann]

@@Rolf B

label ohne for kollidiert mit fehlerhaften Screenreadern, die es leider gibt.

Genauer: mit MS Dragon, was eine Vorlesesoftware ist, aber kein Screenreader.

Ich bin auch nicht im Bilde, ob MS seinem Drachen inzwischen beigebracht hat, HTML zu verstehen.

---

Gunnar, eine Flexbox in einer Flexbox nur für den Gap? Warum dann nicht einfach margin-right:1em auf dem label?

Der Randabstand wäre dann immer da – auch wenn er nicht gebraucht wird, wenn da auf schmalen Viewport umbrochen wird. Dann kann er auch störend sein, sodass das Label mehrzeilig wird, obwohl es ohne den Abstand nach rechts passen würde. Oder noch schlimmer: dass horizontales Scrollen ins Spiel kommt.

Gap hingegen wirkt nur zwischen Flex-Items (bzw. Grid-Items), d.h. wenn Label und Eingabefeld untereinander gerendert werden, hat das Label die volle Seitenbreite.

🖖 Живіть довго і процвітайте

[Merlin S]

Hallo Jürgen!

Vielen Dank für deine Antwort. Deine Idee funktioniert bei mir (Notepad++, Windows 10, verschiedene Browser) leider nicht, es kommt zu dem unerwünschten Umbruch.

Trotzdem vielen Dank.

Gruß

Merlin

[Merlin S]

Hallo Gunnar!

Nochmals Vielen Dank für deine Hilfe. Beispiel 1 funktioniert perfekt und genau so, wie ich es mir vorgestellt habe. Danke!

Und die Eingabefelder sind hier nebeneinander platziert, da es sich um ein Formular handelt, dass nicht zurückgesendet, sondern (auf einer Seite) ausgedruckt werden soll. Daher die unkonventionelle Variante mit mehreren Feldern nebeneinander. Wenn du möchtest, kann ich es mal als Ganzes anhängen.

Gruß

Merlin

[Auge]

Hallo

Auch wenn es ein bisschen spät ist, der Vollständigkeit halber …

Und die Eingabefelder sind hier nebeneinander platziert, da es sich um ein Formular handelt, dass nicht zurückgesendet, sondern (auf einer Seite) ausgedruckt werden soll. Daher die unkonventionelle Variante mit mehreren Feldern nebeneinander.

Es ist durchaus möglich, die Darstellung im Browser selbst und die vom Browser generierten Ausdruck verschieden voneinander zu gestalten. Es wäre also kein Problem, im Browser die Labels oberhalb der Eingabefelder anzuzeigen und die selbe Konstruktion von Label und Formularelement im Ausdruck des fertig ausgefüllten Formulars nebeneinander anzuzeigen.

Dazu müssen die CSS-Eigenschaften, die dafür sorgen, die Elemente nebeneinander anzuzeigen, und die sich deshalb von den Regeln der Anzeige im Browser unterscheiden, einfach nur in einem entsprechenden Media-Block notiert werden.

/* Regeln für die Anzeige im Browser */
@media print {
    /* abweichende Regeln für die Druckausgabe */
}

Tschö, Auge

[Merlin]

Hi Auge!

Vielen Dank für die Idee. Ich werde das mal ausprobieren.

Liebe Grüße

Merlin

[nix]

„Mit so Kram hab’ ich nichts am Hut“ — aber: sie erinnert mich zumindest an mein „wie bekomm’ ich whitespace weg“ Problem. Das bestand, nein, besteht darin, daß eine auf inline getrimmte Liste beim ggf. auftretenden Zeilenumbruch eingefüghte Zeichen (Kommata) vom Element trennt und in die nächste Zeile schiebt. Zur Erklärung: die übliche „Einkaufsiste“

Liste
° abc
° def
° ghi

soll(te) in eine „Briefliste“, in fließenden Text, eingefügt werden:

Liste: abc, def, ghi

Was aber ggf. dann doch nur so aussieht:

Liste: abc, def
, ghi

Meine bis for kurzem gepflegte Lösung

<ul>Liste
<li

>abc</li
>def</li
>ghi</li></ul>

hat jetzt aber schon wieder einen dicken Kratzer bekommen: Buttons mit Popover drin. Wenn die, beispielsweise als Basis für einen Tooltip, auch als schlichter Text daher kommen sollen, provozieren sie ähnliche Dinge:

<p>Nieder mit den Abkürzungen <button type=button popovertarget=defAküFi>Akü</button>?</p>

liefert da auch wieder so etwas:

Nieder mit den Abkürzungen Akü
?

Vielleicht gewöhne ich mir doch noch ab, mich über das beleidigende Namenstrennen aufzuregen? Oder wie sehen das Pe-
ter, An-
drea, …?

[Rolf B]

Hallo nix,

das mit der Liste sollte unproblematisch sein, wenn man das Komma ans Ende der List-Items setzt, außer beim letzten.

Hier ist die Liste:
<ul class="inline">
<li>eins eins eins</li>
<li>zwei zwei zwei</li>
<li>drei drei drei</li>
<li>vier vier vier</li>
<li>fünf fünf fünf</li>
<li>sechs sechs</li>
<li>sieben sieben</li>
</ul>

Wichtig ist nur, dass vor den </li>-Tags kein Whitespace im Markup steht, sonst landet das Space auch vor dem Komma. Whitespace zwischen den Listenelementen und hinter den <li>-Tags sollte unproblematisch sein.

Das CSS dazu sieht so aus:

ul.inline {
  display: inline; padding: 0; margin: 0;
}
ul.inline li {
  display: inline;
}
ul.inline li:not(:last-of-type)::after {
  content: ",";
}

Einen Button und ein Fragezeichen zusammenzuhalten gelingt nach meiner Kenntnis nur mit zusätzlichem Markup. Die diversen Unicode Joiner-Zeichen greifen nicht.

<span class="keep-together"><button>ksdf</button>?</span>

.keep-together { white-space: pre; }

Rolf

[Gunnar Bittersmann]

@@Rolf B

Whitespace zwischen den Listenelementen und hinter den <li>-Tags sollte unproblematisch sein.

Ja, aber ich würde mich nicht drauf verlassen, dass da Whitespace zwischen den li-Elementen ist. Selbst wenn man in seinem Quelltext welchen hat, könnte ein Minifier den eliminieren.

Also nach dem Komma noch ein Leerzeichen setzen:

ul.inline li:not(:last-of-type)::after {
  content: ", ";
}

Es ginge übrigens auch ohne Verneinung:

ul.inline li:nth-last-of-type(n+2)::after {
  content: ", ";
}

Aber besser lesbar ist das wohl nicht.

🖖 Живіть довго і процвітайте

[nix]

Nun, das mit den ggf. umbrechenden :after-Anhängseln hatte ich ja (vorerst?) mal behoben. (inline-block bietet sich zwar auch an, verdammt den Text dann aber zum „block-Leben“.)
Schön sieht es nicht aus, das Zerreißen der Tags. Aber so ist’s wenigstens praktikabel: man kann einfach Listen-Einträge einfügen/dranhängen oder entfernen, ohne groß über solche Folgen nachdenken zu müssen.

„Aber dann kam button mit popover …“. Und dem beizubringen, daß er irgendwiezwischen inline und (inline-)block Zusammenhalt zeigen soll — zumindest aktuell habe ich nicht mal ansatzweise eine Idee, wie das funktionieren könnte. Aber … („Der Krieg des Charlie Wilson“:) man wird sehen. Und wenn es auf das Warten auf Godot anchor hinauslaufen sollte. (Das beträfe zwar nicht dieses button-Problem, aber ich könnte diese („Der Schuh des Manitou“:) „Gesamtsituation“ damit anders angehen.