Google Groups unterstützt keine neuen Usenet-Beiträge oder ‑Abos mehr. Bisherige Inhalte sind weiterhin sichtbar.
Schließen
CSS: Eigenschaften von Tabellenspalten
5 Aufrufe
Direkt zur ersten ungelesenen Nachricht
Helmut Richter
18.03.2013, 07:37:2718.03.13
an
Gehe ich recht in der Annahme, dass alle style-Eigenschaften von
Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe, Textausrichtung
vï¿œllig wirkungslos fï¿œr die Tabellenelemente sind, weil die keine Kinder der
Spalten sind und daher nichts erben? Dass aber die Spaltenbreite trotzdem an
die Nicht-Kinder vererbt wird? Falls ich damit richtig liege, wo hï¿œtte das
gestanden?
Konkreter Anwendungsfall: Ich mï¿œchte Spaltengruppen voneinander
abgrenzen. Bisherige Lï¿œsung: eine Klasse "separate" fï¿œr jedes einzelne
Tabellenelement dieser Spalte, bei der ein linker Rahmen (border-left)
dazugemalt wird. Sehr hï¿œsslich aus zwei Grï¿œnden:
Erstens kann das einzelne Tabellenelement nichts dafï¿œr; dieser Rahmen ist
Eigenschaft der Semantik der Spalte (oder noch besser: einer colgroup) und
nicht des einzelnen Elements.
Zweitens fï¿œhrt es (wenigstens bei mir) dazu, dass es CSS-Anweisungen mit sehr
ungleichmￜￜig vielen Selektoren gibt, von denen dann die falschen gewinnen:
th + td, th:empty + th, td.separate, th.separate {
border-left-style: solid;
border-left-width: 2px;
}
legt dickere Begrenzungslinien zwischen th und td und bei explizitem .separate
fest, und das soll *immer und ï¿œberall* gelten, selbst wenn man auf die ganz
dï¿œnnen Linien zwischen den Elementen mittels table.nolines verzichtet:
table.nolines td, table.nolines th {
border-style: none;
}
Die letztere Regel hat aber mehr Selektoren und ist daher stï¿œrker. Natï¿œrlich
kann man in der ersteren Regel noch ein paar ï¿œberflï¿œssige Selektoren dazufï¿œgen
(z.B. jeweils "table" am Anfang), aber es wird immer unï¿œbersichtlicher -- ich
hï¿œtte lieber hingeschrieben, was gemeint ist als irgendetwas kryptisches, aus
dem dann nach komplexen Regeln das Gemeinte gemacht wird, was spï¿œtestens bei
der nï¿œchsten ï¿œnderung nicht mehr funktioniert.
--
Helmut Richter
Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe, Textausrichtung
vï¿œllig wirkungslos fï¿œr die Tabellenelemente sind, weil die keine Kinder der
Spalten sind und daher nichts erben? Dass aber die Spaltenbreite trotzdem an
die Nicht-Kinder vererbt wird? Falls ich damit richtig liege, wo hï¿œtte das
gestanden?
Konkreter Anwendungsfall: Ich mï¿œchte Spaltengruppen voneinander
abgrenzen. Bisherige Lï¿œsung: eine Klasse "separate" fï¿œr jedes einzelne
Tabellenelement dieser Spalte, bei der ein linker Rahmen (border-left)
dazugemalt wird. Sehr hï¿œsslich aus zwei Grï¿œnden:
Erstens kann das einzelne Tabellenelement nichts dafï¿œr; dieser Rahmen ist
Eigenschaft der Semantik der Spalte (oder noch besser: einer colgroup) und
nicht des einzelnen Elements.
Zweitens fï¿œhrt es (wenigstens bei mir) dazu, dass es CSS-Anweisungen mit sehr
ungleichmￜￜig vielen Selektoren gibt, von denen dann die falschen gewinnen:
th + td, th:empty + th, td.separate, th.separate {
border-left-style: solid;
border-left-width: 2px;
}
legt dickere Begrenzungslinien zwischen th und td und bei explizitem .separate
fest, und das soll *immer und ï¿œberall* gelten, selbst wenn man auf die ganz
dï¿œnnen Linien zwischen den Elementen mittels table.nolines verzichtet:
table.nolines td, table.nolines th {
border-style: none;
}
Die letztere Regel hat aber mehr Selektoren und ist daher stï¿œrker. Natï¿œrlich
kann man in der ersteren Regel noch ein paar ï¿œberflï¿œssige Selektoren dazufï¿œgen
(z.B. jeweils "table" am Anfang), aber es wird immer unï¿œbersichtlicher -- ich
hï¿œtte lieber hingeschrieben, was gemeint ist als irgendetwas kryptisches, aus
dem dann nach komplexen Regeln das Gemeinte gemacht wird, was spï¿œtestens bei
der nï¿œchsten ï¿œnderung nicht mehr funktioniert.
--
Helmut Richter
Thomas 'PointedEars' Lahn
18.03.2013, 08:06:3818.03.13
an
Helmut Richter wrote:
> Gehe ich recht in der Annahme, dass alle style-Eigenschaften von
> Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe,
> Textausrichtung völlig wirkungslos für die Tabellenelemente sind, weil die
> Gehe ich recht in der Annahme, dass alle style-Eigenschaften von
> Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe,
> keine Kinder der Spalten sind und daher nichts erben? Dass aber die
> Spaltenbreite trotzdem an die Nicht-Kinder vererbt wird? Falls ich damit
> richtig liege, wo hätte das gestanden?
> Spaltenbreite trotzdem an die Nicht-Kinder vererbt wird? Falls ich damit
Dass Du mindestens teilweise fhcsal liegst, steht in
<http://quirksmode.org/css/css2/columns.html>
welches auf
<http://www.w3.org/TR/CSS21/tables.html>
verweist.
PointedEars
--
CSS ist keine Darstellungsvorschrift, sondern ein Darstellungsvorschlag
mit eingebautem "Ich weiß es aber besser"-Recht auf Seiten des userAgent.
(Georg Maaß in dcljs <amuna7$9fbuu$1...@ID-3551.news.dfncis.de>)
Thomas 'PointedEars' Lahn
18.03.2013, 08:16:3618.03.13
an
Helmut Richter wrote:
> Die letztere Regel hat aber mehr Selektoren und ist daher stärker.
> Natürlich kann man in der ersteren Regel noch ein paar überflüssige
> Selektoren dazufügen (z.B. jeweils "table" am Anfang), aber es wird immer
> unübersichtlicher -- ich hätte lieber hingeschrieben, was gemeint ist als
> funktioniert.
„!important“ – „das hier ist wichtiger als alles andere, es sei denn, das
andere ist mindestens genauso wichtig“?
PointedEars
--
Man kann mit JavaScript eine große Zahl von Roundtrips eliminieren und
damit die Usability erhöhen. Allerdings übersteigen die Möglichkeiten
von JavaScript die zerebralen Fähigkeiten der meisten Webmaster bei
Weitem. -- Johann Burkard in dag°
> Die letztere Regel hat aber mehr Selektoren und ist daher stärker.
> Natürlich kann man in der ersteren Regel noch ein paar überflüssige
> Selektoren dazufügen (z.B. jeweils "table" am Anfang), aber es wird immer
> unübersichtlicher -- ich hätte lieber hingeschrieben, was gemeint ist als
> irgendetwas kryptisches, aus dem dann nach komplexen Regeln das Gemeinte
> gemacht wird, was spätestens bei der nächsten Änderung nicht mehr
> funktioniert.
„!important“ – „das hier ist wichtiger als alles andere, es sei denn, das
andere ist mindestens genauso wichtig“?
PointedEars
--
Man kann mit JavaScript eine große Zahl von Roundtrips eliminieren und
damit die Usability erhöhen. Allerdings übersteigen die Möglichkeiten
von JavaScript die zerebralen Fähigkeiten der meisten Webmaster bei
Weitem. -- Johann Burkard in dag°
Susanne Jäger
18.03.2013, 08:22:1218.03.13
an
Helmut Richter schrieb am 18.03.2013 12:37:
> Gehe ich recht in der Annahme, dass alle style-Eigenschaften von
> Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe, Textausrichtung
> vï¿œllig wirkungslos fï¿œr die Tabellenelemente sind, weil die keine Kinder der
> Spalten sind und daher nichts erben? Dass aber die Spaltenbreite trotzdem an
> die Nicht-Kinder vererbt wird? Falls ich damit richtig liege, wo hï¿œtte das
> gestanden?
Nicht ganz, sie vererben zwar nicht, aber border, background, width und
> Gehe ich recht in der Annahme, dass alle style-Eigenschaften von
> Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe, Textausrichtung
> vï¿œllig wirkungslos fï¿œr die Tabellenelemente sind, weil die keine Kinder der
> Spalten sind und daher nichts erben? Dass aber die Spaltenbreite trotzdem an
> die Nicht-Kinder vererbt wird? Falls ich damit richtig liege, wo hï¿œtte das
> gestanden?
visibility funktionieren fï¿œr komplette Spalten.
"Tables - Table cells may belong to two contexts: rows and columns.
However, in the source document cells are descendants of rows, never of
columns. Nevertheless, some aspects of cells can be influenced by
setting properties on columns.
The following properties apply to column and column-group elements:"
<http://www.w3.org/TR/CSS21/tables.html#columns>
und wenn dein englisch reicht als Hintergrund Hixie's Natural Log: The
mystery of why only four properties apply to table columns
<http://ln.hixie.ch/?start=1070385285&count=1>
> Konkreter Anwendungsfall: Ich mï¿œchte Spaltengruppen voneinander
> abgrenzen. Bisherige Lï¿œsung: eine Klasse "separate" fï¿œr jedes einzelne
> Tabellenelement dieser Spalte, bei der ein linker Rahmen (border-left)
> dazugemalt wird. Sehr hï¿œsslich aus zwei Grï¿œnden:
bei solch komplexen Code-Beispielen irgendwann mental aus, bedeutend
einfacher ist es das Weitere mit Analysewerkzeugen im Browser
nachzuvollziehen. Vielleicht hilft ja col.separate {border: ....} schon.
Gruￜ
Susanne
Helmut Richter
18.03.2013, 08:53:2218.03.13
an
Erst einmal vielen Dank an beide Antwortenden. Die Stelle mit den vier an die
Stiefkinder vererbten Eigenschaften hatte ich nicht gleich gefunden --
manchmal habe ich Tomaten auf den Augen.
On Mon, 18 Mar 2013, Susanne Jï¿œger wrote:
> Kannst du mal ein passendes Beispiel online verfï¿œgbar machen?
Mache ich sonst gerne, wollte ich hier aber nicht, weil es genau an *dieser*
Stelle noch Ungereimheiten enthï¿œlt, die ich kenne. Ein Beispiel "ich dachte,
so geht es, geht aber nicht" ist sinnvoll, aber ein Beispiel "ich weiￜ schon,
dass es so nicht geht, aber kriegt ihr heraus, was ich eigentlich wollte"
finde ich doof.
> Vielleicht hilft ja col.separate {border: ....} schon.
Ja. Jedenfalls ist das ein weitaus einfacherer Ansatz als der bisherige und
rechtfertigt ein Neuschreiben dieses Teils des Stylesheets. Muss halt in den
Rest hineinpassen; da muss ich ordentlich nachdenken, welche schon
existierenden Teile mitbetroffen sein kï¿œnnen. Ich versuche mï¿œglichst viel per
Default zu lï¿œsen und Klassen fï¿œr Sonderwï¿œnsche so zu bilden, dass man sie
*unabhï¿œngig* voneinander einsetzen kann. Genau das funktionierte hier nicht,
weil die sich ins Gehege kamen.
--
Helmut Richter
Stiefkinder vererbten Eigenschaften hatte ich nicht gleich gefunden --
manchmal habe ich Tomaten auf den Augen.
On Mon, 18 Mar 2013, Susanne Jï¿œger wrote:
> Kannst du mal ein passendes Beispiel online verfï¿œgbar machen?
Stelle noch Ungereimheiten enthï¿œlt, die ich kenne. Ein Beispiel "ich dachte,
so geht es, geht aber nicht" ist sinnvoll, aber ein Beispiel "ich weiￜ schon,
dass es so nicht geht, aber kriegt ihr heraus, was ich eigentlich wollte"
finde ich doof.
> Vielleicht hilft ja col.separate {border: ....} schon.
rechtfertigt ein Neuschreiben dieses Teils des Stylesheets. Muss halt in den
Rest hineinpassen; da muss ich ordentlich nachdenken, welche schon
existierenden Teile mitbetroffen sein kï¿œnnen. Ich versuche mï¿œglichst viel per
Default zu lï¿œsen und Klassen fï¿œr Sonderwï¿œnsche so zu bilden, dass man sie
*unabhï¿œngig* voneinander einsetzen kann. Genau das funktionierte hier nicht,
weil die sich ins Gehege kamen.
--
Helmut Richter
Helmut Richter
18.03.2013, 14:08:3618.03.13
an
On Mon, 18 Mar 2013, Helmut Richter wrote:
> > Vielleicht hilft ja col.separate {border: ....} schon.
>
> Ja. Jedenfalls ist das ein weitaus einfacherer Ansatz als der bisherige und
> rechtfertigt ein Neuschreiben dieses Teils des Stylesheets.
Getan. Ist sogar noch einfacher: es wird einfach ein Rahmen um alle thead,
> > Vielleicht hilft ja col.separate {border: ....} schon.
>
> Ja. Jedenfalls ist das ein weitaus einfacherer Ansatz als der bisherige und
> rechtfertigt ein Neuschreiben dieses Teils des Stylesheets.
tbody, tfoot sowie colgroup gezogen. Damit sind 95% aller Fï¿œlle erfasst, wo
ich das Bedï¿œrfnis habe, eine Tabelle zu untergliedern. Da man keines dieser
Elemente unbedingt verwenden muss, hï¿œlt sich die Zwangsbeglï¿œckung in
Grenzen. Alle ï¿œbrige machen dann eben lokalere style-Anweisungen.
Ein Fall funktioniert nicht wie erwartet. Ich dachte, wenn die Tabelle
eine "border-width: 2px" hat, dass das auch dann an Kinder wie <tbody>
mittels explizitem "border-width: inherit" vererbt werden mï¿œsste, wenn die
Tabelle selbst ihren Rahmen mit "border-style: hidden" weglï¿œsst.
Firebug behauptet aber eine ererbte "border-width: 0px" fï¿œr <tbody>.
Mysteriï¿œs.
Dafï¿œr gibts ein Beispiel mit reichhaltigen style-Kommentaren: die erste
Tabelle in http://hr.userweb.mwn.de/srv/tab.html . (Diese Webseite enthï¿œlt
ein paar real vorkommende Tabellen aus verschiedenen Artikeln zum Test, ob die
Voreinstellungen praktisch sind.)
Schlimm ist das nicht: ich kann ja "border-width: 2px" bei den Kindern von
<table> wiederholen. Ich wollte nur so viel wie mï¿œglich vererben, z.B. auch
die Rahmenfarbe und -stï¿œrke, wenn jemand lieber grï¿œn-klotzig statt
stahlblau-schlank bevorzugt.
--
Helmut Richter
Susanne Jäger
19.03.2013, 07:09:1719.03.13
an
Helmut Richter schrieb am 18.03.2013 12:37:
> Gehe ich recht in der Annahme, dass alle style-Eigenschaften von
> Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe, Textausrichtung
> vï¿œllig wirkungslos fï¿œr die Tabellenelemente sind, weil die keine Kinder der
> Spalten sind und daher nichts erben?
Wenn wir Glï¿œck haben, kï¿œnnte das Ganze in wenigen Jahren deutlich
> Tabellenspalten (also von <col>-Elementen) wie Rahmen, Farbe, Textausrichtung
> vï¿œllig wirkungslos fï¿œr die Tabellenelemente sind, weil die keine Kinder der
> Spalten sind und daher nichts erben?
einfach werden.
Selectors Level 4 - 14. Grid-Structural Selectors
<http://dev.w3.org/csswg/selectors4/#table-pseudos>
Ist bisher wohl noch nirgends implementiert, aber die Idee klingt nicht
schlecht. Aufmerksam wurde ich durch eine Anfrage in der Mailingliste
der CSS-WG
<http://lists.w3.org/Archives/Public/www-style/2013Mar/0291.html>ff
Es geht voran ;-)
Susanne
0 neue Nachrichten