expertenaustausch > comm.* > comm.infosystems.www.authoring.misc

Stefan Froehlich (04.01.2020, 13:06)
Ich wollte die Feiertage dazu nützen, eine etwas angestaubte
Applikation von Tabellen mit <tr class="odd|even"> auf das
modernere tr:nth-child(odd|even) umzustellen. Hat leider nicht wie
geplant geklappt, da sich rund ein Dutzend größere Tabellen
widersetzt haben, wegen einer Struktur sinngemäß wie folgt:

#v+
<tr class="odd"><td>1</td></tr>
<tr class="even"><td>2</td></tr>
<tr class="even"><td>2.1</td></tr>
<tr class="even"><td>2.2</td></tr>
<tr class="odd"><td>3</td></tr>
<tr class="even"><td>4</td></tr>
<tr class="odd"><td>5</td></tr>
<tr class="odd"><td>5.1</td></tr>
#v-

#v+
tr.odd { background: #eee; }
tr.even { background: #ccc; }
#v-

Als Beispiel könnte eine Rechnung dienen, bei der einzelne
Positionen mit Lieferzuschlägen versehen sind, d.h. es handelt sich
technisch und semantisch sind das vollwertige Tabellenzeilen, aber
*optisch* sollen einzelne Exemplare davon zusammengefasst werden;
die oben dargestellte Struktur ist leicht erzeugt.

Ziel wären Tabellen der Form:

#v+
<tr class="normal"><td>1</td></tr>
<tr class="normal"><td>2</td></tr>
<tr class="addon"><td>2.1</td></tr>
<tr class="addon"><td>2.2</td></tr>
<tr class="normal"><td>3</td></tr>
<tr class="normal"><td>4</td></tr>
<tr class="normal"><td>5</td></tr>
<tr class="addon"><td>5.1</td></tr>
#v-

Aber gibt es irgendeine Möglichkeit, die addon-Zeilen mit den
gleichen Attributen wie die jeweils darüberliegende normal-Zeile
auszustatten und gleichzeitig die normal-Zeilen mit nth-child oder
nth-of-type zu formatieren?

Ich war schon knapp davor, mit mehreren <tbody> zu experimentieren,
also:

#v+
<tbody>
<tr class="normal"><td>1</td></tr>
</tbody>
<tbody>
<tr class="normal"><td>2</td></tr>
<tr class="addon"><td>2.1</td></tr>
<tr class="addon"><td>2.2</td></tr>
</tbody>
<tbody>
<tr class="normal"><td>3</td></tr>
</tbody>
<tbody>
<tr class="normal"><td>4</td></tr>
</tbody>
<tbody>
<tr class="normal"><td>5</td></tr>
<tr class="addon"><td>5.1</td></tr>
</tbody>
#v-

Aber das erscheint mir eine arg missbräuchliche Verwendung; zudem
sind die meisten der betroffenen Tabellen 99% der Zeit entartet,
d.h. ohne jegliche addon-Zeile. Dann wäre jede Tabellenzeile ein
eigener Body, und irgendwie widerstrebt mir das sehr.

Gibt es noch weitere Möglichkeiten?

Servus,
Stefan
Maik Koenig (04.01.2020, 13:52)
Am 04.01.2020 um 12:06 schrieb Stefan Froehlich:

> Ich wollte die Feiertage dazu nützen, eine etwas angestaubte
> Applikation von Tabellen mit <tr class="odd|even"> auf das
> modernere tr:nth-child(odd|even) umzustellen. Hat leider nicht wie
> geplant geklappt, da sich rund ein Dutzend größere Tabellen
> widersetzt haben, wegen einer Struktur sinngemäß wie folgt: [...]


Warum umstellen wenn es funktioniert? Bringt die neue Variante
irgendwelche Vorteile im Vergleich zur alten Lösung?

Greetz,
MK
Stefan Froehlich (04.01.2020, 14:09)
On Sat, 04 Jan 2020 12:52:46 Maik Koenig wrote:
> Am 04.01.2020 um 12:06 schrieb Stefan Froehlich:
> [...]


> Warum umstellen wenn es funktioniert? Bringt die neue Variante
> irgendwelche Vorteile im Vergleich zur alten Lösung?


Es wäre z.B. einfacher, sollte jemand auf die Idee kommen, 3 Farben
verwenden zu wollen - gut, das nicht arg wahrscheinlich, es ist für
die Layouter heutzutage wohl die üblichere Variante.

Und ich könnte meinen Code an ein paar Stellen aufräumen bzw.
modularer gestalten, weil ich nicht mehr auf den zZt mitgeschleppten
Zähler achten müsste.

Aber klar, wenn sich keine *gute* Lösung findet, kann und werde ich
bei der aktuellen bleiben.

Servus,
Stefan
Maik Koenig (04.01.2020, 14:45)
Am 04.01.2020 um 13:09 schrieb Stefan Froehlich:
> On Sat, 04 Jan 2020 12:52:46 Maik Koenig wrote:
> Es wäre z.B. einfacher, sollte jemand auf die Idee kommen, 3 Farben
> verwenden zu wollen - gut, das nicht arg wahrscheinlich, es ist für
> die Layouter heutzutage wohl die üblichere Variante.
> Und ich könnte meinen Code an ein paar Stellen aufräumen bzw.
> modularer gestalten, weil ich nicht mehr auf den zZt mitgeschleppten
> Zähler achten müsste.


Die Tabellen werden ja vermutlich automatisch erzeugt. Kannst Du in dem
Automatismus nicht dafür sorgen, dass die zweite Zeile gar keine echte
Zeile wird sondern die notwendigen Daten pro Spalte direkt innerhalb der
Zelle liegen und bloss durch <br/> getrennt sind?

Beispiel:

<tr>
<td>a</td> <td>b</td>
</tr>
<tr>
<td>eins</td> <td>zwei</td>
</tr>
<tr>
<td>eins_Zusatz</td> <td>zwei_Zusatz</td>
</tr>

wird zu:
<tr>
<td>a</td> <td>b</td>
</tr>
<tr>
<td>eins<br/>eins_Zusatz</td> <td>zwei<br/>zwei_Zusatz</td>
</tr>

Dann würde tr:nth-child(odd|even) so funktionieren, dass
zusammengehörige Daten gleich formatiert sind.

Greetz,
MK
Stefan Froehlich (04.01.2020, 15:20)
On Sat, 04 Jan 2020 13:45:50 Maik Koenig wrote:
> Am 04.01.2020 um 13:09 schrieb Stefan Froehlich:
> > Und ich könnte meinen Code an ein paar Stellen aufräumen bzw.
> > modularer gestalten, weil ich nicht mehr auf den zZt
> > mitgeschleppten Zähler achten müsste.


> Die Tabellen werden ja vermutlich automatisch erzeugt. Kannst Du
> in dem Automatismus nicht dafür sorgen, dass die zweite Zeile gar
> keine echte Zeile wird sondern die notwendigen Daten pro Spalte
> direkt innerhalb der Zelle liegen und bloss durch <br/> getrennt
> sind?


> <tr>
> <td>a</td> <td>b</td>
> </tr>
> <tr>
> <td>eins<br/>eins_Zusatz</td> <td>zwei<br/>zwei_Zusatz</td>
> </tr>


Das wäre einfach und würde in der Tat den hier beschriebenen Zweck
erreichen.

Ist nicht ganz elegant und ich bin mir nicht sicher, ob das wirklich
unter allen Umständen eine akzeptable Formatierung erzeugt, aber vor
allem (das hatte ich im OP nicht erwähnt, weil es in der originalen
Formatierung kein Problem war) werden diese Zeilen an einigen
Stellen mit kleinerer, kursiver Schrift dargestellt; das würde ich
dann verlieren.

Ich habe ja die Befürchtung, dass das, was mir vorschwebt, nicht
möglich ist. Letztlich bräuchte ich wohl colgroup für Zeilen (aber
eben so, wie colgroup gelöst ist, nicht so wie das existierende
scope-Attribut).

Servus,
Stefan
Maik Koenig (04.01.2020, 17:17)
Am 04.01.2020 um 14:20 schrieb Stefan Froehlich:

> Das wäre einfach und würde in der Tat den hier beschriebenen Zweck
> erreichen.
> Ist nicht ganz elegant und ich bin mir nicht sicher, ob das wirklich
> unter allen Umständen eine akzeptable Formatierung erzeugt, aber vor
> allem (das hatte ich im OP nicht erwähnt, weil es in der originalen
> Formatierung kein Problem war) werden diese Zeilen an einigen
> Stellen mit kleinerer, kursiver Schrift dargestellt; das würde ich
> dann verlieren.


Nicht zwangsläufig. Wenn Du ohnehin die "Sonderzeilen" in die einzelnen
Felder einfügen musst, könntest Du für diese "Sonderzeilen" auch bei
Bedarf eine entsprechende Klasse und damit Formatierung vergeben. Das
ist problemlos machbar.

Greetz,
MK
Susanne Jäger (06.01.2020, 00:19)
Stefan Froehlich wrote on 04.01.20 12:06:
[..]
> gleichen Attributen wie die jeweils darüberliegende normal-Zeile
> auszustatten und gleichzeitig die normal-Zeilen mit nth-child oder
> nth-of-type zu formatieren?


ohne das jetzt ausprobiert/nachgebaut zu haben, hilft dir / funktioniert
der + (adjacent sibling) selector weiter? Also Sonderregel für tr.normal
+ tr.addon und/oder umgekehrt.

Gruß
Susanne
Stefan Froehlich (07.01.2020, 18:09)
On Sun, 05 Jan 2020 23:19:50 Susanne Jäger wrote:
> Stefan Froehlich wrote on 04.01.20 12:06:
> ohne das jetzt ausprobiert/nachgebaut zu haben, hilft dir /
> funktioniert der + (adjacent sibling) selector weiter? Also
> Sonderregel für tr.normal + tr.addon und/oder umgekehrt.


Wenn, dann bin ich noch nicht draufgekommen wie. Mit

#v+
tr:nth-child(odd)+tr.addon {
background: lightblue;
}
#v-

lässt sich zwar die erste Folgezeile einfärben, danach steht man
aber immer noch vor dem gleichen Problem.

Ich fürchte, die Quintessenz läuft auf "geht leider nicht" hinaus.

Servus,
Stefan
Stefan Froehlich (07.01.2020, 18:14)
On Sat, 04 Jan 2020 16:17:02 Maik Koenig wrote:
> Am 04.01.2020 um 14:20 schrieb Stefan Froehlich:
> Nicht zwangsläufig. Wenn Du ohnehin die "Sonderzeilen" in die einzelnen
> Felder einfügen musst, könntest Du für diese "Sonderzeilen" auch bei
> Bedarf eine entsprechende Klasse und damit Formatierung vergeben. Das
> ist problemlos machbar.


Im Sinn von "<td>eins<br/><span class="addon">eins_Zusatz</span></td>"?

Das ist dann ja noch um eine Klasse grausiger, als das Original
(weil nicht nur die Klasse unschön sind, sondern auch das HTML).

In der Erzeugung wäre es auch nicht einfacher - bislang gibt es da
einen Code für alle Zeilen (aus Sicht der Programmlogik
unterscheiden sich die ja fast nicht), das ginge dann auch nicht
mehr.

Ich glaube, ich beim status quo :-(

Servus,
Stefan
Maik Koenig (07.01.2020, 19:40)
Am 07.01.2020 um 17:14 schrieb Stefan Froehlich:

> Im Sinn von "<td>eins<br/><span class="addon">eins_Zusatz</span></td>"?


Jepps.

> Das ist dann ja noch um eine Klasse grausiger, als das Original
> (weil nicht nur die Klasse unschön sind, sondern auch das HTML).


Ja nun, einen Tod musste sterben. Ich sehe nicht, wie man deine
Anforderungen ansonsten ohne JavaScript umsetzen könnte.

Greetz,
MK
Stefan Froehlich (08.01.2020, 08:28)
On Tue, 07 Jan 2020 18:40:42 Maik Koenig wrote:
> Am 07.01.2020 um 17:14 schrieb Stefan Froehlich:
> > Das ist dann ja noch um eine Klasse grausiger, als das Original
> > (weil nicht nur die Klasse unschön sind, sondern auch das HTML).

> Ja nun, einen Tod musste sterben. Ich sehe nicht, wie man deine
> Anforderungen ansonsten ohne JavaScript umsetzen könnte.


Keine Ahnung, warum immer die Sachen, die ich brauche, in die
Kategorie "ewiges Leben" fallen. Für Spalten wäre das alles ganz
einfach...

Servus,
Stefan
Andreas Borutta (08.01.2020, 14:49)
Stefan Froehlich:

[..]
> sind die meisten der betroffenen Tabellen 99% der Zeit entartet,
> d.h. ohne jegliche addon-Zeile. Dann wäre jede Tabellenzeile ein
> eigener Body, und irgendwie widerstrebt mir das sehr.


Ich kann Dein Widerstreben nachvollziehen. Schön ist es nicht, viele
einzelne TR als "Gruppe" zu deklarieren.

Aber im Kontext erscheint es mir dennoch als die beste Variante.

Missbrauch im engen Sinne kann ich jedenfalls bei der Beschreibung
"The tbody element represents a block of rows that consist of a body
of data for the parent table element" nicht sehen.


Andreas
Andreas Borutta (08.01.2020, 14:50)
Stefan Froehlich:

[..]
> sind die meisten der betroffenen Tabellen 99% der Zeit entartet,
> d.h. ohne jegliche addon-Zeile. Dann wäre jede Tabellenzeile ein
> eigener Body, und irgendwie widerstrebt mir das sehr.


Ich kann Dein Widerstreben nachvollziehen. Schön ist es nicht, viele
einzelne TR als "Gruppe" zu deklarieren.

Aber im Kontext erscheint es mir dennoch als die beste Variante.

Missbrauch im engen Sinne kann ich jedenfalls bei der Beschreibung
"The tbody element represents a block of rows that consist of a body
of data for the parent table element" nicht sehen.


Vermutlich könntest Du auf die beiden Klassen "normal" und "addon"
ganz verzichten und die Gestaltung mit nth-of-child-Selektoren
erledigen.

Andreas
Ähnliche Themen