inline-Element mit fester Breite und Zeilenumbruch davor

[Felix Riesterer]

Liebe Mitlesende,

ich möchte ein Formular gestalten. Folgendes Markup sei gegeben:

<form ...>  
    <p>  
        <label for="sorte">Eissorte </label>  
        <select name="sorte" id="sorte">[...]</select>  
        <label for="behaeltnis">Behältnis </label>  
        <select name="behaeltnis" id="behaeltnis">[...]</select>  
        <input type="submit" value="bestellen" />  
    </p>  
</form>

Gewünschtes Aussehen:

Eissorte  <Erdbeer...>
    Behältnis <Waffel..> [bestellen]

(oder auch mit dem [bestellen]-Button in einer neuen Zeile)

Mein erster Lösungsgedanke war, dass jedes select-Element mit der Pseudoklasse :after einen Zeilenumbruch erhält. Dieser Lösungsweg ist in meinem FF aber kläglich gescheitert. Folgender Code hat keine sichtbaren Auswirkungen gehabt:

select:after { white-space: pre-line; content: "\a"; }

Anscheinend mag der FF keine Pseudoklasse :after (oder auch :before) bei <select>-Elementen.

Mein zweiter Versuch war dann, dass jedes <label>-Element eine neue Zeile beginnt. Das habe ich mit der Pseudoklasse :before gelöst:

label:before { white-space: pre-line; content: "\a"; }

Soweit klappt das in meinem FF auch (IE mache ich später folgsam).

Nun das Problem: Ich möchte ja alle Labels mit identischer Breite. Folgender Versuch bringt zwar eine identische Breite, zerstört aber den vorher eingerichteten Zeilenumbruch:

label { display: inline-block; width: 4em; }

Anscheinend gelingt die vorherige CSS-Regel mit :before nur in bestimmten Ausnahmefällen...? Oder hat jemand eine andere Erklärung, warum das so nicht klappen will, oder weiß gar, wie ich stattdessen vorgehen muss?

Liebe Grüße,

Felix Riesterer.

[Vinzenz Mai]

Hallo,

<form ...>

<p>
        <label for="sorte">Eissorte </label>
        <select name="sorte" id="sorte">[...]</select>
        <label for="behaeltnis">Behältnis </label>
        <select name="behaeltnis" id="behaeltnis">[...]</select>
        <input type="submit" value="bestellen" />
    </p>
</form>

  

> Gewünschtes Aussehen:  
  

>     Eissorte  <Erdbeer...>  
>     Behältnis <Waffel..> [bestellen]  
>   
> (oder auch mit dem [bestellen]-Button in einer neuen Zeile)  
  
warum nicht: form- oder p-Element eine Breite geben, label- und select-Elemente mit display:block und einer Breite versehen, die sich an der vorhandenen Breite orientiert und floaten lassen?  
  
Warum keine Liste oder Tabelle?  
  
Letzeres ist ernst gemeint. Vor Jahrhunderten gabs noch kein HTML, aber Behörden, die schon damals unstillbaren Hunger auf ausgefüllte Formulare hatten. Man verwendete Tabellen, um die Formulare übersichtlich zu gestalten. Das ist nicht verwunderlich, denn schließlich handelt es sich bei Formularelementen um tabellarische Daten.  
  
Eine Liste wär' auch noch 'ne einfache Möglichkeit ...  
... und dann gibts noch das br-Element. ;-)  
  
Ich fürchte jedoch, Du nimmst lieber kompliziertes (und von noch weit verbreiteten Browsern nicht unterstütztes) CSS :-)  
  
  
Freundliche Grüße  
  
Vinzenz

[Gunnar Bittersmann]

@@Vinzenz Mai:

nuqneH

warum nicht: form- oder p-Element eine Breite geben

In vernünftigen Browsern geht’s auch ohne. Dafür mit clearenden Worten.

label- und select-Elemente mit display:block und einer Breite versehen, die sich an der vorhandenen Breite orientiert und floaten lassen?

'float' setzt implizit 'display' auf "block". [CSS21 §9.7]

label, select, input  
{  
	float: left;  
}  
  
label  
{  
	clear: left;  
	width: 6em;  
}

In unvernünftigen Browsern geht’s so nicht: „Internet Explorer [IE < 8] wendet zwar das clear auf die jeweilige Box an, vergisst dies jedoch wieder bei der nachfolgenden Box, so dass die Darstellung fehlerhaft ist (Screenshots)“. [icke]

Warum keine Liste oder Tabelle?

Äußerst berechtigte Frage! Oder wenigstens ein gruppierendes Element um zusammengehörige 'label' und 'select'. Ansonsten hat man ein änliches Problem wie bei Definitionslisten, weil in HTML das zusammengehörige 'dt' und 'dd' gruppierende 'di' fehlt.

Qapla'

[Felix Riesterer]

Lieber Gunnar,

Warum keine Liste oder Tabelle?

Äußerst berechtigte Frage! Oder wenigstens ein gruppierendes Element um zusammengehörige 'label' und 'select'.

zugegeben. Dieser Umstand macht meine Frage zu einer eher akademischen zu CSS und seiner standard-konformen Unterstützung in den "guten" Browsern.

Ansonsten hat man ein änliches Problem wie bei Definitionslisten, weil in HTML das zusammengehörige 'dt' und 'dd' gruppierende 'di' fehlt.

"di"? Du meintest "dl", oder nicht?

Liebe Grüße,

Felix Riesterer.

[Kai345]

[latex]Mae  govannen![/latex]

Ansonsten hat man ein änliches Problem wie bei Definitionslisten, weil in HTML das zusammengehörige 'dt' und 'dd' gruppierende 'di' fehlt.

"di"? Du meintest "dl", oder nicht?

Er meint schon di, das eine Menge von dt und dd-Elementen gruppieren könnte.

Cü,

Kai

[Felix Riesterer]

Lieber Kai345,

Er meint schon di, das eine Menge von dt und dd-Elementen gruppieren könnte.

aha! XHTML_2_! Das habe ich bewusst noch nicht gelernt. Für mich war es irrelevant, zumindest bisher. Und da offensichtlich der Trend XHTML2 nicht mehr wirklich folgt, sondern nun zu HTML5 geht, werde ich einfach einmal abwarten, wie man dort Definitionslisten handabt. Solange dieser Standard nicht offiziell verabschiedet worden ist, werde ich davon die Finger lassen.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer:

nuqneH

Er meint schon di, das eine Menge von dt und dd-Elementen gruppieren könnte.

[…] Und da offensichtlich der Trend XHTML2 nicht mehr wirklich folgt, sondern nun zu HTML5 geht […]

'di' war auch in HTML5 mal vorgesehen gewesen, wurde aber wieder rausgenommen. Große Dummheit, IMHO.

http://forum.de.selfhtml.org/archiv/2009/5/t186757/#m1240638 ff.

Qapla'

[Felix Riesterer]

Lieber Vinzenz,

warum nicht: form- oder p-Element eine Breite geben, label- und select-Elemente mit display:block und einer Breite versehen, die sich an der vorhandenen Breite orientiert und floaten lassen?

Warum keine Liste oder Tabelle?

Letzeres ist ernst gemeint.

mein Problem ist sicherlich eher akademischer Natur, da sich mein Anzeigeproblem strukturell lösen lässt - zugegeben.

schließlich handelt es sich bei Formularelementen um tabellarische Daten.

Das kommt darauf an. Tabellarische Daten liegen nach meinem Strukturverständnis dann vor, wenn die Auflistung in nicht nur einer Dimension erfolgt, sondern in zwei; sprich, wenn nicht nur ein senkrechter Bezug (Aufzählung), sondern auch ein waagrechter Bezug (Verknüpfung, 2. Dimension) der Daten untereinander besteht. Und das muss in einem Formular nicht unbedingt gegeben sein.

Aber ich gebe Dir insofern Recht, als ich mein Markup durch eine Liste erweitern werde, um mein Anzeigeproblem strukturell zu lösen.

Eine Liste wär' auch noch 'ne einfache Möglichkeit ...

Eine strukturell angemessene sogar. Im obigen Beispiel ist bei mehrfacher Bestellung eine Tabelle sinnvoll, in meinem tatsächlichen Projekt dagegen nicht. Obiges Beispiel könnte so aussehen:

+-----+--------------+-----------+
 | Nr. |    Sorte     | Behältnis |
 +-----+--------------+-----------+
 |  1  | Erdbeer      |  Waffel   |
 +-----+--------------+-----------+
 |  2  | Schokolade   |  Waffel   |
 +-----+--------------+-----------+
 |  3  | Straciatella |  Becher   |
 +-----+--------------+-----------+

Wenn das Formular aber nur die Eingabe einer Einzelbestellung unterstützt, dann wäre eine Definitionsliste sicherlich passender:

Sorte:
    Erdbeer
Behältnis:
    Waffel

... und dann gibts noch das br-Element. ;-)

;-)

Ich fürchte jedoch, Du nimmst lieber kompliziertes (und von noch weit verbreiteten Browsern nicht unterstütztes) CSS :-)

Du hast Recht, wenn Du meine Frage als eher akademischer Natur ansiehst. Was allerdings das "weit verbreitete Browser" angeht: Anscheinend ist sogar der FF(3.6.3) damit überfordert. Ts, ts, ts.

Liebe Grüße,

Felix Riesterer.

[ChrisB]

Hi,

schließlich handelt es sich bei Formularelementen um tabellarische Daten.

Das kommt darauf an. Tabellarische Daten liegen nach meinem Strukturverständnis dann vor, wenn die Auflistung in nicht nur einer Dimension erfolgt, sondern in zwei; sprich, wenn nicht nur ein senkrechter Bezug (Aufzählung), sondern auch ein waagrechter Bezug (Verknüpfung, 2. Dimension) der Daten untereinander besteht. Und das muss in einem Formular nicht unbedingt gegeben sein.

Du hast bei deinem Beispiel auf der einen Seite Beschriftungen (Labels), auf der anderen Seite Eingabefelder - natürlich kann man das als tabellearische Daten betrachten.

Deine zwei „Dimensionen“ sehe ich hier auch gegeben.

MfG ChrisB

[Gunnar Bittersmann]

@@Felix Riesterer:

nuqneH

Wenn das Formular aber nur die Eingabe einer Einzelbestellung unterstützt, dann wäre eine Definitionsliste sicherlich passender:

Ist der Zwang, jede zweispaltige Tabelle als Definitionsliste auszeichnen zu wollen, heilbar?

http://forum.de.selfhtml.org/archiv/2006/1/t122191/#m788050 ff.

Qapla'

[jobo]

Hallo,

Ist der Zwang, jede zweispaltige Tabelle als Definitionsliste auszeichnen zu wollen, heilbar?

Klar. Eine Definitionsliste ist ja ein eigenständiger Datensatz, der seine Spaltenbeschriftung mitbringt. Quasi eine einzeilige Tabelle (assoziatives Array, JSON-Objekt). Wenn man das kapiert hat, kann man mit umgehen, oder?
Gruß

jobo

[Der Martin]

Hallo Felix,

ich möchte ein Formular gestalten. Folgendes Markup sei gegeben:

<form ...>

<p>
        <label for="sorte">Eissorte </label>
        <select name="sorte" id="sorte">[...]</select>
        <label for="behaeltnis">Behältnis </label>
        <select name="behaeltnis" id="behaeltnis">[...]</select>
        <input type="submit" value="bestellen" />
    </p>
</form>

  
warum nicht ein fieldset anstatt des p-Elements?  
  

> Mein erster Lösungsgedanke war, dass jedes select-Element mit der Pseudoklasse :after einen Zeilenumbruch erhält. Dieser Lösungsweg ist in meinem FF aber kläglich gescheitert.  
  
Das dürfte daran liegen, dass ein Zeilenumbruch, wenn er mit der content-Eigenschaft eingefügt wird, die gleiche Wirkung hätte wie ein Zeilenumbruch im Quellcode: Er wird als Whitespace interpretiert.  
  

> `select:after { white-space: pre-line; content: "\a"; }`{:.language-css}  
  
Bist du sicher, dass du Linefeed meintest, und nicht Carriage Return oder gar eine Kombination aus beiden? Abgesehen davon ist die Notation irreführend: Auch wenn CSS keine C-typischen Escapes verwendet, denkt man beim Lesen von "\a" spontan zunächst an Ctrl-G. Die Notation "\0A" wäre lesefreundlicher.  
  

> Mein zweiter Versuch war dann, dass jedes <label>-Element eine neue Zeile beginnt. Das habe ich mit der Pseudoklasse :before gelöst:  
>   
> `label:before { white-space: pre-line; content: "\a"; }`{:.language-css}  
>   
> Soweit klappt das in meinem FF auch.  
  
Das überrascht mich - auch hier hätte ich erwartet, dass das Linefeed als normales Whitespace-Zeichen interpretiert wird.  
  
Allem Ehrgeiz zum Trotz halte ich aber wie Vinzenz Formulare für einen sinnvollen Einsatzfall von dl oder table.  
  
So long,  
 Martin  

-- 
Computer funktionieren grundsätzlich nicht richtig.  
Wenn doch, hast du etwas falsch gemacht.  

[Felix Riesterer]

Lieber Martin,

warum nicht ein fieldset anstatt des p-Elements?

ich habe in meinem echten Projekt ein fieldset um das <p>-Element herum. Um aber das Problem strukturell so einfach wie möglich zu halten, habe ich dieses gekürzt. Im Grunde hätte ich mir auch das <form>-Element im Beispiel sparen können - ob dann aber der Code noch valide gewesen wäre? Wahrscheinlich schon, wenn auch sinnfrei (<input> außerhalb eines <form> hat keine Wirkung).

Element mit der Pseudoklasse :after einen Zeilenumbruch erhält. Dieser Lösungsweg ist in meinem FF aber kläglich gescheitert.

Das dürfte daran liegen, dass ein Zeilenumbruch, wenn er mit der content-Eigenschaft eingefügt wird, die gleiche Wirkung hätte wie ein Zeilenumbruch im Quellcode: Er wird als Whitespace interpretiert.

Im Grunde hast Du Recht, jedoch habe ich mit white-space:pre-line definiert, dass Zeilenumbrüche in der Darstellung nicht geschluckt werden sollen (wie eben auch in einem <pre>-Element). Daher ist meine Erwartungshaltung nicht unbegründet.

select:after { white-space: pre-line; content: "\a"; }

Bist du sicher, dass du Linefeed meintest, und nicht Carriage Return oder gar eine Kombination aus beiden?

Ja. Diese Schreibweise ist sogar von der Spezifikation auf der W3C-Seite direkt übernommen.

Abgesehen davon ist die Notation irreführend: Auch wenn CSS keine C-typischen Escapes verwendet, denkt man beim Lesen von "\a" spontan zunächst an Ctrl-G. Die Notation "\0A" wäre lesefreundlicher.

Zugegeben. Das könnte ich für den menschlichen Leser verbessern.

label:before { white-space: pre-line; content: "\a"; }

Soweit klappt das in meinem FF auch.

Das überrascht mich - auch hier hätte ich erwartet, dass das Linefeed als normales Whitespace-Zeichen interpretiert wird.

Du kennst anscheinend die Eigenschaft "white-space" noch nicht so gut? Ist mir vor diesem Fall auch so gegangen... *g*

Allem Ehrgeiz zum Trotz halte ich aber wie Vinzenz Formulare für einen sinnvollen Einsatzfall von dl oder table.

Vinzenz hat Recht, wenn er meinen Lösungsansatz als akademische CSS-Übung (meine Worte) sieht. Ich werde wohl das Markup in eine Liste packen. Dann ist das Problem strukturell gelöst. Aber warum konnte ich es nicht mit reinen CSS-Mitteln lösen (akademische Frage)?

Liebe Grüße,

Felix Riesterer.

[jobo]

Hallo Felix,

Vinzenz hat Recht, wenn er meinen Lösungsansatz als akademische CSS-Übung (meine Worte) sieht. Ich werde wohl das Markup in eine Liste packen. Dann ist das Problem strukturell gelöst. Aber warum konnte ich es nicht mit reinen CSS-Mitteln lösen (akademische Frage)?

Weil wie Gunnar richtig bemerkt, im HTML ein "Fehler" ist. Der Bezug zwischen Label und Input wird über das Attribut "for" hergestellt. XHTML_2 macht es mMn. "richtig". Label und Input müssen in ein umspannendes Element. Eigentlich in ein <div>, denn sie bilden eine "Division", eine Einheit. In HTML5 gibt es ja wohl ein Section-Element, was Überschriften und deren Absätze umschließen soll. Das ist mMn. "semantisch" das selbe, "akademische" Problem.

Als ich mich mit akademischem Interesse mal mit einem Formulargenerator beschäftigt hatte, bin ich natürlich auch darauf gestoßen, dass man die "Labels" natürlich gerne alle in einer Breite hätte (wenn man nicht nur eine Zeile anzeigen möchte). Dann aber landest Du wieder bei einer Tabelle, denn du möchtest nur die Elemente in einer gleichen Breite zeigen, die einen Tabellarischen Überblick gewähren über Datensätze, die sich zB. sinnvoll durch ihre Bestelleingangsnummer sortieren lassen.

Eigentlich ist schon der Unterschied der Formularelemente murx würde ich meinen. Denn hier bestimmt HTML die Darstellung, nämlich "select-Box" oder "Liste von Checkboxen/Radioboxen". <input type="select"><option>...</option></input> wäre eigentlich logischer.

Das Zend-Framework nutzt definition-list für seine Formular-Klasse. Und deren Formular-Validator klebt an der Formular-Klasse, und damit mischt sich hier Validierung mit Darstellung. Das hat mich stutzig gemacht, warum gerade Formulare, also eigentlich _die_ Schnittstelle zwischen User und Server, so "problematisch" sind.

Ich hatte damals u.a. sowas in meinem CSS:

div > label {display:block;float:left;width:10em;}

Später aber auch:

a) <div class="label_control_pair"><label>... <input ....
für sowas wie <label>... <select> (also Paarung Inline- und Bockelement)

und
b) <span class="label_control_pair"><label> ... <input> ...

um multiple Auswahllisten mit Checkboxen möglich zu machen, (Inline-Label und Inline-Input).

Gruß

jobo

[Felix Riesterer]

Lieber jobo,

Weil wie Gunnar richtig bemerkt, im HTML ein "Fehler" ist. Der Bezug zwischen Label und Input wird über das Attribut "for" hergestellt.

das ist nur eine Möglichkeit. Die Spezifikation ermöglicht auch folgendes:

<label>Username: <input name="user" type="text" /></label>

XHTML_2 macht es mMn. "richtig". Label und Input müssen in ein umspannendes Element. Eigentlich in ein <div>, denn sie bilden eine "Division", eine Einheit. In HTML5 gibt es ja wohl ein Section-Element, was Überschriften und deren Absätze umschließen soll. Das ist mMn. "semantisch" das selbe, "akademische" Problem.

Ich finde das zusätzliche Element nicht gut. Und schon garnicht das <div>, da es für Blockelemente gedacht ist, die Texteingabeelemente jedoch ausschließlich inline-Elemente sind. Da wäre allenfalls ein <span> syntaktisch richtig. Gerade weil man aber zwei Möglichkeiten hat, den Bezug herzustellen, sollte man auch von beiden Möglichkeiten Gebrauch machen. Fehlerhafte Browser sind kein Argument...

Eigentlich ist schon der Unterschied der Formularelemente murx würde ich meinen. Denn hier bestimmt HTML die Darstellung, nämlich "select-Box" oder "Liste von Checkboxen/Radioboxen". <input type="select"><option>...</option></input> wäre eigentlich logischer.

Da stimme ich Dir zu. Vollkommen.

Liebe Grüße,

Felix Riesterer.

[jobo]

Hallo Felix,

Ich finde das zusätzliche Element nicht gut. Und schon garnicht das <div>, da es für Blockelemente gedacht ist,

Nicht auch zur Gruppierung von mehreren Inline-Elementen? Ein "logischer" Absatz, kein sprachlicher (p wie paragraph)? Denn der Absatz (<br>) signalisiert ja immer einen "Block".

Da wäre allenfalls ein <span> syntaktisch richtig.

Dem ich dann per CSS "display:block" zuweise? (;-).

Gruß

jobo

[Felix Riesterer]

Lieber jobo,

Ich finde das zusätzliche Element nicht gut. Und schon garnicht das <div>, da es für Blockelemente gedacht ist,

Nicht auch zur Gruppierung von mehreren Inline-Elementen?

kann man machen, ich nenne das "missbrauchen".

Ein "logischer" Absatz, kein sprachlicher (p wie paragraph)? Denn der Absatz (<br>) signalisiert ja immer einen "Block".

Logik? In Sprache? Hehe. Aber egal. Ein <div> ist kein Absatz. Es ist eine Division. Eine Abteilung.

Da wäre allenfalls ein <span> syntaktisch richtig.
Dem ich dann per CSS "display:block" zuweise? (;-).

Ja, schon klar. ;-)

Liebe Grüße,

Felix Riesterer.

[jobo]

Hallo Felix,

Ich finde das zusätzliche Element nicht gut. Und schon garnicht das <div>, da es für Blockelemente gedacht ist,

Nicht auch zur Gruppierung von mehreren Inline-Elementen?

kann man machen, ich nenne das "missbrauchen".

Warum? Ich dachte immer, eine "Abteilung" wäre ein "Absatz", der a) semantisch nicht nur das ist (sondern "mehr") und b) Blockelemente wie Absätze zusammenfassen darf.

Ein "logischer" Absatz, kein sprachlicher (p wie paragraph)? Denn der Absatz (<br>) signalisiert ja immer einen "Block".

Logik? In Sprache? Hehe.

Naja, ein "Absatz" ist eine Logik. So meinte ich das.

Ein <div> ist kein Absatz. Es ist eine Division. Eine Abteilung.

Eine kleine Division könnte ja aus label und input bestehen. Das ist semantologisch so wie Überschrift->Absatz wär jetzt meine Intuitivmeinung.

Da wäre allenfalls ein <span> syntaktisch richtig.
Dem ich dann per CSS "display:block" zuweise? (;-).

Ja, schon klar. ;-)

Ja wirklich? Denn ein "display:block" ist eigentlich "falsch". Denn wenn ich es als Block (Div) darstelle, ist ein ein Block (== logische Einheit). Dann "_muss_" es ins html, nicht ins CSS.

Gruß

jobo

[ChrisB]

Hi,

Ja wirklich? Denn ein "display:block" ist eigentlich "falsch". Denn wenn ich es als Block (Div) darstelle, ist ein ein Block (== logische Einheit). Dann "_muss_" es ins html, nicht ins CSS.

Wieso wirfst du denn Struktur und Darstellung in einen Topf?

MfG ChrisB

[jobo noreg]

Hallo,

Ja wirklich? Denn ein "display:block" ist eigentlich "falsch". Denn wenn ich es als Block (Div) darstelle, ist ein ein Block (== logische Einheit). Dann "_muss_" es ins html, nicht ins CSS.

Wieso wirfst du denn Struktur und Darstellung in einen Topf?

Mein Punkt war eigentlich genau anders rum: wenn ich in der Darstellung einen "Block" wähle, also zB. einen Absatz (oder sprachlich eine Pause), dann deutet das (in der Regel) auf einen inhaltlichen "Block" hin. Der sollte sich dann im HTML finden, weil "semantisch".

Gruß,

jobo

[Der Martin]

Hallo,

kann man machen, ich nenne das "missbrauchen".
Warum? Ich dachte immer, eine "Abteilung" wäre ein "Absatz", der a) semantisch nicht nur das ist (sondern "mehr") und b) Blockelemente wie Absätze zusammenfassen darf.

nein, ein "Absatz" ist ein Begriff aus dem Schriftsatz - das ist ein Block zusammengehörender Textzeilen, der in HTML mit dem p-Element abgebildet wird. Das div-Element dient nur dazu, beliebige andere Elemente (das können auch Überschriften und Absätze sein) so zu gruppieren, dass sie gemeinsam einen Block bilden.

Ein "logischer" Absatz, kein sprachlicher (p wie paragraph)? Denn der Absatz (<br>) signalisiert ja immer einen "Block".
Logik? In Sprache? Hehe.
Naja, ein "Absatz" ist eine Logik. So meinte ich das.

Ihr meintet nicht Logik, sondern Struktur (das, was die HTML-Fachleute gern "Semantik" nennen). ;-)

Ein <div> ist kein Absatz. Es ist eine Division. Eine Abteilung.
Eine kleine Division könnte ja aus label und input bestehen. Das ist semantologisch so wie Überschrift->Absatz wär jetzt meine Intuitivmeinung.

Durchaus nachvollziehbar.

Ja wirklich? Denn ein "display:block" ist eigentlich "falsch". Denn wenn ich es als Block (Div) darstelle, ist ein ein Block (== logische Einheit). Dann "_muss_" es ins html, nicht ins CSS.

Äh, wie? Es geht um die Art der Darstellung, das hat prinzipiell nichts im HTML verloren. Nochmal zur Verdeutlichung:

<span> gruppiert inline-Elemente, die gesamte Gruppe bleibt inline
 <div> gruppiert inline- und/oder Blockelemente, die gesamte Gruppe ist ein Block

Dass man die beiden Elemente aus CSS-Sicht jederzeit austauschen kann, ist klar; aus HTML-Sicht geht das nicht immer, da span keine Blockelemente enthalten darf.

Ciao,
 Martin

[jobo]

Hallo Martin,

Ja wirklich? Denn ein "display:block" ist eigentlich "falsch". Denn wenn ich es als Block (Div) darstelle, ist ein ein Block (== logische Einheit). Dann "_muss_" es ins html, nicht ins CSS.

Äh, wie? Es geht um die Art der Darstellung, das hat prinzipiell nichts im HTML verloren.

Ob nun Logik, Struktur oder Semantik: Einen "Block" stellt man erstmal als Block dar, weil der Block dargestellt den inhaltlichen (logischen) Zusammenhang des Textabschnitts "symbolisiert" bzw. eben darstellt. Wäre der Text gelesen, wäre es eine Pause, die das Blockende "darstellt".

Nochmal zur Verdeutlichung:

<span> gruppiert inline-Elemente, die gesamte Gruppe bleibt inline
<div> gruppiert inline- und/oder Blockelemente, die gesamte Gruppe ist ein Block

Dass man die beiden Elemente aus CSS-Sicht jederzeit austauschen kann, ist klar; aus HTML-Sicht geht das nicht immer, da span keine Blockelemente enthalten darf.

Eben, und das ist ja Felix Argument umgekehrt, ich nehme solange das rangniedrieger Gruppierungselement, wie das möglich ist.

Besonderheit an span wäre ja eigentlich aber auch, dass es "nur Text" markiert, also Schlüsselwörter, Titel oder Eigennamen im Absatz (dargestellt dann kursiv oder fett o.äl).

Gruß

jobo

[Kai345]

[latex]Mae  govannen![/latex]

Weil wie Gunnar richtig bemerkt, im HTML ein "Fehler" ist. Der Bezug zwischen Label und Input wird über das Attribut "for" hergestellt.

das ist nur eine Möglichkeit. Die Spezifikation ermöglicht auch folgendes:

<label>Username: <input name="user" type="text" /></label>

Praktisch anwendbar leider nur, wenn man IE<=6 nicht mehr beachten muß. Ansonsten ist for= weiterhin erforderlich.

Cü,

Kai

[Felix Riesterer]

Lieber Kai345,

<label>Username: <input name="user" type="text" /></label>

Praktisch anwendbar leider nur, wenn man IE<=6 nicht mehr beachten muß.

Ich schrieb doch:

Fehlerhafte Browser sind kein Argument...

Ansonsten ist for= weiterhin erforderlich.

Ja, fehlerhafte Browser sind eben eine Pest. Aber bei <label> kann ich eine fehlende oder falsche Funktionalität verschmerzen. Immerhin behindert es nicht den Datentransfer zwischen User und Server. Nur die user experience wird (wenn überhaupt) gestört.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer:

nuqneH

Die Spezifikation ermöglicht auch folgendes:
<label>Username: <input name="user" type="text" /></label>

Für semantisch sinnvoll halte ich dies nicht. Ein Eingabefeld ist doch kein Bestandteil seiner Beschriftung.

Qapla'

[jobo]

Hallo,

Die Spezifikation ermöglicht auch folgendes:
<label>Username: <input name="user" type="text" /></label>

Für semantisch sinnvoll halte ich dies nicht. Ein Eingabefeld ist doch kein Bestandteil seiner Beschriftung.

Genau, das wäre ein <section> oder ein <div class="label_control_set"> oder ein <fieldset>?

Gruß

jobo

[Der Martin]

Hallo Felix,

Das dürfte daran liegen, dass ein Zeilenumbruch, wenn er mit der content-Eigenschaft eingefügt wird, die gleiche Wirkung hätte wie ein Zeilenumbruch im Quellcode: Er wird als Whitespace interpretiert.
Im Grunde hast Du Recht, jedoch habe ich mit white-space:pre-line definiert, dass Zeilenumbrüche in der Darstellung nicht geschluckt werden sollen (wie eben auch in einem <pre>-Element). Daher ist meine Erwartungshaltung nicht unbegründet.

da hast du natürlich auch wieder Recht.

label:before { white-space: pre-line; content: "\a"; }
Soweit klappt das in meinem FF auch.
Das überrascht mich - auch hier hätte ich erwartet, dass das Linefeed als normales Whitespace-Zeichen interpretiert wird.
Du kennst anscheinend die Eigenschaft "white-space" noch nicht so gut? Ist mir vor diesem Fall auch so gegangen... *g*

Doch, die kenne ich eigentlich, hab sie sogar selbst schon ab und zu verwendet (der Wert "pre-line" war mir allerdings bisher fremd). Aber in diesem Fall hatte ich einfach nur Augen für die content-Eigenschaft, so dass mir das white-space davor völlig entgangen ist.

Jetzt, da ich deine beiden Beispiele *vollständig* gelesen und verstanden habe, teile ich deine Verwunderung.

Vinzenz hat Recht, wenn er meinen Lösungsansatz als akademische CSS-Übung (meine Worte) sieht. Ich werde wohl das Markup in eine Liste packen. Dann ist das Problem strukturell gelöst. Aber warum konnte ich es nicht mit reinen CSS-Mitteln lösen (akademische Frage)?

Ich weiß es nicht - aber ich kann die Motivation verstehen, der Frage trotz vorhandener Alternativlösung nachzugehen. ;-)

Ciao,
 Martin