Tabellenbreite

[bleumi85]

Hallo liebes Forum,

ich bin mal wieder auf der Suche nach Hilfe.

Ich habe mir folgende Tabelle angelegt: Beispieltabelle

Jetzt hätte ich bspw. gerne die erste Spalte auf 20% der Breite, die zweite und dritte und Spalte auf 30% der Breite und die Vierte wieder auf 20%. Ich hab aber keine Ahnung wie ich das anstelle und meine bisherigen Bemühungen verliefen im Sande. Kann mir jemand weiterhelfen?

[Linuchs]

Kann mir jemand weiterhelfen?

Ja. Sprich die Spalten doch an:

tr > td:nth-of-type(1) {width:20%;}
tr > td:nth-of-type(2) {width:30%;}
tr > td:nth-of-type(3) {width:30%;}
tr > td:nth-of-type(4) {width:20%;}

Da kannst du dann bei Zahlen auch gleich text-align:right; hinzufügen.

Linuchs

[bleumi85]

Hi Linuchs,

wenn ich das ganze so umsetze wie du es mir geschrieben hast, müsste ich doch auf 100% kommen, oder? Leider ist das nicht der Fall. Zumindest füllt die Tabelle nicht den gesamten Platz aus. Mein Problem besteht also immer noch.

[Vollzitat entfernt]

[Auge]

Hallo

wenn ich das ganze so umsetze wie du es mir geschrieben hast, müsste ich doch auf 100% kommen, oder? Leider ist das nicht der Fall. Zumindest füllt die Tabelle nicht den gesamten Platz aus. Mein Problem besteht also immer noch.

Dann solltest du erst einal definieren, was 100% sind? Die von Linuchs gezeigte Code ergibt zumindest 100% des für die Inhalte benötigten Platzes und etwas mehr. Wenn du 100% von irgendetwas anderem haben willst, z.B. 100% der Breite eines Vorfahrenelements oder feste 600px, musst du diese Breite für die Tabelle selbst festlegen.

Dann werden die 20% und 30% auf diese übergeordnete Breitenangabe bezogen und, wie festgelegt, auf die Spalten aufgeteilt.

Tschö, Auge

[bleumi85]

Hi,

das Elternelement sollte doch die Tabelle sein, oder? Dieser Tabelle gebe ich eine feste Breite von 44% der Bildschirmgröße. Jetzt war ich davon ausgegangen, dass die Spalten, wenn ich ihnen bspw. jeweils 25% Platz zugestehe diesen kompletten "Rahmen" ausfüllen, sprich alle 11% groß sind. Wo ist mein Denkfehler?

[Vollzitat entfernt]

[Auge]

Hallo

das Elternelement sollte doch die Tabelle sein, oder?

Jein, zumindest nicht direkt. Direkte Vorfahrenelemente von th und td sind die Zeilen tr. Zwischen denen und table kann noch thead, tbody und/oder tfoot notiert sein. Implizit werden diese Elemente sowieso von den Browsern ins DOM eingefügt. table ist bestenfalls Großelternelement, sonst Urgroßelter.

Dieser Tabelle gebe ich eine feste Breite von 44% der Bildschirmgröße. Jetzt war ich davon ausgegangen, dass die Spalten, wenn ich ihnen bspw. jeweils 25% Platz zugestehe diesen kompletten "Rahmen" ausfüllen, sprich alle 11% groß sind.

So soll das sein. Das Dabblet zeigt auch, dass die Tabelle selbst 44% der Breite belegt. Da du die Tabelle aber mit display: block; versehen hast, ist sie selbst nicht mehr Bestandteil der Tabelle. Kommentiere mal das display: block; im Dabblet aus und du wirst sehen, dass sich die Spalten auf die gesamte Breite abzüglich des für die Tabelle selbst geltenden Paddings von 1em verteilen.

Tschö, Auge

[bleumi85]

Hi Auge,

danke für die schnelle Antwort. Du hast recht. Jetzt nehmen die Spalten wieder die gesamte Breite des "Rahmens" an. Allerdings sind jetzt meine width-Angaben wieder völlig wirkunslos. Es bleibt dabei, dass alle Spalten gleich groß sind. Wie bekomme ich es denn nun hin dass meine Spalten eben nicht alle 25% breit sind sondern vielleicht, 10-20-30-40?

[Vollzitat entfernt]

[Gunnar Bittersmann]

@@bleumi85

Wie bekomme ich es denn nun hin dass meine Spalten eben nicht alle 25% breit sind sondern vielleicht, 10-20-30-40?

Erstmal ein Tip, wie du es hinbekommst, dass deine Postings nicht so hoch sind:

Zitiere nur das, auf das du dich beziehst. TOFU ist hier unerwünscht.

LLAP 🖖

[MrMurphy1]

Hallo

dann doch eher

tr > th:nth-of-type(1),
tr > td:nth-of-type(1) {
   width:20%;
}
tr > th:nth-of-type(2),
tr > td:nth-of-type(2) {
   width:30%;
}
tr > th:nth-of-type(3),
tr > td:nth-of-type(3) {
   width:30%;
}
tr > th:nth-of-type(4),
tr > td:nth-of-type(4) {
   width:20%;
}

Allerdings würde ich statt einer id besser eine class verwenden, zum Beispiel class="konto". Zudem ist der Aufbau der Tabelle strikt reglementiert und es sollen wohl auch keine verschachtelten Tabellen verwendet werden. Eindeutiger und kürzer wäre dann

.konto>td>:nth-child(1),
.konto>td>:nth-child(4) {
   width:20%;
}
.konto>td>:nth-child(2),
.konto>td>:nth-child(3) {
   width:30%;
}

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

Hallo

dann doch eher

tr > th:nth-of-type(1),
tr > td:nth-of-type(1) {
   width:20%;
}

Warum? Wenn für Zellen keine Breite angegeben ist, richtet die sich nach der Breite anderer Zellen der jeweiligen Spalte.

Wenn allerdings td und th die einzigen Kinder von tr sind, ist der Selektor überspezifiziert: tr > kann weg.

Und da td und th in Tabellenzeilen auch gemischt auftreten können, ist :nth-child() hier der Vorzug gegenüber :nth-of-type() zu geben.

Allerdings würde ich statt einer id besser eine class verwenden, zum Beispiel class="konto".

Warum? Wenn das die einzige Tabelle der Art ist, ist eine ID angebracht.

.konto>td>:nth-child(1),
.konto>td>:nth-child(4) {
   width:20%;
}

Du meintest vermutlich tr, nicht td. Aber auch damit wird das so nichts, da tr nicht Kinder des Tabellenelements sind.

LLAP 🖖

[Linuchs]

tr > th:nth-of-type(1),
tr > td:nth-of-type(1) {
   width:20%;
}

Wenn allerdings td und th die einzigen Kinder von tr sind, ist der Selektor überspezifiziert: tr > kann weg.

Wieso? Ich meine doch die erste Zelle jeder Zeile. Wie könnte ich dann die erste Zelle der Tabelle ansprechen? Zum Beispiel für eine Hintergrund-Farbe.

Linuchs

[Der Martin]

Hallo,

Wenn allerdings td und th die einzigen Kinder von tr sind, ist der Selektor überspezifiziert: tr > kann weg.

Wieso? Ich meine doch die erste Zelle jeder Zeile.

ja, das hat aber damit nichts zu tun. Da td und th immer Kinder von tr sind, ist der Selektor tr>td bzw. tr>th redundant formuliert; td oder th allein (plus eventuelle Pseudoklassen) genügen.

Wie könnte ich dann die erste Zelle der Tabelle ansprechen?

Du meinst sicher die erste Zeile? Voilà:

table tr:first-of-type

Oder wirklich die erste Zelle in der ersten Zeile? Geht auch:

table tr:first-of-type th:first-of-type,
table tr:first-of-type td:first-of-type

Zwei Angaben, um der sehr wahrscheinlichen Möglichkeit Rechnung zu tragen, dass die erste Zelle eine Kopfzelle (Zeilen- oder Spaltenkopf) ist.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Wie könnte ich dann die erste Zelle der Tabelle ansprechen?

Du meinst sicher die erste Zeile? Voilà:

table tr:first-of-type

Vermutlich meint er den Tabellenkopf. Also thead bzw. thead tr bzw. thead th.

So, wie es bleumi85 auch umgesetzt hat.

table tr:first-of-type th:first-of-type,
table tr:first-of-type td:first-of-type

Zwei Angaben, um der sehr wahrscheinlichen Möglichkeit Rechnung zu tragen, dass die erste Zelle eine Kopfzelle (Zeilen- oder Spaltenkopf) ist.

Nein. Dass eine Zelle eine Kopfzelle (Zeilen- oder Spaltenkopf) ist, dem trägt die Auszeichnung als th Rechnung, nicht das Styling per :first-of-type oder :first-child.

LLAP 🖖

[Der Martin]

Hallo,

Du meinst sicher die erste Zeile? Voilà:

table tr:first-of-type

Vermutlich meint er den Tabellenkopf. Also thead bzw. thead tr bzw. thead th.

möglich, sogar sinnvoll - aber das erschien mir zu trivial, als dass man nochmal danach fragen würde. Daher bin ich davon ausgegangen, dass (aus Bequemlichkeit?) kein thead, tbody, oder tfoot notiert wurde, sondern einfach tr innerhalb von table.

table tr:first-of-type th:first-of-type,
table tr:first-of-type td:first-of-type

Zwei Angaben, um der sehr wahrscheinlichen Möglichkeit Rechnung zu tragen, dass die erste Zelle eine Kopfzelle (Zeilen- oder Spaltenkopf) ist.

Nein. Dass eine Zelle eine Kopfzelle (Zeilen- oder Spaltenkopf) ist, dem trägt die Auszeichnung als th Rechnung, nicht das Styling per :first-of-type oder :first-child.

Korrekt. Deswegen verstehe ich dein "Nein" nicht. Der obige Selektor spricht die erste Zelle einer Tabelle an, egal ob sie als th oder td notiert ist.

Ciao,
 Martin

[Linuchs]

table tr:first-of-type th:first-of-type,
table tr:first-of-type td:first-of-type

Ich dachte, man könnte das vielleicht verkürzen auf

tr:nth-of-type(1) *:nth-of-type(1) {background:#f00}

aber auch hier wird jede tr zur ersten, wenn nur vorher was passiert, etwa thead, tbody, ...

... auch table tr:first-of-type gibt's mehrere ... so ein Blödsinn.

Linuchs

[Gunnar Bittersmann]

@@Linuchs

table tr:first-of-type th:first-of-type,
table tr:first-of-type td:first-of-type

Ich dachte, man könnte das vielleicht verkürzen auf

tr:nth-of-type(1) *:nth-of-type(1) {background:#f00}

Das könnte man, wenn man davon ausgeht, dass es außer th und tdkeine anderen Elementtypen in tr gibt.

Allerdings selektiert das was anderes als du vermutlich denkst: bei

<table>
  <tr>
    <th>foo</th>
    <td>bar</td>
  </tr>
</table>

nämlich beide Zellen.

Wie ich in diesem Thread schon sagte, will man hier wohl eher :nth-child() verwenden, nicht :nth-of-type.

... auch table tr:first-of-type gibt's mehrere ... so ein Blödsinn.

Was Blödsinn ist: table tr:first-of-type zu verwenden, wenn man thead > tr meint.

LLAP 🖖

[Der Martin]

Hi,

Das könnte man, wenn man davon ausgeht, dass es außer th und tdkeine anderen Elementtypen in tr gibt.

gibt es die denn? Darf es welche geben?

Allerdings selektiert das was anderes als du vermutlich denkst: bei

<table>
  <tr>
    <th>foo</th>
    <td>bar</td>
  </tr>
</table>

nämlich beide Zellen.

Ah, stimmt. Jetzt habe ich meinen Denkfehler auch erkannt.

Wie ich in diesem Thread schon sagte, will man hier wohl eher :nth-child() verwenden, nicht :nth-of-type.

Ja, genau.

So long,
 Martin

[Matthias Apsel]

Hallo Der Martin,

Das könnte man, wenn man davon ausgeht, dass es außer th und tdkeine anderen Elementtypen in tr gibt.

gibt es die denn? Darf es welche geben?

script und template, fehlt im Wiki noch, vielleicht könnte das jemand, zum Beispiel @Matthias Scharwies ergänzen.

Bis demnächst
Matthias

[Linuchs]

... Da td und th immer Kinder von tr sind, ist der Selektor tr>td bzw. tr>th redundant formuliert; td oder th allein (plus eventuelle Pseudoklassen) genügen.

Okay, dann habe ich die Zählung im DOM-Konzept überhaupt nicht verstanden.

Ich könnte mir mit Javascript doch wohl sämtliche td greifen und dem ersten im Dokument eine Hintergrund-Farbe geben?

var arr_td = document.getElementsByTagName( "td" );
arr_td[0].style.background = "#ff0";

Aber CSS sieht das gaaaanz anders ... null (Ziffer 0) ist dort sowieso 1 ...

td:nth-of-type(1) {background:#f00}

... und tatsächlich, der haut das in jede Tabelle, in jede Zeile ...

kopfschüttel

Da lasse ich es bewusst bei der Redundanz, falls CSS später mal die Logik entdeckt. Oder meinetwegen, um meine Sichtweise darzustellen:

tr > td:nth-of-type(1) {background:#f00}

Linuchs

[Tabellenkalk]

Hallo,

... und tatsächlich, der haut das in jede Tabelle, in jede Zeile ...

tr > td:nth-of-type(1) {background:#f00}

Klar, damit selektierst jede erste Tabellenzelle die direktes Kind einer beliebigen Tabellenzeile ist. Also jede Zeile, jede Tabelle.

Wenn es doch nur eine Möglichkeit gäbe zu sagen, nimm nur die erste Zeile...

Gruß
Kalk

[Der Martin]

Hallo,

... Da td und th immer Kinder von tr sind, ist der Selektor tr>td bzw. tr>th redundant formuliert; td oder th allein (plus eventuelle Pseudoklassen) genügen.

Okay, dann habe ich die Zählung im DOM-Konzept überhaupt nicht verstanden.

sieht so aus.

Ich könnte mir mit Javascript doch wohl sämtliche td greifen und dem ersten im Dokument eine Hintergrund-Farbe geben?

var arr_td = document.getElementsByTagName( "td" );
arr_td[0].style.background = "#ff0";

Das bedeutet übersetzt: Besorge mir eine Liste sämtlicher td-Elemente im Dokument(!) und weise dem ersten davon einen bestimmten Style zu.
Wohlgemerkt, du rufst die Methode getElementsByTagName() bezogen auf document auf, sie sucht also das ganze Dokument ab.

Aber CSS sieht das gaaaanz anders ... null (Ziffer 0) ist dort sowieso 1 ...

Ja, das stört mich auch immer wieder ...

td:nth-of-type(1) {background:#f00}

... und tatsächlich, der haut das in jede Tabelle, in jede Zeile ...

Ja, weil die Pseudoklasse :nth-of-type(n) ebenso wie ihre Verwandten sich immer auf die Reihenfolge bezogen auf das Elternelement beziehen, nicht global aufs ganze Dokument.

kopfschüttel

Schüttel den Kopf, wenn es dir hilft; wichtig ist hier nur zu erkennen: CSS selektiert immer in einem Ast des DOM, die Javascript-Methoden in dem Element, auf dem sie aufgerufen werden. Ja, getElementsByTagName() kann auch auf einem beliebigen anderen Element als document aufgerufen werden. Und dann verhält es sich ebenso "lokal" wie ein entsprechender CSS-Selektor.

Da lasse ich es bewusst bei der Redundanz, falls CSS später mal die Logik entdeckt.

Du meinst wohl: Falls du später mal die Logik entdeckst. ;-)

So long,
 Martin

[Linuchs]

Du meinst wohl: Falls du später mal die Logik entdeckst. ;-)

Naja, die CSS-Logik ist nicht direkt meine, da muss ich ein-, zweimal um die Ecke denken.

Wer war der erste Mensch im Weltraum?

Laut CSS-Logik eine ganze Menge, denn für jede beliebige Nation gab es einen ersten.

Und ich bin wahrscheinlich laut CSS-Logik der cleverste Mensch der Welt. Da gibt es dann Milliarden ... Für jede Kombination aus Krankenhaus und Geburtsminute einen ...

Traue keiner Statistik, die du nicht selbst gefälscht hast.

Linuchs

[Der Martin]

Hi,

Du meinst wohl: Falls du später mal die Logik entdeckst. ;-)

Naja, die CSS-Logik ist nicht direkt meine, da muss ich ein-, zweimal um die Ecke denken.

Wer war der erste Mensch im Weltraum?

Laut CSS-Logik eine ganze Menge, denn für jede beliebige Nation gab es einen ersten.

du willst es nicht verstehen, oder? *seufz*

Bei jeder Klassifizierung, egal ob "der erste" oder "der einzige", ist es für die Ergebnismenge entscheidend, auf welche Ausgangsmenge sich die Aussage bezieht. Und die Bedeutung von :first-child oder :first-of-type und Konsorten ist nun mal per Definition festgelegt auf die Menge ihrer selbst und ihrer Geschwister. (Hmm ... war das zu explizit? Bin ich auch mein eigener Bruder?)

Und ich bin wahrscheinlich laut CSS-Logik der cleverste Mensch der Welt.

Bestimmt, wenn du die Aussage auf eine Menge beziehst, der du selbst, eine Biberkolonie, ein Steinpilz und ein Putzlappen angehören.

Traue keiner Statistik, die du nicht selbst gefälscht hast.

Oder anders: Hinterfrage immer kritisch, worauf sich eine Aussage bezieht.

Ciao,
 Martin

[Linuchs]

Hallo Martin,

du willst es nicht verstehen, oder? *seufz*

Ich möchte es verstehen aufgrund einer "korrekten" Beschreibung. Oder dazu beitragen, Syntax-Angaben ein-deutig zu formulieren. Zum Stichwort CSS/Selektorenbei SelfHTML lese ich:

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement `eines` Elementes auszuwählen.

Ja, so habe ich es verstanden und so ist es falsch. Es wird das erste Kindelement vieler Elemente ausgewählt. Nicht das Erste sondern die Ersten - ist für mich ein Unterschied.

Okay, in der deutschen Sprache ist eines sehr nebulös. Wenn es um Genauigkeit geht, sollte man genau eines, ein bestimmtes, ein beliebiges oder wie hier - beliebig viele Elemente formulieren. Und beliebig viele oder einige (die Mehrzahl von eins) sind auch in der Umgangssprache nicht eins.

Ich bekomme auch immer (liebevoll) eins (manchmal beliebig viele) auf die Birne, wenn ich mich in Helptexten unklar ausdrücke.

Linuchs

[Der Martin]

Hallo,

du willst es nicht verstehen, oder? *seufz*

Ich möchte es verstehen aufgrund einer "korrekten" Beschreibung. Oder dazu beitragen, Syntax-Angaben ein-deutig zu formulieren. Zum Stichwort CSS/Selektorenbei SelfHTML lese ich:

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement `eines` Elementes auszuwählen.

ja, das war in der Tat mehrdeutig. Jetzt besser?

Ja, so habe ich es verstanden und so ist es falsch. Es wird das erste Kindelement vieler Elemente ausgewählt. Nicht das Erste sondern die Ersten - ist für mich ein Unterschied.

Ja. Das erste Kindelement in jedem Knoten.

Okay, in der deutschen Sprache ist eines sehr nebulös. Wenn es um Genauigkeit geht, sollte man genau eines, ein bestimmtes, ein beliebiges oder wie hier - beliebig viele Elemente formulieren. Und beliebig viele sind auch in der Umgangssprache nicht eins.

Aber das ist ein Problem der deutschen Sprache, dass der unbestimmte Artikel ein und das Zahlwort ein identisch sind. Im Englischen wäre es "the first child of an element", was etwas anderes ist als "the first child of one element".

Ich bekomme auch immer (liebevoll) eins (manchmal beliebig viele) auf die Birne, wenn ich mich in Helptexten unklar ausdrücke.

Mir wird das auch gelegentlich bewusst, wenn ich mich mit meinem Onkel unterhalte. Der hält unter anderem auch Vorlesungen in Technische Dokumentation und hat mittlerweile einen geschärften Sinn für solche Merkwürdigkeiten - oder für Formulierungen, die allgemein üblich, aber falsch sind.

Ciao,
 Martin

[Linuchs]

ja, das war in der Tat mehrdeutig. Jetzt besser?

Ja. Ich lese

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement seines Elternelementes auszuwählen. 

und in der Folge wird beschrieben, dass in dem Beispiel zwei Kindelemente betroffen sind. Da würde ich eher formulieren

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement von (einem oder mehreren) Elternelementen auszuwählen. 

Ja. Das erste Kindelement in jedem Knoten.

Das Erste ist ja nur eins. Alle ersten Kindelemente aller Knoten - wäre das korrekt?

Linuchs

[Matthias Apsel]

Hallo Linuchs,

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement seines Elternelementes auszuwählen. 

und in der Folge wird beschrieben, dass in dem Beispiel zwei Kindelemente betroffen sind. Da würde ich eher formulieren

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement von (einem oder mehreren) Elternelementen auszuwählen. 

Nein. So wie der Selektor p jedes p-Element auswählt, wählt :first-child jedes Element, das erstes Kindelement ist.

<Nur_mal_schnell_so_hingeschrieben>
Mit keinem CSS-Selektor kannst du garantieren, dass (unter allen Umständen) nur genau ein Element ausgewählt wird. Es lässt sich immer ein HTML-Dokument bauen, dass mehrere Elemente selektiert werden.
</Nur_mal_schnell_so_hingeschrieben>

Bis demnächst
Matthias

[Linuchs]

Nein. So wie der Selektor p jedes p-Element auswählt, wählt :first-child jedes Element, das erstes Kindelement ist.

Guter Vergleich, sogar für mich verständlich ;-)

Wir schreiben aber etwas aneiander vorbei, weil ich :nth-of-type() auf dem Schirm habe. Wahrscheinlich, weil es :third-child usw. nicht gibt.

Und tatsächlich habe ich noch Webseiten im Bestand mit sowas wie td:first-child+td+td+td+td

Und - ja, das habe ich jetzt kapiert - td:nth-of-type(3) ist nicht der Dritte sondern die Dritten. So unterschiedlich wie der dritte Zahn und die dritten Zähne.

Linuchs

[Der Martin]

Hallo,

Nein. So wie der Selektor p jedes p-Element auswählt, wählt :first-child jedes Element, das erstes Kindelement ist.

Guter Vergleich, sogar für mich verständlich ;-)

na also, wir finden doch noch zueinander.

Wir schreiben aber etwas aneiander vorbei, weil ich :nth-of-type() auf dem Schirm habe. Wahrscheinlich, weil es :third-child usw. nicht gibt.

Aus nachvollziehbaren Gründen, finde ich. Man bräuchte sehr viele CSS-Keywords für die vielen möglichen Pseudoklassen.

Aber beachte, dass :first-child zwar dasselbe ist wie :nth-child(1), aber etwas anderes als :first-of-type oder :nth-of-type(1):

• td:first-child selektiert ein td-Element, wenn es das erste Kind seines Parent ist
• td:first-of-type(1) selektiert das erste td-Element innerhalb seines Parent, auch wenn es davor noch Kindelemente eines anderen Typs gibt.

Und - ja, das habe ich jetzt kapiert - td:nth-of-type(3) ist nicht der Dritte sondern die Dritten. So unterschiedlich wie der dritte Zahn und die dritten Zähne.

Genau. Mit den Dritten kaut man besser. Ach nee, der Spruch ging noch irgendwie anders.

So long,
 Martin

[Matthias Apsel]

Hallo Der Martin,

Aber beachte, dass :first-child zwar dasselbe ist wie :nth-child(1), aber etwas anderes als :first-of-type oder :nth-of-type(1):

• td:first-child selektiert ein td-Element, wenn es das erste Kind seines Parent ist
• td:first-of-type(1) selektiert das erste td-Element innerhalb seines Parent, auch wenn es davor noch Kindelemente eines anderen Typs gibt.

Ja vergleichbar mit erstes Kind vs. erster Tochter.

Bis demnächst
Matthias

[Der Martin]

Hallo,

• td:first-child selektiert ein td-Element, wenn es das erste Kind seines Parent ist
• td:first-of-type(1) selektiert das erste td-Element innerhalb seines Parent, auch wenn es davor noch Kindelemente eines anderen Typs gibt.

Ja vergleichbar mit erstes Kind vs. erster Tochter.

sehr schöner Vergleich! Der ist mir nicht eingefallen. Lässt sich natürlich noch variieren: Erstes Kind vs. erstes blauäugiges Kind; erstes Kind vs. erstes von einem bestimmten Vater ... ;-)

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

• td:first-of-type(1) selektiert das erste td-Element

Bist du sicher? ;-)

erstes Kind vs. erstes von einem bestimmten Vater ... ;-)

Da fiel mir sofort ein Film mit Pierre Richard (der große Blonde) ein, in dem sein bester Freund und dessen Frau (beide dunkelhaarig) einen blonden Lockenkopf als Kind hatten.

LLAP 🖖

[Linuchs]

Mit den Dritten kaut man besser.

Genau. Ein gescheiterter Werbe-Slogan der Zahntechniker-Branche, die mit den Zweiten nichts verdienen konnte. Denn die Kunden, die freiwillig wechseln wollten, blieben aus.

Nun werben sie damit, sich an Problemen "die Zähne auszubeissen", das fruchtet. Denn jeder - so auch ich - fragt immer mal wieder irgendwo an: "Ich hätte da gerne mal ein Problem" ...

Darauf hatten ja auch die Friseure spekuliert und empfahlen, die "Haare zu raufen". Doch auch das ein Fehlschlag, denn "geraufte Haare" ist kein verlässliches Geschäftsmodell.

Doch auch für Friseure kam die Rettung: Das Eifon. Beim Runterblicken fielen immer die Haare vor die Augen. Und nun ...

[Bilder aus rechtlichen Gründen entfernt, Anm. der Red.]

Linuchs

[Christian Kruse]

Hallo Linuchs,

ist die Einbindung der Bilder hier legal? Hast du die Verwertungsrechte dafür? Ansonsten sollten wir sie löschen.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

ist die Einbindung der Bilder hier legal? Hast du die Verwertungsrechte dafür? Ansonsten sollten wir sie löschen.

Ich denke, sie sind höchstens CC-BY o.ä., sodass mindestens die Quelle fehlt. Also löschen.

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Hallo Christian Kruse,

ist die Einbindung der Bilder hier legal? Hast du die Verwertungsrechte dafür? Ansonsten sollten wir sie löschen.

Ich denke, sie sind höchstens CC-BY o.ä., sodass mindestens die Quelle fehlt. Also löschen.

Zumindest von der ersten Nase könnte man die ja rechtlich korrekt einbauen. Bin aber jedesmal froh, wenn ich eine Webseite aufrufe, auf der Sascha Lobo nicht zu sehen ist - auch wenn ich mir jedesmal sage: "Beruhig dich, solche Menschen muss es schließlich auch geben..." ;-)

Marc

[marctrix]

Hej Der Martin,

Wir schreiben aber etwas aneiander vorbei, weil ich :nth-of-type() auf dem Schirm habe. Wahrscheinlich, weil es :third-child usw. nicht gibt.

Aus nachvollziehbaren Gründen, finde ich. Man bräuchte sehr viele CSS-Keywords für die vielen möglichen Pseudoklassen.

:first-child und :last-child sind ja nur Kurzformen für die meistgenutzten :nth-child() und :nth-last-child() ...

Mit den Dritten kaut man besser. Ach nee, der Spruch ging noch irgendwie anders.

Mit den Dritten sieht man besser?

Marc

[Der Martin]

Hallo,

Mit den Dritten kaut man besser. Ach nee, der Spruch ging noch irgendwie anders.

Mit den Dritten sieht man besser?

... aus?

*scnr*
 Martin

[Auge]

Hallo

Nein. So wie der Selektor p jedes p-Element auswählt, wählt :first-child jedes Element, das erstes Kindelement ist.

Eben.

<Nur_mal_schnell_so_hingeschrieben>
Mit keinem CSS-Selektor kannst du garantieren, dass (unter allen Umständen) nur genau ein Element ausgewählt wird. Es lässt sich immer ein HTML-Dokument bauen, dass mehrere Elemente selektiert werden.
</Nur_mal_schnell_so_hingeschrieben>

Öhhm, #identifikator existiert für den Bedarfsfall. Aber mittlerweile ist das wegen der ganzen CSS3-Möglichkeiten wohl out. Da wird lieber abgezählt und bei Veränderungen im DOM erneut gezählt und der Quelltext angepasst, als die zuverlässig funktionierenden, abgehangenen Möglichkeiten zu nutzen.

Tschö, Auge

[Der Martin]

Hallo,

<Nur_mal_schnell_so_hingeschrieben>
Mit keinem CSS-Selektor kannst du garantieren, dass (unter allen Umständen) nur genau ein Element ausgewählt wird. Es lässt sich immer ein HTML-Dokument bauen, dass mehrere Elemente selektiert werden.
</Nur_mal_schnell_so_hingeschrieben>

Öhhm, #identifikator existiert für den Bedarfsfall.

ja, aber "unter allen Umständen" schließt IMO auch fehlerhafte HTML-Dokumente als Basis ein. Und real existierende Browser selektieren meines Wissens mit einem ID-Selektor auch mehrere Elemente mit derselben ID.

Ciao,
 Martin

[Matthias Apsel]

Hallo Der Martin,

ja, aber "unter allen Umständen" schließt IMO auch fehlerhafte HTML-Dokumente als Basis ein. Und real existierende Browser selektieren meines Wissens mit einem ID-Selektor auch mehrere Elemente mit derselben ID.

Ja, das waren auch meine Gedanken, als ich „unter allen Umständen“ schrieb.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Der Martin

Mit keinem CSS-Selektor kannst du garantieren, dass (unter allen Umständen) nur genau ein Element ausgewählt wird. Es lässt sich immer ein HTML-Dokument bauen, dass mehrere Elemente selektiert werden.

ja, aber "unter allen Umständen" schließt IMO auch fehlerhafte HTML-Dokumente als Basis ein.

Die wären aber schon äußerst fehlerhaft, wenn durch html, :root, head, body mehrere Elemente selektiert werden.

LLAP 🖖

[Auge]

Hallo

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement `eines` Elementes auszuwählen.

ja, das war in der Tat mehrdeutig. Jetzt besser?

Meiner Meinung nach ja.

Ja, so habe ich es verstanden und so ist es falsch. Es wird das erste Kindelement vieler Elemente ausgewählt. Nicht das Erste sondern die Ersten - ist für mich ein Unterschied.

Ja. Das erste Kindelement in jedem Knoten.

Wenn wir schon dabei sind: „Das erste Kindelements jedes Knotens“. ;-) und *scnr*

Aber das ist ein Problem der deutschen Sprache, dass der unbestimmte Artikel ein und das Zahlwort ein identisch sind.

Für mich war der beanstandete Satz aus dem Zusammenhang heraus eindeutig. Offensichtlich war er das nicht für jeden. Durch die Änderung von „eines Elements“ zu „seines Elternelements“ sollte sich die offensichtlich doch vorhandene Mehrdeutigkeit erledigt haben.

Tschö, Auge

[marctrix]

Hej Der Martin,

du willst es nicht verstehen, oder? *seufz*

Ich möchte es verstehen aufgrund einer "korrekten" Beschreibung. Oder dazu beitragen, Syntax-Angaben ein-deutig zu formulieren. Zum Stichwort CSS/Selektorenbei SelfHTML lese ich:

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement `eines` Elementes auszuwählen.

ja, das war in der Tat mehrdeutig. Jetzt besser?

Meiner Meinung nach nicht. Oft werden Bedeutungen nur aus dem Zusammenhang klar. Das betrifft die Teekesselchen-Worte ebenso wie Janusworte u. a. m.

Dein Bemühen, dem Text mehr Eindeutigkeit zu geben, hat IMHO zu einer schlechteren Verständlichkeit geführt.

Ich will da jetzt nicht ohne Rücksprache mit Dir auch noch drin herumfuhrwerken, daher mein Vorschlag, etwas mehr zu erklären:

Der Selektor :first-child wählt das erste Kindelement aus. Dieser Selektor bezieht sich also immer auf ein Elternelement. Wenn Sie in Ihrem CSS lediglich `:first-child { background: red; }` notieren, werden sehr viele Elemente einen roten Hintergrund bekommen: Das erste Element in html (body), Das erste Element in body (oft 'header' oder eine Überschrift), das erste Element im Footer, im Menü usw).

Daher lässt sich :first-child sinnvoll nur in einem Kombinator verwenden, z. B. nav li:first-child wählt jeden ersten Listeneintrag in der Hauptnavigation aus - das sind bei verschachtelten Listen selbstverständlich mehrere - eben in jeder Liste der erste Eintrag.

Ja, so habe ich es verstanden und so ist es falsch. Es wird das erste Kindelement vieler Elemente ausgewählt. Nicht das Erste sondern die Ersten - ist für mich ein Unterschied.

Ja. Das erste Kindelement in jedem Knoten.

Logisch!

Okay, in der deutschen Sprache ist eines sehr nebulös. Wenn es um Genauigkeit geht, sollte man genau eines, ein bestimmtes, ein beliebiges oder wie hier - beliebig viele Elemente formulieren. Und beliebig viele sind auch in der Umgangssprache nicht eins.

Aber das ist ein Problem der deutschen Sprache, dass der unbestimmte Artikel ein und das Zahlwort ein identisch sind. Im Englischen wäre es "the first child of an element", was etwas anderes ist als "the first child of one element".

Das macht doch gar keinen Sinn - es ist doch das Kind eines jeden (engl. each) gemeint. Natürlich kann man das im Deutsche auch eindeutig ausdrücken. Ansonsten richtet es der Kontext.

Mir wird das auch gelegentlich bewusst, wenn ich mich mit meinem Onkel unterhalte. Der hält unter anderem auch Vorlesungen in Technische Dokumentation und hat mittlerweile einen geschärften Sinn für solche Merkwürdigkeiten - oder für Formulierungen, die allgemein üblich, aber falsch sind.

Hauptsache sie sind allgemein verständlich! ;-)

Aber klar, es ist oft eine Herausforderung, die richtigen Worte zu wählen, weil man selber weiß ja, was man meint. Kontext darf eben nicht nur im Kopf des Autors stattfinden. Er muss auch auf das Papier / den Bildschirm ;-)

Marc

[Der Martin]

Hallo Marc,

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement `eines` Elementes auszuwählen.

ja, das war in der Tat mehrdeutig. Jetzt besser?

Meiner Meinung nach nicht. Oft werden Bedeutungen nur aus dem Zusammenhang klar. Das betrifft die Teekesselchen-Worte ebenso wie Janusworte u. a. m.

das schon, aber ebenso oft gibt es auch Raum für Missverständnisse. Mir war die Bedeutung von :first-child und Co. klar, deswegen hätte ich mich an der ursprünglichen Formulierung auch nicht gestört. Offenbar sah Linuchs das anders, und deswegen hab ich auf die Schnelle versucht, den Satz eindeutiger zu machen.

Dein Bemühen, dem Text mehr Eindeutigkeit zu geben, hat IMHO zu einer schlechteren Verständlichkeit geführt.

Finde ich nicht, denn was jetzt dort steht, ist nicht das, was ich geschrieben hatte. Meine Formulierung war: "das erste Kindelement seines Elternelementes auszuwählen."
Das hat aber (siehe Versionsgeschichte) später am Tag wohl nochmal jemand geändert, und jetzt steht da "erste Kindelemente auszuwählen". Das finde ich in der Tat auch schlechter als die ursprüngliche Version.

Ich will da jetzt nicht ohne Rücksprache mit Dir auch noch drin herumfuhrwerken, daher mein Vorschlag, etwas mehr zu erklären:

Mehr Klarheit durch Ausführlichkeit? Kann man natürlich auch machen.

Ja. Das erste Kindelement in jedem Knoten.

Logisch!

Ja, fand ich auch.

Aber das ist ein Problem der deutschen Sprache, dass der unbestimmte Artikel ein und das Zahlwort ein identisch sind. Im Englischen wäre es "the first child of an element", was etwas anderes ist als "the first child of one element".

Das macht doch gar keinen Sinn - es ist doch das Kind eines jeden (engl. each) gemeint.

Eben, und nicht das Kind genau eines (engl. one).

Mir wird das auch gelegentlich bewusst, wenn ich mich mit meinem Onkel unterhalte. Der hält unter anderem auch Vorlesungen in Technische Dokumentation und hat mittlerweile einen geschärften Sinn für solche Merkwürdigkeiten - oder für Formulierungen, die allgemein üblich, aber falsch sind.

Hauptsache sie sind allgemein verständlich! ;-)

Im Alltag ja. In einer einschlägigen Vorlesung darf und muss man pingeliger sein. Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Aber klar, es ist oft eine Herausforderung, die richtigen Worte zu wählen, weil man selber weiß ja, was man meint. Kontext darf eben nicht nur im Kopf des Autors stattfinden. Er muss auch auf das Papier / den Bildschirm ;-)

Und das ist nicht immer einfach. Vor allem muss man sich dessen immer bewusst sein.

So long,
 Martin

[Auge]

Hallo

So wird das nix!

[Vorlesung] Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Und warum müssen die sich einen Preis teilen? Sollte es nicht für jeden der Besten jeweils einen Preis geben? *scnr*

Tschö, Auge

[Der Martin]

Moin,

[Vorlesung] Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Und warum müssen die sich einen Preis teilen? Sollte es nicht für jeden der Besten jeweils einen Preis geben? *scnr*

der Teilnehmer erhält für seine Aufmerksamkeit ein Lob!
Test bestanden. ;-)

Ciao,
 Martin

[marctrix]

Hej Auge,

Und warum müssen die sich einen Preis teilen? Sollte es nicht für jeden der Besten jeweils einen Preis geben?

Und so wird aus einer möglichst einfach verständlichen Erklärung ein möglichst korrekter Text...

Habt Ihr Euch schon mal mit einfacher Sprache beschäftigt?

Marc

[Der Martin]

Hallo,

Habt Ihr Euch schon mal mit einfacher Sprache beschäftigt?

ja, sowohl deutsch als auch englisch. Ein guter Ansatz für Leute, die eine Sprache erstmal lernen, oder die generell Schwierigkeiten mit der Sprache haben. Aber IMO nichts für den Alltag. Da bleibt die Eleganz, die eine Sprache eigentlich hat (haben kann), völlig auf der Strecke.

Und für Menschen mit normal ausgeprägten Sprachfertigkeiten ist "einfache Sprache" eher schwieriger zu verstehen, weil durch die ausgeprägt einfachen, kurzen Sätze Zusammenhänge schwerer zu erkennen sind. Das ist jedenfalls mein Eindruck.

So long,
 Martin

[marctrix]

Hej Der Martin,

Habt Ihr Euch schon mal mit einfacher Sprache beschäftigt?

ja, [...] Aber IMO nichts für den Alltag. Da bleibt die Eleganz, die eine Sprache eigentlich hat (haben kann), völlig auf der Strecke.

Richtig.

Und für Menschen mit normal ausgeprägten Sprachfertigkeiten ist "einfache Sprache" eher schwieriger zu verstehen, weil durch die ausgeprägt einfachen, kurzen Sätze Zusammenhänge schwerer zu erkennen sind. Das ist jedenfalls mein Eindruck.

Kommt darauf an, wie die Texte vorher waren. Ich habe mal intensiv ein Projekt verfolgt, bei dem allerhand behördliche Anträge in einfache Sprache gebracht wurden. Das war nciht nur ein Gewinn in Bezug auf die Verständlichkeit, sondern auch sprachlich. Von Eleganz war in den Anträgen schon vorher nciht viel zu sehn. Der Staub klebte fast sichtbar zwischen den Zeilen.

Es wäre auch zu viel verlangt, wenn man neben Eindeutigkeit (was bei den Formularen wichtig war) und guter Verständlichkeit auch noch Eleganz fordern würde ;-)

Aber um auf Dokus zurück zu kommen. Ich persönlich mag englische Fachbücher, in denen auch eher mal geplaudert wird und finde die sehr gut verständlich. In deutschen (auch meinen) fehlt dieses Element. - Wenn ich schon mal ins erzählen verfalle, wird das vom Lektorat gestrichen. ;-)

Marc

[Der Martin]

Hi,

Und für Menschen mit normal ausgeprägten Sprachfertigkeiten ist "einfache Sprache" eher schwieriger zu verstehen, weil durch die ausgeprägt einfachen, kurzen Sätze Zusammenhänge schwerer zu erkennen sind. Das ist jedenfalls mein Eindruck.

Kommt darauf an, wie die Texte vorher waren. Ich habe mal intensiv ein Projekt verfolgt, bei dem allerhand behördliche Anträge in einfache Sprache gebracht wurden.

das ist natürlich ein Sonderfall. Die sind ja dann auch normalerweise nicht in Deutsch abgefasst, sondern in Bürokratisch.

Das war nciht nur ein Gewinn in Bezug auf die Verständlichkeit, sondern auch sprachlich. Von Eleganz war in den Anträgen schon vorher nciht viel zu sehn. Der Staub klebte fast sichtbar zwischen den Zeilen.

Das ist in dem Fall klar.

Aber um auf Dokus zurück zu kommen. Ich persönlich mag englische Fachbücher, in denen auch eher mal geplaudert wird und finde die sehr gut verständlich. In deutschen (auch meinen) fehlt dieses Element.

ACK.

Ciao,
 Martin

[marctrix]

Hej Der Martin,

Kommt darauf an, wie die Texte vorher waren. Ich habe mal intensiv ein Projekt verfolgt, bei dem allerhand behördliche Anträge in einfache Sprache gebracht wurden.

das ist natürlich ein Sonderfall.

Jeder Text ist ein Sonderfall. Aber hier war das Optimierungspotential schon überdurchschnittlich ;-)

Die sind ja dann auch normalerweise nicht in Deutsch abgefasst, sondern in Bürokratisch.

Sehr schön das!

Marc

[Gunnar Bittersmann]

@@marctrix

Aber um auf Dokus zurück zu kommen. Ich persönlich mag englische Fachbücher, in denen auch eher mal geplaudert wird und finde die sehr gut verständlich. In deutschen (auch meinen) fehlt dieses Element. - Wenn ich schon mal ins erzählen verfalle, wird das vom Lektorat gestrichen. ;-)

Ich gehör ja eher zur sprechenden als zur schreibenden Zunft – bei einer Live-Performance gibt’s kein Lektorat (was Vor- und Nachteile hat. ;-)).

Die ersten paar Minuten meines Vortrags beginne ich üblicherweise mit Plauderei – die auch nicht unbedingt was mit dem Thema zu tun hat. Einfach nur zum Spaß, z.B. Späße über mich selbst (Vortrag im Vorjahr verkackt) oder über die polnische Sprache. Guckst du selbst. :-)

LLAP 🖖

[Der Martin]

Hallo Gunnar,

[...] oder über die polnische Sprache. Guckst du selbst. :-)

mir ist schon öfter aufgefallen, dass du anscheinend recht vertraut mit der polnischen Sprache bist, obwohl ich dachte, du wärst ein waschechter Berliner. Bist du in einer vorwiegend polnischsprachigen Region aufgewachsen oder wie kommt das?

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

ich dachte, du wärst ein waschechter Berliner.

Bin ick ooch.

Bist du in einer vorwiegend polnischsprachigen Region aufgewachsen

Nö, in Rand-Berlin, vorwiegend berlinerischsprachig. ;-)

oder wie kommt das?

Ich war 4 Jahre zum Studium in Warschau. Da ist was hängengeblieben – zumindest von der Sprache. ;-)

LLAP 🖖

[Der Martin]

Hallo,

ich dachte, du wärst ein waschechter Berliner.

Bin ick ooch.

na denn is ja allet jut.
Nein, ich werde mir nicht die Blöße geben, "live" Berliner Mundart zu imitieren. Wer Dialekte nachmacht, macht sich damit meistens lächerlich; es gibt nur wenige, die es wirklich können.

Ich war 4 Jahre zum Studium in Warschau. Da ist was hängengeblieben – zumindest von der Sprache. ;-)

Das hört sich überzeugend an! Und ich habe im Lauf der Zeit von verschiedenen Personen gehört, Polnisch sei eine sehr schwierige Sprache. Vor allem deshalb, weil es zu der eh schon komplzierten Grammatik noch mehr Ausnahmen als Regeln gibt.

Ciao,
 Martin

[marctrix]

Hej Gunnar,

Die ersten paar Minuten meines Vortrags beginne ich üblicherweise mit Plauderei

Hmmm - wir haben viel gemeinsam...

Übrigens mal wieder ein gelungenes Stück Lehrkunst!

Marc

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Plauderei – die auch nicht unbedingt was mit dem Thema zu tun hat.

Über Schriftarten (26:47)

Und über den Weltfrieden. (29:06)

LLAP 🖖

[Gunnar Bittersmann]

@@Der Martin

In einer einschlägigen Vorlesung darf und muss man pingeliger sein. Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Ich mag deinen Onkel. ;-)

LLAP 🖖

[Der Martin]

Hallo,

In einer einschlägigen Vorlesung darf und muss man pingeliger sein. Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Ich mag deinen Onkel. ;-)

kannst du doch anhand nur einer Eigenschaft noch gar nicht beurteilen.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin

kannst du doch anhand nur einer Eigenschaft noch gar nicht beurteilen.

Was ich beurteilen kann: Angesichts der Technik da auf dem Tisch hoffe ich für deinen Onkel, dass das kein aktuelles Foto ist. ;-)

LLAP 🖖

[Der Martin]

Hallo Gunnar,

kannst du doch anhand nur einer Eigenschaft noch gar nicht beurteilen.

Was ich beurteilen kann: Angesichts der Technik da auf dem Tisch hoffe ich für deinen Onkel, dass das kein aktuelles Foto ist. ;-)

nein, ist es auch nicht. Das Foto dürfte so um die 10 Jahre alt sein. Er wirkte allerdings immer schon jünger, als er tatsächlich ist. Hermann ist gerade mal 10 Jahre älter als ich selbst, aber wir sind uns in manchen Dingen (persönliche Macken, Gewohnheiten, Vorlieben) so ähnlich, dass wir von Freunden und Verwandten gern als Zwillinge bezeichnet werden. Wir haben sogar eine sehr ähnliche Handschrift.

Aber derart "altes Gerümpel" hatten sie immer noch an manchen Plätzen, als ich im vergangenen Sommer mal wieder zu Besuch war. Vielleicht nicht so sehr in den Büros, aber an einigen Labor-Arbeitsplätzen.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Aber derart "altes Gerümpel" …

Ein 4:3-Monitor kommt mir quadratisch vor – wie sich Sehgewohnheiten ändern.

Ein Röhrenmonitor aber nicht kubisch – der geht weit mehr in die Tiefe als in Breite und Höhe. ;-)

LLAP 🖖

[Der Martin]

Hallo,

Aber derart "altes Gerümpel" …

Ein 4:3-Monitor kommt mir quadratisch vor – wie sich Sehgewohnheiten ändern.

ich kann mich an Widescreen-Formate immer noch nicht wirklich gewöhnen. Ich habe mich damit abgefunden, dass sie mittlerweile üblich sind, aber gefallen muss mir das nicht. Ich hoffe, dass mein guter 4:3-Monitor mit 1600x1200 mir noch lange zu Diensten sein wird. Gerade am PC ist mir eine hohe vertikale Auflösung wichtiger als die Horizontale.

Ein Röhrenmonitor aber nicht kubisch – der geht weit mehr in die Tiefe als in Breite und Höhe. ;-)

Das zeichnet(e) eigentlich gute CRT-Monitore aus. Je länger die Röhre im Verhältnis zur Diagonale ist, desto weniger Verzerrungen treten an den Rändern auf, und desto flacher kann die Front sein.

Ich finde übrigens, dass man die Tiefe auf diesem Foto sehr schlecht einschätzen kann.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Gerade am PC ist mir eine hohe vertikale Auflösung wichtiger als die Horizontale.

Deshalb drehe ich Monitore üblicherweise ins Hochformat.

LLAP 🖖

[Der Martin]

Hi,

Gerade am PC ist mir eine hohe vertikale Auflösung wichtiger als die Horizontale.

Deshalb drehe ich Monitore üblicherweise ins Hochformat.

wollte ich eigentlich auch. Meine Wunsch-Konfiguration war der "große" 20-Zöller im Hochformat (also 1600px vertikal), und der kleinere mit 1280x1024 daneben in normaler Orientierung (der hätte auch kein Drehgelenk).

Problem: Der X-Server (vermutlich) hat immense Probleme damit, zwei Monitore in unterschiedlicher Orientierung anzusprechen. Anscheinend wird bei jeder Änderung am Bildschirm wieder das gesamte Bild um 90° gedreht neu berechnet. Das führte dazu, dass man mit dem Rechner nicht vernünftig arbeiten konnte, weil jedes Scrollen, jedes Öffnen, Schließen oder Verschieben eines Fensters eine halbe bis eine Sekunde gebraucht hat.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Problem: Der X-Server (vermutlich) hat immense Probleme damit, zwei Monitore in unterschiedlicher Orientierung

Hach, immer wieder die Leute mit ihren minderwertigen Betriebssystemen! 😈

LLAP 🖖

[Christian Kruse]

Hallo Martin,

Problem: Der X-Server (vermutlich) hat immense Probleme damit, zwei Monitore in unterschiedlicher Orientierung anzusprechen.

Nö? Das klappt hier ohne Probleme.

Anscheinend wird bei jeder Änderung am Bildschirm wieder das gesamte Bild um 90° gedreht neu berechnet. Das führte dazu, dass man mit dem Rechner nicht vernünftig arbeiten konnte, weil jedes Scrollen, jedes Öffnen, Schließen oder Verschieben eines Fensters eine halbe bis eine Sekunde gebraucht hat.

Das hört sich eher nach einem Treiber-Problem an.

LG,
CK

[Der Martin]

Hallo,

Problem: Der X-Server (vermutlich) hat immense Probleme damit, zwei Monitore in unterschiedlicher Orientierung anzusprechen.

Nö? Das klappt hier ohne Probleme.

vielleicht auch eine Frage der richtigen Konfiguration? Ich wüsste aber nicht, wo ich da ansetzen sollte.

Anscheinend wird bei jeder Änderung am Bildschirm wieder das gesamte Bild um 90° gedreht neu berechnet. Das führte dazu, dass man mit dem Rechner nicht vernünftig arbeiten konnte, weil jedes Scrollen, jedes Öffnen, Schließen oder Verschieben eines Fensters eine halbe bis eine Sekunde gebraucht hat.

Das hört sich eher nach einem Treiber-Problem an.

Will ich nicht ausschließen, erscheint mir aber eher unwahrscheinlich, weil der Effekt sowohl mit dem OpenSource-Treiber auftrat, als auch mit dem proprietären von AMD. Aber an Einzelheiten kann ich mich auch nicht mehr erinnern; immerhin ist das lange her. Ich weiß gar nicht mehr, ob das noch mit einem "echten" Ubuntu war, oder ob ich da schon auf Mint umgestiegen war (das wäre 2012 gewesen).

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

vielleicht auch eine Frage der richtigen Konfiguration? Ich wüsste aber nicht, wo ich da ansetzen sollte.

Das ist eigentlich nichts, was konfiguriert werden müsste, das ist eine Sache, die man mit der XRandr-Schnittstelle einstellt; entweder via Desktop (iirc bietet Mint dafür ein Konfiguration-Utility an) oder via CLI:

xrandr --output DVI-1 --rotate left
xrandr --output DVI-1 --rotate normal

Das hört sich eher nach einem Treiber-Problem an.

Will ich nicht ausschließen, erscheint mir aber eher unwahrscheinlich, weil der Effekt sowohl mit dem OpenSource-Treiber auftrat, als auch mit dem proprietären von AMD.

Das heisst ja nichts. Die Treiber von AMD sind eine Frechheit und die FLOSS-Treiber hinken leider immer etwas hinterher (weshalb ich mich auch weigere eine neue GraKa zu kaufen).

Ich weiß gar nicht mehr, ob das noch mit einem "echten" Ubuntu war, oder ob ich da schon auf Mint umgestiegen war (das wäre 2012 gewesen).

Naja, gedrehte Bildschirme gab es schon recht früh, mindestens seit '98, und ich weiss, dass Linux das bei meinem ersten Monitor, der nicht mehr 4:3 war, auch schon konnte... auch wenn das damals[tm] noch ein echtes Gefrickel in der X-Config war, mit irgendwelchen Matrizen, die man sich ausrechnen musste...

LG,
CK

[Der Martin]

Hi,

vielleicht auch eine Frage der richtigen Konfiguration? Ich wüsste aber nicht, wo ich da ansetzen sollte.

Das ist eigentlich nichts, was konfiguriert werden müsste

ich meine, ich hätte hier und da mal über framebuffer und double-buffering und ähnlich wüste Sachen gelesen, und dass man für bestimmte Funktionen bestimmte Einstellungen bräuchte. Und dann kommt noch dazu, dass Ubuntoide gar keine xorg.conf mehr benutzen, wo man überhaupt eingreifen könnte, sondern stattdessen eine Menge interner Magie ...
Krieg's aber aus dem Gedächtnis auch nicht mehr zusammen, ist schon 'ne Weile her. Verstanden hab ich es damals auch nicht wirklich.

das ist eine Sache, die man mit der XRandr-Schnittstelle einstellt; entweder via Desktop (iirc bietet Mint dafür ein Konfiguration-Utility an) oder via CLI:

xrandr --output DVI-1 --rotate left
xrandr --output DVI-1 --rotate normal

Ja, das ist mir geläufig, auch wenn ich es via GUI einstellen kann (bei Ubuntu seit mindestens 9.04 auch schon, das war meine Einstiegsversion).

Das hört sich eher nach einem Treiber-Problem an.

Will ich nicht ausschließen, erscheint mir aber eher unwahrscheinlich, weil der Effekt sowohl mit dem OpenSource-Treiber auftrat, als auch mit dem proprietären von AMD.

Das heisst ja nichts. Die Treiber von AMD sind eine Frechheit

Ja, nach dem letzten Update auf dem anderen Rechner war der AMD-Treiber derart kaputt, dass er gar nicht mehr funktionierte und das AMD-Konfigurationstool sich gar beschwerte, ich hätte keine dazu kompatible Hardware.

und die FLOSS-Treiber hinken leider immer etwas hinterher (weshalb ich mich auch weigere eine neue GraKa zu kaufen).

Das ist eigentlich einleuchtend, aber nicht weiter schlimm, finde ich.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

ich meine, ich hätte hier und da mal über framebuffer und double-buffering und ähnlich wüste Sachen gelesen, und dass man für bestimmte Funktionen bestimmte Einstellungen bräuchte.

Ohje, das klingt aber ziemlich merkwürdig. Framebuffer ist am Treiber vorbei, da verzichtest du auf viel Hardware-Beschleunigung, auch wenn der FB selber hardware-beschleunigt ist. Ich musste damals meinen WebBoy, ein Billig-Notebook von Gerricom, mein erstes Notebook, mit Framebuffer betreiben.

Und dann kommt noch dazu, dass Ubuntoide gar keine xorg.conf mehr benutzen, wo man überhaupt eingreifen könnte, sondern stattdessen eine Menge interner Magie ...

Nee, das ist nur „Convention Over Configuration“; du kannst weiterhin alles einstellen, wenn du das möchtest. Ausser Ubuntu selber, dass halt Mir statt Xorg oder Wayland benutzt. Aber das von dir verwendete Mint z.B. erwartet eine xorg.conf in /etc/X11/xorg.conf bzw einzelne Dateien in /etc/X11/xorg.conf.d/.

und die FLOSS-Treiber hinken leider immer etwas hinterher (weshalb ich mich auch weigere eine neue GraKa zu kaufen).

Das ist eigentlich einleuchtend, aber nicht weiter schlimm, finde ich.

Klar ist das einleuchtend ;-) Aber wenn ich eine neue GraKa kaufen will, die dann noch nicht unterstützt wird, ist das gelinde gesagt ärgerlich ;-)

Wobei das mit den GraKas eh immer noch schwierig ist, ich suche seit geraumer Zeit eine passiv gekühlte GraKa, die 2x 2560x1440 ansteuern kann. Das scheint es einfach nicht zu geben.

LG,
CK

[Der Martin]

Hallo,

ich meine, ich hätte hier und da mal über framebuffer und double-buffering und ähnlich wüste Sachen gelesen, und dass man für bestimmte Funktionen bestimmte Einstellungen bräuchte.

Ohje, das klingt aber ziemlich merkwürdig. Framebuffer ist am Treiber vorbei

ah, das ist mal eine klare Aussage. Ich dachte, es wäre quasi das Gegenteil: Eine zusätzliche Pufferung durch den Treiber, um bestimmte Manipulationen durchführen zu können.

da verzichtest du auf viel Hardware-Beschleunigung, auch wenn der FB selber hardware-beschleunigt ist. Ich musste damals meinen WebBoy, ein Billig-Notebook von Gerricom, mein erstes Notebook, mit Framebuffer betreiben.

Wie gesagt, ich kann mich nicht mehr erinnern, in welchem Zusammenhang das war.

Und dann kommt noch dazu, dass Ubuntoide gar keine xorg.conf mehr benutzen, wo man überhaupt eingreifen könnte, sondern stattdessen eine Menge interner Magie ...

Nee, das ist nur „Convention Over Configuration“; du kannst weiterhin alles einstellen, wenn du das möchtest. Ausser Ubuntu selber, dass halt Mir statt Xorg oder Wayland benutzt. Aber das von dir verwendete Mint z.B. erwartet eine xorg.conf in /etc/X11/xorg.conf bzw einzelne Dateien in /etc/X11/xorg.conf.d/.

Tatsächlich. Ich entsinne mich aber noch, dass Ubuntu (Lucid oder Maverick, AFAIR) an der Stelle gähnende Leere hatte und auch eine von Hand angelegte xorg.conf geflissentlich ignorierte.

Aber wenn ich eine neue GraKa kaufen will, die dann noch nicht unterstützt wird, ist das gelinde gesagt ärgerlich ;-)

Stimmt, so weit hatte ich nicht gedacht.

Wobei das mit den GraKas eh immer noch schwierig ist, ich suche seit geraumer Zeit eine passiv gekühlte GraKa, die 2x 2560x1440 ansteuern kann. Das scheint es einfach nicht zu geben.

Keine Ahnung; bin nicht auf dem Laufenden, was der Markt da so hergibt. Abgesehen davon habe ich schon seit Ewigkeiten keine separate Grafikkarte mehr gekauft, sondern mich mit den Onboard-Lösungen zufrieden gegeben.

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

ich meine, ich hätte hier und da mal über framebuffer und double-buffering und ähnlich wüste Sachen gelesen, und dass man für bestimmte Funktionen bestimmte Einstellungen bräuchte.

Ohje, das klingt aber ziemlich merkwürdig. Framebuffer ist am Treiber vorbei

ah, das ist mal eine klare Aussage. Ich dachte, es wäre quasi das Gegenteil: Eine zusätzliche Pufferung durch den Treiber, um bestimmte Manipulationen durchführen zu können.

Nein, dass ist der Video-Speicher, dort kann man das Bild, das am Monitor angezeigt wird, Pixel für Pixel reinschreiben, quasi als Bitmap.

Ich entsinne mich aber noch, dass Ubuntu (Lucid oder Maverick, AFAIR) an der Stelle gähnende Leere hatte und auch eine von Hand angelegte xorg.conf geflissentlich ignorierte.

Wie gesagt: Ubuntu verwendet Mir als Display Server, nicht Xorg oder Wayland. Da hilft dann keine xorg.conf ;-)

LG,
CK

[Der Martin]

Hi,

Framebuffer ist am Treiber vorbei

ah, das ist mal eine klare Aussage. Ich dachte, es wäre quasi das Gegenteil: Eine zusätzliche Pufferung durch den Treiber, um bestimmte Manipulationen durchführen zu können.

Nein, dass ist der Video-Speicher, dort kann man das Bild, das am Monitor angezeigt wird, Pixel für Pixel reinschreiben, quasi als Bitmap.

jaja, das ist mir technisch schon klar (hat man ja früher[tm] oft genug so gemacht). Ich hatte eben nur eine andere Vorstellung.

Ich entsinne mich aber noch, dass Ubuntu (Lucid oder Maverick, AFAIR) an der Stelle gähnende Leere hatte und auch eine von Hand angelegte xorg.conf geflissentlich ignorierte.

Wie gesagt: Ubuntu verwendet Mir als Display Server, nicht Xorg oder Wayland. Da hilft dann keine xorg.conf ;-)

Das mag heute so sein; die alten Ubuntus, die ich erwähnte, hatten aber noch den traditionellen Xorg. Aber vermutlich auch schon mit ein paar Ubuntu-spezifischen Anpassungen.

Ciao,
 Martin

[Orlok]

Hallo Christian

Framebuffer ist am Treiber vorbei, da verzichtest du auf viel Hardware-Beschleunigung, auch wenn der FB selber hardware-beschleunigt ist.

Was es nicht alles gibt. ;-)

Wenn ich das richtig verstanden habe, handelt es sich beim Linux Framebuffer um eine Schnittstelle, mit der direkt auf den phyischen Framebuffer zugegriffen werden kann, und zwar, wie du sagst, ohne Umweg über die Grafikkartentreiber.

In diesem Fall würde man wohl nicht nur auf viel, sondern auf so gut wie die gesamte Hardware-Beschleunigung verzichten, da man sich auf diese Weise erst kurz vor Schluss in die Grafikpipeline einklinkt. Denn danach wird ja im Prinzip nur noch der Framebuffer line-by-line gelesen und die Anzeige entsprechend aktualisiert.

Die wirklich rechenintensiven Operationen, wie die Transformation der Vertexdaten oder auch der Prozess der Rasterung selbst, finden jedoch allesamt vorher statt, von daher würde ich eine solche Lösung unbedingt vermeiden wollen, wenn es sich denn irgendwie vermeiden lässt …

Viele Grüße,

Orlok

[Der Martin]

Hallo,

Framebuffer ist am Treiber vorbei, da verzichtest du auf viel Hardware-Beschleunigung, auch wenn der FB selber hardware-beschleunigt ist.

Was es nicht alles gibt. ;-)

Wenn ich das richtig verstanden habe, handelt es sich beim Linux Framebuffer um eine Schnittstelle, mit der direkt auf den phyischen Framebuffer zugegriffen werden kann, und zwar, wie du sagst, ohne Umweg über die Grafikkartentreiber.

In diesem Fall würde man wohl nicht nur auf viel, sondern auf so gut wie die gesamte Hardware-Beschleunigung verzichten, da man sich auf diese Weise erst kurz vor Schluss in die Grafikpipeline einklinkt. Denn danach wird ja im Prinzip nur noch der Framebuffer line-by-line gelesen und die Anzeige entsprechend aktualisiert.

ja, das ist genau die Technik, die in den 90er Jahren unter sogenannten Betriebssystemen wie DOS und mit Grafikkarten, bei denen von Hardware-Beschleunigung noch niemand sprach, die beste Performance erzielt hat.

Heute dürfte das vermutlich nur noch für Nischenanwendungen sinnvoll sein, oder für Grafikkarten, für die man ums Verrecken keinen anständigen Treiber bekommt.

So long,
 Martin

[Christian Kruse]

Hallo Orlok,

Wenn ich das richtig verstanden habe, handelt es sich beim Linux Framebuffer um eine Schnittstelle, mit der direkt auf den phyischen Framebuffer zugegriffen werden kann, und zwar, wie du sagst, ohne Umweg über die Grafikkartentreiber.

Ja, das ist richtig.

In diesem Fall würde man wohl nicht nur auf viel, sondern auf so gut wie die gesamte Hardware-Beschleunigung verzichten, […]

Nein, es gibt Hardware-beschleunigten Framebuffer (Stichwort DirectFB). Aber das ist natürlich bei weitem nicht vergleichbar mit richtiger[tm] Hardware-Beschleunigung.

[…] von daher würde ich eine solche Lösung unbedingt vermeiden wollen, wenn es sich denn irgendwie vermeiden lässt …

Ja, auf jeden Fall. Nur damals[tm] hatte man nicht unbedingt immer eine Wahl. Heute ist das zum Glück anders.

LG,
CK

[marctrix]

Hej Gunnar,

Gerade am PC ist mir eine hohe vertikale Auflösung wichtiger als die Horizontale.

Deshalb drehe ich Monitore üblicherweise ins Hochformat.

Ich mag es Editor, Browser und Entwicklerwerkzeuge nebeneinander zu haben. Macht aber erst auf sehr breiten Monitoren Spaß...

Schön, dass es für jeden etwas gibt!

Marc

[Gunnar Bittersmann]

@@marctrix

Ich mag es Editor, Browser und Entwicklerwerkzeuge nebeneinander zu haben. Macht aber erst auf sehr breiten Monitoren Spaß...

Dafür hat man doch mehrere Monitore! ;-)

LLAP 🖖

[Der Martin]

Hallo,

Ich mag es Editor, Browser und Entwicklerwerkzeuge nebeneinander zu haben. Macht aber erst auf sehr breiten Monitoren Spaß...

Dafür hat man doch mehrere Monitore! ;-)

danke, die Antwort hatte ich mir verkniffen.

Abgesehen davon: Bei einem großen Monitor in Hochkant-Orientierung kann man diese Dinge teilweise auch in der Vertikalen stapeln. Lohnt sich aber erst bei wirklich hohen Auflösungen deutlich jenseits von Full HD, etwa 2560x1600. Das wäre so etwa mein Traum von einem Monitor.

Bezahlen möchte ich ihn aber nicht. ;-)

So long,
 Martin

PS: Mannomann, wenn ich mich daran erinnere, dass ich für meinen ersten TFT-Monitor mit 15" und 1024x768 fast 1800 Mark bezahlt habe ...

[Gunnar Bittersmann]

@@Der Martin

danke, die Antwort hatte ich mir verkniffen.

Irgendwer muss ja die Drecksarbeit machen. ;-)

PS: Mannomann, wenn ich mich daran erinnere, dass ich für meinen ersten TFT-Monitor mit 15" und 1024x768 fast 1800 Mark bezahlt habe ...

Was kam doch gleich mein erster DVD-Player?

LLAP 🖖

[Der Martin]

Hallo,

danke, die Antwort hatte ich mir verkniffen.

Irgendwer muss ja die Drecksarbeit machen. ;-)

*g*

PS: Mannomann, wenn ich mich daran erinnere, dass ich für meinen ersten TFT-Monitor mit 15" und 1024x768 fast 1800 Mark bezahlt habe ...

Was kam doch gleich mein erster DVD-Player?

Keine Ahnung, aber ich weiß noch, was mein erster gekostet hat: 199 EU$. Eigentlich wollte ich einen neuen CD-Player, weil meiner sich verabschiedet hatte, aber dann habe ich festgestellt, dass es kaum noch Standalone-CD-Player gab - und wenn, dann deutlich über 100 EU$, die guten eher in Richtung 200. Und dann dachte ich, komm, gib dir'n Ruck und leg noch'n Fuffi mehr drauf, dann haste gleich einen DVD-Player. Hab's nicht bereut.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Keine Ahnung, aber ich weiß noch, was mein erster gekostet hat: 199 EU$.

Bei mir waren’s noch so etwa 800 DM.

Das Gerät hatte innerhalb der Garantiezeit eine kleine Macke. Zur Reparatur geschafft, nach sechs Wochen immer noch nicht zurückbekommen, Geld zurückverlangt. Für die Hälfte des Geldes dann das Nachfolgemodell gekauft. :-)

Und dann dachte ich, komm, gib dir'n Ruck und leg noch'n Fuffi mehr drauf, dann haste gleich einen DVD-Player. Hab's nicht bereut.

Was nervt ist die lange Zeit, die ein DVD-Player gegenüber einem CD-Player braucht, bis er endlich anfängt, eine Scheibe abzuspielen. Als ob die Laser da drinnen erstmal eine Lasershow machen.

CD-Laser: „Ich will erstmal nachsehen, ob die eingelegte Scheibe eine CD ist.“
DVD-Laser: „Ist mir völlig Schnuppe, was du da siehst. Ich will selber nachsehen, ob es eine DVD ist.“
DVD-Laser für die 2. Schicht: „Dann will ich aber auch …“
Nutzer (schon leicht genervt): „Sagt mal, geht’s noch‽ Kommt ihr vielleicht mal zu Potte‽“

LLAP 🖖

[Der Martin]

Hallo,

Keine Ahnung, aber ich weiß noch, was mein erster gekostet hat: 199 EU$.

Bei mir waren’s noch so etwa 800 DM.

okay, dann warst du deutlich früher dran als ich - schon die Währung lässt das vermuten. ;-)

Das Gerät hatte innerhalb der Garantiezeit eine kleine Macke. Zur Reparatur geschafft, nach sechs Wochen immer noch nicht zurückbekommen, Geld zurückverlangt. Für die Hälfte des Geldes dann das Nachfolgemodell gekauft. :-)

Also letztendlich doch ein Schnäppchen!

Was nervt ist die lange Zeit, die ein DVD-Player gegenüber einem CD-Player braucht, bis er endlich anfängt, eine Scheibe abzuspielen. Als ob die Laser da drinnen erstmal eine Lasershow machen.

Ist das so? Es klingt irgendwie logisch, wenn man's mal von der technischen Seite betrachtet, aber es ist mir noch nie bewusst aufgefallen. Allerdings, wenn ich mal so darüber nachdenke, gibt es bei den DVD-Playern auch untereinander erhebliche Unterschiede, wie lange die brauchen. Da gibt es welche, die machen erstmal zehn Sekunden Kunstpause (obwohl mal deutlich hört, dass da im Gerät irgendwas abgeht), andere fangen nach zwei, drei Sekunden schon an, den Film oder die Musik zu spielen.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Abgesehen davon: Bei einem großen Monitor in Hochkant-Orientierung kann man diese Dinge teilweise auch in der Vertikalen stapeln. Lohnt sich aber erst bei wirklich hohen Auflösungen deutlich jenseits von Full HD, etwa 2560x1600. Das wäre so etwa mein Traum von einem Monitor.

Ich habe zwei gute 2560x1440-Monitore nebeneinander stehen, die den sRGB-Raum abdecken können. Kann ich nur empfehlen.

Bezahlen möchte ich ihn aber nicht. ;-)

Ich auch nicht, und hab ich auch nicht ;-) Arbeitsplatz-Ausstattung.

LG,
CK

[marctrix]

Hej Der Martin,

Dafür hat man doch mehrere Monitore! ;-)

danke, die Antwort hatte ich mir verkniffen.

Die brauchen aber zu viel Platz - und auf zwei Monitore kann ich die drei Dinge (Editor, Browser, Entwicklertools) nie vernünftig anordnen.

Abgesehen davon: Bei einem großen Monitor in Hochkant-Orientierung kann man diese Dinge teilweise auch in der Vertikalen stapeln.

Dann kommt noch eine VESA-HAlterung dazu - meiner lässt sich nciht drehen, ich habe aber die Horizontale lieber.

Bezahlen möchte ich ihn aber nicht. ;-)

PS: Mannomann, wenn ich mich daran erinnere, dass ich für meinen ersten TFT-Monitor mit 15" und 1024x768 fast 1800 Mark bezahlt habe ...

Da gibt es die doch heute deutlich günstiger - bin mit meinem LG sehr zufrieden!

Marc

[Christian Kruse]

Hallo marctrix,

Die brauchen aber zu viel Platz - und auf zwei Monitore kann ich die drei Dinge (Editor, Browser, Entwicklertools) nie vernünftig anordnen.

Ich bin mit dieser Anordnung ausgesprochen zufrieden: Linker Monitor mit 50:50 Entwickler-Tools und Browser, rechter Monitor mit 100% der Editor (der dann wieder eine Split View hat mit 1-n Files).

LG,
CK

[marctrix]

Hej Christian,

Hallo marctrix,

Die brauchen aber zu viel Platz - und auf zwei Monitore kann ich die drei Dinge (Editor, Browser, Entwicklertools) nie vernünftig anordnen.

Ich bin mit dieser Anordnung ausgesprochen zufrieden: Linker Monitor mit 50:50 Entwickler-Tools und Browser, rechter Monitor mit 100% der Editor (der dann wieder eine Split View hat mit 1-n Files).

So mache ich es auch, wenn ich an einen Arbeitsplatz mit zwei Monitoren muss - was immer noch besser ist, als ein Arbeitsplatz mit einem Monitor (deutlich) kleiner als FullHD - kommt ja auch immer mal wieder vor. Andererseits tut es auch mal Coda auf dem iPad für Kleinigkeiten, die sich schnell mal zwischendurch lösen lassen...

Marc

[marctrix]

Hej Gunnar,

@@marctrix

Ich mag es Editor, Browser und Entwicklerwerkzeuge nebeneinander zu haben. Macht aber erst auf sehr breiten Monitoren Spaß...

Dafür hat man doch mehrere Monitore! ;-)

Braucht zu viel Platz ;-)

Marc

[Christian Kruse]

Hallo Martin,

kannst du doch anhand nur einer Eigenschaft noch gar nicht beurteilen.

Oh, ich hatte (mindestens) eine Vorlesung bei Herrn Gebhard.

LG,
CK

[Der Martin]

Hi Christian,

kannst du doch anhand nur einer Eigenschaft noch gar nicht beurteilen.

Oh, ich hatte (mindestens) eine Vorlesung bei Herrn Gebhard.

und es hat dir vermutlich nicht nachhaltig geschadet. :-)

So long,
 Martin

[Christian Kruse]

Hallo Martin,

kannst du doch anhand nur einer Eigenschaft noch gar nicht beurteilen.

Oh, ich hatte (mindestens) eine Vorlesung bei Herrn Gebhard.

und es hat dir vermutlich nicht nachhaltig geschadet. :-)

Naja, ich habe seitdem so leichte Ticks… zuck 😉

LG,
CK

[Tabellenkalk]

Hallo,

Finde ich nicht, denn was jetzt dort steht, ist nicht das, was ich geschrieben hatte. Meine Formulierung war: "das erste Kindelement seines Elternelementes auszuwählen."
Das hat aber (siehe Versionsgeschichte) später am Tag wohl nochmal jemand geändert, und jetzt steht da "erste Kindelemente auszuwählen". Das finde ich in der Tat auch schlechter als die ursprüngliche Version.

Dieser Jemand war ich. Linuchs hatte sich daran gestört, dass aus der Formulierung nicht klar wurde, dass mehrere Elmente selektiert werden. Das wird m.E. durch "das erste Kindelement seines Elternelementes" noch weniger deutlich. Mit "erste Kindelemente" versuche ich darzustellen, dass eben der Selektor in seiner uneingeschränkten Form eben einen ganzen Haufen selektiert. Diesen Haufen muss/kann man bei Bedarf durch weitere Selektorenkombination einschränken.

Gruß
Kalk

[marctrix]

Hej Der Martin,

ja, das war in der Tat mehrdeutig. Jetzt besser?

Meiner Meinung nach nicht. Oft werden Bedeutungen nur aus dem Zusammenhang klar. Das betrifft die Teekesselchen-Worte ebenso wie Janusworte u. a. m.

das schon, aber ebenso oft gibt es auch Raum für Missverständnisse. Mir war die Bedeutung von :first-child und Co. klar, deswegen hätte ich mich an der ursprünglichen Formulierung auch nicht gestört. Offenbar sah Linuchs das anders, und deswegen hab ich auf die Schnelle versucht, den Satz eindeutiger zu machen.

Wir haben diese Diskussion in unterschiedlichsten Kontexten öfters, ich erinner nur an funktioniert nicht, wenn es nicht bedienbar ist ;-)

Es ist eigentlich klar, was damit gemeint ist, hatte aber in dem Thread, wo es gefallen ist, zu Verwirrung geführt.

Unter anderem vielleicht deshalb, weil es eine deutsche Übersetzung eines Zitates war, das nicht allen bekannt war (und der Zusammenhang, in dem es geäußert wurde).

Die grundsätzliche Frage, die man sich dann stellen muss: kann man etwas besser ausdrücken?

Und das heißt nicht eindeutiger oder weniger missverständlich. Das bedeutet meiner Meinung nach: kann ich zu der Gruppe der meisten Menschen, die das eh schon verstehen, so wie es bereits formuliert ist, durch eine alternative Formulierung noch mehr Leute erreichen?

Nur wenn man das mit "ja" beantworten kann, sollte man umformulieren. Nicht weil ein Text durch die Umformulierung formal "richtig" wird.

In den meisten Fällen ist nur ein "richtiger" Text für die Mehrheit verständlich, manchmal erreicht man nciht alle, aber auch Linuchs weiß ja nun was gemeint ist. Es gibt ja auch bei jedem Artikel im Wiki den Button "Hierzu das Forum befragen" oder so - da wird dann ja gerne auch noch weiter erklärt - manche Dinge sind einfach sehr schwer so zu erklären, dass man wirklich jeden damit erreicht.

Darüber reden, ob man einen Artikel besser machen kann: immer!

Ihn dann tatsächlich umschreiben: nur wenn er dadurch besser wird.

Ich glaube mein Ansatz führt zu mehr Verständlichkeit (längere Erklärung) stört aber auf jeden Fall alle, denen die viel kürzere Formulierung genug gewesen war. Die verlieren durch meinen Ansatz schlicht Zeit - und Konzentration.

Dein Bemühen, dem Text mehr Eindeutigkeit zu geben, hat IMHO zu einer schlechteren Verständlichkeit geführt.

Finde ich nicht, denn was jetzt dort steht, ist nicht das, was ich geschrieben hatte. Meine Formulierung war: "das erste Kindelement seines Elternelementes auszuwählen."

Sorry, mein Fehler!

Ich will da jetzt nicht ohne Rücksprache mit Dir auch noch drin herumfuhrwerken, daher mein Vorschlag, etwas mehr zu erklären:

Mehr Klarheit durch Ausführlichkeit? Kann man natürlich auch machen.

Ich glaube mein Ansatz führt zu mehr Verständlichkeit (längere Erklärung) stört aber auf jeden Fall alle, denen die viel kürzere Formulierung genug gewesen war. Die verlieren durch meinen Ansatz schlicht Zeit - und Konzentration.

Auch hier gilt: Den Text nur umschreiben, wenn er dadurch besser wird.

Ja. Das erste Kindelement in jedem Knoten.

Logisch!

Ja, fand ich auch.

Kontext kann auch in anderen Köpfen vorhanden sein. ;-)

Mir wird das auch gelegentlich bewusst, wenn ich mich mit meinem Onkel unterhalte. Der hält unter anderem auch Vorlesungen in Technische Dokumentation und hat mittlerweile einen geschärften Sinn für solche Merkwürdigkeiten - oder für Formulierungen, die allgemein üblich, aber falsch sind.

Hauptsache sie sind allgemein verständlich! ;-)

Im Alltag ja. In einer einschlägigen Vorlesung darf und muss man pingeliger sein. Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Ist das wirklich so?

Marc

[Der Martin]

Hallo,

Die grundsätzliche Frage, die man sich dann stellen muss: kann man etwas besser ausdrücken?

das ist zwar genau die richtige Frage, aber sie birgt ein großes Problem: "besser" ist ein subjektiver Begriff, der individuell unterschiedlich bewertet wird.

Und das heißt nicht eindeutiger oder weniger missverständlich. Das bedeutet meiner Meinung nach: kann ich zu der Gruppe der meisten Menschen, die das eh schon verstehen, so wie es bereits formuliert ist, durch eine alternative Formulierung noch mehr Leute erreichen?

Nur wenn man das mit "ja" beantworten kann, sollte man umformulieren. Nicht weil ein Text durch die Umformulierung formal "richtig" wird.

Hmm ...

Darüber reden, ob man einen Artikel besser machen kann: immer!

Ihn dann tatsächlich umschreiben: nur wenn er dadurch besser wird.

Da haben wir wieder den Begriff "besser". Ich fand, eindeutiger und damit weniger missverständlich sei auf jeden Fall auch besser.

Ich glaube mein Ansatz führt zu mehr Verständlichkeit (längere Erklärung) stört aber auf jeden Fall alle, denen die viel kürzere Formulierung genug gewesen war. Die verlieren durch meinen Ansatz schlicht Zeit - und Konzentration.

Ja, stimmt. Allen Menschen recht getan ...

Ich glaube mein Ansatz führt zu mehr Verständlichkeit (längere Erklärung) stört aber auf jeden Fall alle, denen die viel kürzere Formulierung genug gewesen war. Die verlieren durch meinen Ansatz schlicht Zeit - und Konzentration.

Du wiederholst dich. Warst du mal beim Fernsehen? ;-)

In einer einschlägigen Vorlesung darf und muss man pingeliger sein. Da würde mein lieber Onkel zum Beispiel den Satz "Die drei besten Teilnehmer erhalten einen Preis" anmarkern: Es gibt keine drei besten Teilnehmer, es gibt nur einen besten. Gemeint ist hier: "Die besten drei Teilnehmer ..."

Ist das wirklich so?

IMO ja. Mich hat er damals mit dem Beispiel überzeugt.

So long,
 Martin

[Matthias Apsel]

Hallo marctrix,

Es müssten dann ggf. alle Artikel zu den Selektoren geändert werden.

body ist nicht das erste Kind von html ;-p

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Es müssten dann ggf. alle Artikel zu den Selektoren geändert werden.

body ist nicht das erste Kind von html ;-p

Kennst du mein HTML ;-)

Nein, du hast natürlich recht. Selbst wenn ich es weglassen würde, wäre es nicht der erste Knoten im DOM...

Das war jetzt richtig falsch! Gut, dass du es nicht so hast stehen lassen.

Marc

[Auge]

Hallo

du willst es nicht verstehen, oder? *seufz*

Ich möchte es verstehen aufgrund einer "korrekten" Beschreibung. Oder dazu beitragen, Syntax-Angaben ein-deutig zu formulieren. Zum Stichwort CSS/Selektorenbei SelfHTML lese ich:

Mithilfe des Selektors :first-child ist es möglich, das erste Kindelement `eines` Elementes auszuwählen.

Ja, so habe ich es verstanden und so ist es falsch.

Dein Verständnis? Ja, offensichtlich.

Es wird das erste Kindelement vieler Elemente ausgewählt. Nicht das Erste sondern die Ersten - ist für mich ein Unterschied.

Ja, es wird das jeweils erste Kindelement eines Elternelements ausgewählt. Und ja, es kann in einem Dokument sowohl eines oder mehrere Elternelemente geben. Genauso funktioniert CSS. Wenn du das erste Kindelement eines bestimmten (Groß)-Elternelements selektieren willst, dann gib diesem eine ID, soll es das Kindelement einer bestimmten Gruppe sein, dann vergebe eine Klasse. Unter anderem dazu sind IDs und Klassen da.

Tschö, Auge

[Linuchs]

Ja, so habe ich es verstanden und so ist es falsch.

Dein Verständnis? Ja, offensichtlich.

Im meinem Leben hat es sich bewährt, an Wissen anzuknüpfen, das schon vorhandenn ist und Neues zu ergänzen.

Weil ich mich in Javascript ausgiebig mit Elementen im DOM beschäftigt habe, ist dort das erste td eben ein ganz bestimmtes und nicht ein Haufen wie in CSS.

Da ich gerne - was hier gescholten wird - im CSS redundant formuliere

table.liste tbody tr > td:nth-of-type(1) {text-align:right}

ist mir die Mehrdeutigkeit von :nth-of-type(1) nie aufgefallen.

Ich formuliere auch lieber heute, der 15. Aug 2016 und raufte mir jahrelang die Haare, wenn ich auf Webseiten Veranstaltungstermine ohne Jahreszahl finde, also unklar. Deshalb habe ich jetzt kaum noch welche und muss solche "Informationen" mangels möglicher Ausgleichshandlung ignorieren.

heute oder in diesem Jahr hat wie viele unterschiedliche Treffer im Lebsnszyklus einer Webseite?

Linuchs, der Pingelige

[Der Martin]

Hallo,

Ich formuliere auch lieber heute, der 15. Aug 2016

wenn es schon so eindeutig sein muss, lass ich die Angabe heute am besten gleich weg. Die stimmt morgen eh nicht mehr, denn schon morgen wird heute gestern sein.

und raufte mir jahrelang die Haare, wenn ich auf Webseiten Veranstaltungstermine ohne Jahreszahl finde, also unklar.

Das ist nicht auf Veranstaltungskalender beschränkt. Ich ärgere mich immer, wenn ich feststelle, dass der Duden (die gedruckte Ausgabe als Buch) kein Ausgabedatum verrät. Oder dass Stadtpläne nicht mit einem Ausgabedatum gekennzeichnet sind. Oder dass man nach einem zweiwöchigen Urlaub heimkommt und in der Post unter anderem einen Zettel findet, der für "nächsten Donnerstag" eine Altkleidersammlung ankündigt. Ist dieser bestimmte nächste Donnerstag schon vorbei? Oder kommt der noch?

heute oder in diesem Jahr hat wie viele unterschiedliche Treffer im Lebsnszyklus einer Webseite?

Zu viele.

Ciao,
 Martin

[Linuchs]

... Oder dass man nach einem zweiwöchigen Urlaub heimkommt und in der Post unter anderem einen Zettel findet, der für "nächsten Donnerstag" eine Altkleidersammlung ankündigt. Ist dieser bestimmte nächste Donnerstag schon vorbei? Oder kommt der noch?

Ahhh, ich freue mich, dass die Diskussion in die entspannte Phase tritt. Ich denke, es gibt immer einen nächsten Donnerstag mit Altkleidersammlung. Also nichts versäumt. Ganz anders als das nächste Wochenende. Wer das am Freitag sagt, meint oft das übernächste.

Oder er meint wirklich morgen und übermorgen und ich denke eine Woche weiter. Da kann man schon was versäumen.

Linuchs

[Gunnar Bittersmann]

@@Der Martin

Ich ärgere mich immer, wenn ich feststelle, dass der Duden (die gedruckte Ausgabe als Buch) kein Ausgabedatum verrät.

Die DDR-Ausgaben taten das. Runtergekommen, das Ding.

LLAP 🖖

[Auge]

Hallo

Weil ich mich in Javascript ausgiebig mit Elementen im DOM beschäftigt habe, ist dort das erste td eben ein ganz bestimmtes und nicht ein Haufen wie in CSS.

Und immer noch vergleichst du Äpfel mit Birnen. Der Martin hat nicht umsonst den Unterschied zwischen dem standardmäßig uneingeschränkten, dokumentweiten Fokus des entsprechenden JS-Arrays, der anderen Arbeitsweise von CSS und der Möglichkeit, diese „andere“ Arbeitsweise auch in JS zu erreichen, indem man den Fokus auf einen Ast des DOM beschränkt, herausgearbeitet. Es handelt sich eben nicht um einen „Haufen“, sondern um eine ganz bestimmte Menge von Elementen, die mit dem Selektor erfasst wird (wie auch in den JS-Fällen). Im hier diskutierten Fall sind das im CSS-Fall die jeweils ersten td oder th einer Tabellenzeile.

Tschö, Auge

[Gunnar Bittersmann]

@@Linuchs

Weil ich mich in Javascript ausgiebig mit Elementen im DOM beschäftigt habe, ist dort das erste td eben ein ganz bestimmtes und nicht ein Haufen wie in CSS.

Erstmal selektierst du in JavaScript mit document.getElementsByTagName() auch einen Haufen. Nur dass dieser geordnet ist und du danach aus dem Haufen das erste Element auswählen kannst. Diese Möglichkeit gibt es in CSS nicht.

Da ich gerne - was hier gescholten wird - im CSS redundant formuliere

table.liste tbody tr > td:nth-of-type(1) {text-align:right}

Das wird zurecht gescholten. Überspezifizierte Selektoren führen zu unwartbarem Code.

LLAP 🖖

[marctrix]

Hej Linuchs,

Weil ich mich in Javascript ausgiebig mit Elementen im DOM beschäftigt habe, ist dort das erste td eben ein ganz bestimmtes und nicht ein Haufen wie in CSS.

Nein, das verhält sich genau wie CSS - du hast Dich vorher nur bereits an eine bestimmte Stelle im DOM begeben, betrachtest also nur einen ganz kleinen Bereich im DOM und nimmst davon das erste td.

Geht in CSS genauso, wie du es vormachst (gibt noch andere Möglichkeiten, enn das HTML bekannt ist, ich mag Deine aber):

table.liste tbody tr > td:nth-of-type(1) {text-align:right}

Eine Frage nur: wenn es eine Liste ist, wieso verwendest du dann <table>?

Marc

[Gunnar Bittersmann]

@@Auge

Wenn du das erste Kindelement eines bestimmten (Groß)-Elternelements selektieren willst, dann gib diesem eine ID, soll es das Kindelement einer bestimmten Gruppe sein, dann vergebe eine Klasse. Unter anderem dazu sind IDs und Klassen da.

Eigentlich sind IDs und Klassen dazu da, den Inhalt zu beschreiben. Sie sollten eigentlich schon vor dem Stylen im Markup vorhanden sein.

LLAP 🖖

[Auge]

Hallo

Wenn du das erste Kindelement eines bestimmten (Groß)-Elternelements selektieren willst, dann gib diesem eine ID, soll es das Kindelement einer bestimmten Gruppe sein, dann vergebe eine Klasse. Unter anderem dazu sind IDs und Klassen da.

Eigentlich sind IDs und Klassen dazu da, den Inhalt zu beschreiben. Sie sollten eigentlich schon vor dem Stylen im Markup vorhanden sein.

*grmpf* Ja natürlich. IDs und Klassen sind dazu da, Elemente einzeln bzw. in Gruppen zu identifizieren, die z.B. auch – deshalb schrieb ich „unter anderem“ – mit CSS angesprochen werden können. Wo siehst du den Widerspruch? Weil ich nicht schrieb, welcher Schritt wann zu erfolgen hat?

Man, man man!

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

*grmpf* Ja natürlich. IDs und Klassen sind dazu da, Elemente einzeln bzw. in Gruppen zu identifizieren

Mein Punkt war: IDs und Klassen sind erstmal dazu da, Elemente genauer zu beschreiben.

Bspw. eine Tabelle für Kontogedöns mit <table class="konto"> (bzw. id). Und das, ohne daran zu denken, ob man das später zum Stylen gebrauchen könnte.

Wo siehst du den Widerspruch? Weil ich nicht schrieb, welcher Schritt wann zu erfolgen hat?

Doch, ebendas tatest du: „Wenn du das erste Kindelement … selektieren willst, dann gib diesem eine ID, … dann vergebe eine Klasse.“

Aber kein Grund, wegen Klein(l)igkeiten an die Decke zu gehen.

LLAP 🖖

[Auge]

Hallo

Okay, dann habe ich die Zählung im DOM-Konzept überhaupt nicht verstanden.

Nö, was du nicht verstanden hast, ist, dass auch CSS keine Programmiersprache ist.

Ich könnte mir mit Javascript doch wohl sämtliche td greifen und dem ersten im Dokument eine Hintergrund-Farbe geben?

Ja.

Aber CSS sieht das gaaaanz anders ... null (Ziffer 0) ist dort sowieso 1 und tatsächlich, der haut das in jede Tabelle, in jede Zeile ...

kopfschüttel

Wieso „kopfschüttel“? Jedes der angesprochenen td ist jeweils das erste Kind eines anderen Elements (tr), also wird es richtigerweise mit dem Selektor td:nth-of-type(1) („nimm das erste td jedes Elternelements“) angesprochen.

tr > td:nth-of-type(1) {background:#f00}

Dir ist klar, dass dieser Selektor tr > td:nth-of-type(1) genau die selben Elemente wie td:nth-of-type(1) erwischt?

Tschö, Auge

[Christian Kruse]

Hallo Auge,

Okay, dann habe ich die Zählung im DOM-Konzept überhaupt nicht verstanden.

Nö, was du nicht verstanden hast, ist, dass auch CSS keine Programmiersprache ist.

CSS ist Turing Complete, daher ist diese Aussage schwer haltbar ;-)

LG,
CK

[Auge]

Hallo

Okay, dann habe ich die Zählung im DOM-Konzept überhaupt nicht verstanden.

Nö, was du nicht verstanden hast, ist, dass auch CSS keine Programmiersprache ist.

CSS ist Turing Complete, daher ist diese Aussage schwer haltbar ;-)

Ich bin ja kein Experte in Informatik, aber ich lese dort von der Behauptung der Turingvollständigkeit von CSS. Dann lese ich Gegenstimmen und dann davon, dass nicht CSS3, sondern erst CSS3 und HTML5 und schlussendlich ganz unten, wieder anders, dass CSS3, HTML5 und ein bedienender Mensch zusammen turingvollständig sind. Das klingt nicht wirklich überzeugend. Andererseits ist der in der akzeptierten Antwort vorgestellte Code ganz schön creepy.

Ich denke aber, dass das für das hiesige Problem wurscht ist. :-)

Tschö, Auge

[Christian Kruse]

Hallo Auge,

Das klingt nicht wirklich überzeugend.

Ist es auch nicht (siehe die Voraussetzungen in der ersten Antwort). Aber es ist eine sehr witzige Überlegung und eine beeindruckende Implementation und es war hier das perfekte Posting um das zu verlinken ;-)

Ich denke aber, dass das für das hiesige Problem wurscht ist. :-)

Hence the tags ;-)

LG,
CK

[Linuchs]

Nö, was du nicht verstanden hast, ist, dass auch CSS keine Programmiersprache ist.

... und kann trotzdem zählen. Naja, nicht wirklich, wie wir gerade feststellen.

Und Entscheidungen treffen a:hover oder a:nichthover

Sogar die Zeit von 3 sec abfragen

.drehlogo {
  -webkit-transition: -webkit-transform 3s ease;
  -moz-transition: -moz-transform 3s ease;
  -ms-transition: -ms-transform 3s ease;
  -o-transition: -o-transform 3s ease;
  transition: transform 3s ease;
}
.drehlogo:hover {
  -moz-transform: rotate(360deg);
  -webkit-transform: rotate(360deg);
  -o-transform: rotate(360deg);
  -ms-transform: rotate(360deg);
  transform: rotate(360deg);
}

Linuchs

[MrMurphy1]

Hallo

Du meintest vermutlich tr, nicht td. Aber auch damit wird das so nichts, da tr nicht Kinder des Tabellenelements sind.

Richtig. Da war ich zu schnell. Also

.konto tr>:nth-child(1),
.konto tr>:nth-child(4) {
   width:20%;
}
.konto tr>:nth-child(2),
.konto tr>:nth-child(3) {
   width:30%;
}

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

Richtig. Da war ich zu schnell. Also

.konto tr>:nth-child(1),
.konto tr>:nth-child(4) {
   width:20%;
}
.konto tr>:nth-child(2),
.konto tr>:nth-child(3) {
   width:30%;
}

Kann man machen. Allerdings ist der Code nicht sprechend; man erkennt nicht auf den ersten Blick, welche Elemente damit gestylt werden (th und td, was im Selektor gar nicht vorkommt). Ich würde dafür schreiben:

.konto th,
.konto td
{
  width: 30%;
}

.konto th:first-child,
.konto th:last-child,
.konto td:first-child,
.konto td:last-child
{
  width: 20%;
}

Ist länger, aber selbsterklärend.

Zukünftig geht’s auch kürzer:

.konto :matches(th, td)
{
  width: 30%;
}

.konto :matches(th, td):matches(:first-child, :last-child)
{
  width: 20%;
}

The future is (almost) now.

Guckst du. Dummerweise setzt weder Autoprefixer noch Prefixfree :matches() in :-moz-any() und :-webkit-any() um, so dass ich mich hier eines Sass-Mixins bedient habe, um nicht den Deklarationsblock duplizieren zu müssen.

Nachtrag: Ginge hier aber auch ohne Sass; :matches() macht sich ja besonders bei der zweiten Regel bezahlt. Und darin ist nur eine Deklaration. Guckst du zweites Beispiel.

LLAP 🖖

[MrMurphy1]

Hallo

Nur zur Info: Das table-Element ist sachlich falsch, da keine Tabellendaten vorhanden sind. Du hast eine Liste die in Tabellendarstellung angezeigt werden soll. Als HTML-Element ist deshalb das dl-Element mit seinen Kindelementen dt und dd angebracht.

Aber zu deinem Problem:

Eine Tabelle beansprucht zunächst nur so viel Platz wie ihr Inhalt erfordert. Um Leerraum verteilen zu können muss er zunächst erzeugt werden. Dazu kannst du die Breite (width) des table-Elements zum Beispiel auf 100% erweitern.

Dann kannst du den einzelnen Spalten bestimmte Breiten zusordnen. Das geht natürlich nur wenn das Fenster breit genug ist. Die Darstellung für Smartphones und Tablets sollte über responsive Layouts mittels Media Queries angepasst werden.

Die Tabellenspalten kannst du entweder über die HTML-Elemente colgrounp und col oder über Selektoren bestimmen. Dort kannst du dann die von dir gewünschten Breiten vorgeben.

Sinnvoller ist meist jedoch mittels padding einen Mindestabstand zwischen Inhalt und Zellenrand vorzugeben und den Rest dem Browser zu überlassen.

Gruss

MrMurphy

[Auge]

Hallo

Nur zur Info: Das table-Element ist sachlich falsch, da keine Tabellendaten vorhanden sind.

Auch wenn du das ann allen Ecken und Enden immer wieder behauptest, wird diese Behauptung nicht richtiger.

Das da unten (aus dem verlinkten Dabblet) sind eindeutig tabellarische Daten.

|Datum|Bezeichnung|Name|Betrag |---| |15. August 2016|Einzahlung|Mustermann, Max|100,00€ |7. Juli 2016|Einzahlung|Peters, Petra|50,00€ |9. Mai 2016|Einzahlung|Meier, Manfred|600,00€

Du hast eine Liste die in Tabellendarstellung angezeigt werden soll. Als HTML-Element ist deshalb das dl-Element mit seinen Kindelementen dt und dd angebracht.

Warum um alles in der Welt willst du das umständlich als Liste nachbauen?

Tschö, Auge

[Klawischnigg]

Hi there,

Nur zur Info: Das table-Element ist sachlich falsch, da keine Tabellendaten vorhanden sind. Du hast eine Liste die in Tabellendarstellung angezeigt werden soll. Als HTML-Element ist deshalb das dl-Element mit seinen Kindelementen dt und dd angebracht.

Sorry, aber wenn das keine tabellarischen Daten sind, was glaubst Du eigentlich, warum es dann das table-Element überhaupt noch gibt? Nur damit sich irgendjemand am Rand der IT-Welt hinstellen und über die falsche Verwendung eines in Deinen Augen offensichtlich völlig überflüssigen Elements schwadronieren kann?

[Gunnar Bittersmann]

@@MrMurphy1

Nur zur Info: Das table-Element ist sachlich falsch,

Falsch?

da keine Tabellendaten vorhanden sind.

Deine Einschätzung ist falsch.

Als HTML-Element ist deshalb das dl-Element mit seinen Kindelementen dt und dd angebracht.

Auch weil das wegen des in HTML fehlenden di-Elements durchaus Probleme beim Stylen macht, ist der Ratschlag falsch.

Die Tabellenspalten kannst du entweder über die HTML-Elemente colgrounp und col oder über Selektoren bestimmen. Dort kannst du dann die von dir gewünschten Breiten vorgeben.

Ja, kann man. Man kann aber auch den Tabellenzellen die gewünschten Breiten geben.

Sinnvoller ist meist jedoch mittels padding einen Mindestabstand zwischen Inhalt und Zellenrand vorzugeben und den Rest dem Browser zu überlassen.

Das hängt vom jeweiligen Fall ab, ob das wirklich sinnvoller ist.

LLAP 🖖

[Christian Kruse]

Hallo MrMurphy1,

der Vollständigkeit halber:

Die Darstellung für Smartphones und Tablets sollte über responsive Layouts mittels Media Queries angepasst werden.

Nee, umgekehrt. Die Darstellung für Desktops sollte mittels Media Queries angepasst werden.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Die Darstellung für Smartphones und Tablets sollte über responsive Layouts mittels Media Queries angepasst werden.

Nee, umgekehrt. Die Darstellung für Desktops sollte mittels Media Queries angepasst werden.

Nee. Dem würde ich – wenn’s um Tabellen geht – nicht zustimmen. Es könnte unsinnig sein.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Die Darstellung für Smartphones und Tablets sollte über responsive Layouts mittels Media Queries angepasst werden.

Nee, umgekehrt. Die Darstellung für Desktops sollte mittels Media Queries angepasst werden.

Nee. Dem würde ich – wenn’s um Tabellen geht – nicht zustimmen.

Das macht nichts, ich habe mich schon lange damit abgefunden oft anderer Meinung zu sein als du ;)

LG,
CK

[Matthias Apsel]

Hallo bleumi85,

Jetzt hätte ich bspw. gerne die erste Spalte auf 20% der Breite, die zweite und dritte und Spalte auf 30% der Breite und die Vierte wieder auf 20%. Ich hab aber keine Ahnung wie ich das anstelle und meine bisherigen Bemühungen verliefen im Sande. Kann mir jemand weiterhelfen?

Das Wiki. Ausgangspunkt

Bis demnächst
Matthias