nicht angemeldet
Gunnar Bittersmann
Rolf B
marctrix
marctrix
Gunnar Bittersmann
Matthias Apsel
marctrix
Rolf B
marctrix
Gunnar Bittersmann
marctrix
Guten Morgen! Wie erreiche ich daß ein td fixe "%-Breite" einhält, also die Beite nicht vom Inhalt abhängt, und Scrollbalken nur bei Bedarf angezeigt werden?
Julius
JürgenB<!DOCTYPE html><html lang="de"><head><meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>P R E I S L I S T E</title>
<style>
.dt0{ width: 32%;border:1px solid black; /* 3*32% */
max-width: 32%;
overflow: scroll;}
.plz{width: 2%;} /* Platzhalter + 2* 2% = 100% */
</style>
</head>
<body style="width:100%;">
<table style="width:98%; height:50em; border-collapse: collapse;">
<tr>
<td class="dt0">xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1<br>z
</td>
<td class="plz">
</td>
<td class="dt0">yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
</td>
<td class="plz">
</td>
<td class="dt0">
</td>
</tr>
</table>
</body>
</html>
@@mathefritz
BTW:
<title>P R E I S L I S T E</title>
ist falsch. Was soll den ein Screenreader da vorlesen? „Pe-er-e-i-es-el-i-es-te-e“?
Richtig: <title>Preisliste</title>
LLAP 🖖
hm hm das läßt einen aber Stylingmöglickeiten für titel wünschen. Aber der Browser hat keine Einflußmöglickeit auf die Fensterverwaltung ( Linux Systemeinstellungen ) .
Hallo mathefritz,
hm hm das läßt einen aber Stylingmöglickeiten für
titelwünschen.
Wenn du den Titeltext sperrst, erhöhst du die Wahrscheinlichkeit, dass der Nutzer – je nach Gerät – den Titel deiner Seite nicht vollständig sehen kann.
Aber der Browser hat keine Einflußmöglickeit auf die Fensterverwaltung ( Linux Systemeinstellungen ) .
Die Darstellung der Tabs erzeugt er selber, aber auch hier wäre ein Styling zwecklos. Zumindest ich habe jedenfalls keine Lust auf bunte, blinkende oder komische Schriftarten, weil jede Webseite meint, besonders wichtig zu sein.
Gruß
Julius
schon gut. Die td-Frage ist wichtig.
Danke, ist was ich brauche.
Hallo mathefritz,
ich habe hier etwas gespielt, und mein Kenntnisstand ist:
Rolf
Danke Rolf B,
ja,
Raum zwischen den Zeilen würde stören; aber warum klappt eigentlich margin-right: 2%; als Ersatz der SpacingSpalten nicht?
Hallo Rolf B,
- dann noch
border-collapse:separate; border-spacing:2%
REIN THEORETISCH kann man border-spacing mit zwei Werten angeben, horizontal und vertial, aber selbst in den Beispielen im MDN funktioniert das nicht.
Prozentangaben sind für border-spacing nicht erlaubt.
Steht auch hier: https://www.w3.org/TR/css-tables-3/#border-spacing-property
Welches nun das richtige ist (eins zu alt, das andere zu neu), weiß ich auch nicht.
Bis demnächst
Matthias
Hallo Matthias Apsel,
Welches nun das richtige ist (eins zu alt, das andere zu neu), weiß ich auch nicht.
Vielleicht die: https://www.w3.org/TR/CSS22/tables.html#separated-borders
Bis demnächst
Matthias
@@Rolf B
REIN THEORETISCH kann man border-spacing mit zwei Werten angeben, horizontal und vertial, aber selbst in den Beispielen im MDN funktioniert das nicht.
in meinem Beispiel funktioniert es.
@Gunnar Bittersmann - was ist da los?
Wo ist da?
LLAP 🖖
Hallo Gunnar Bittersmann,
REIN THEORETISCH kann man border-spacing mit zwei Werten angeben, horizontal und vertial, aber selbst in den Beispielen im MDN funktioniert das nicht.
in meinem Beispiel funktioniert es.
ebenso im Wiki.
Bis demnächst
Matthias
Wo ist da?
Eigentlich hier - aber da habe ich blind darauf vertraut, dass das Beispiel auch das umsetzt, was im Beispieltext steht. Tut es jedoch nicht.
Matthias' Hinweis mit den Prozenten war das, was mir fehlte.
Rolf
Hej mathefritz,
da du in deinem Code (absichtlich) und auch in dem text deinen postings sehr wenige Infos bereit stellst, ist es nur eine Vermutung, aber ich glaube, du suchst eigentlich CSS Grid…
Wie gesagt, nur geraten. Vielleicht liege ich auch völlig daneben.
Marc
Hallo Marc,
Du
liegst schon richtig, hab dazu momentan nur das dazu und nicht die Muße zu genauem Studium .
Der Screenshot ist ein Auszug aus der Seite die ein Bekannter mich unentgeltlich überarbeiten läßt, wobei der Inhalt der mittleren breiten Spalte der Umfassenden einzeiligen Tabelle ein anderer sein wird als der der linken, und auch der Inhalt der rechten noch nicht feststeht
Hej mathefritz,
Du
liegst schon richtig,
Dann solltest du auf keinen Fall Layout-Tabellen nehmen, die machen mehr Probleme, als sie lösen.
hab dazu momentan nur das dazu und nicht die Muße zu genauem Studium.
Ja, das ist schon so ziemlich der kompakteste Guide. Aber um drei Spalten zu erzeugen reicht auch flexbox.
Weil man manchmal einfach voran kommen muss, gebe ich dir ausnahmsweise einen Fisch (heißt ich zeige dir einen möglichen Lösungsweg) und sage dir zusätzlich, wo du die Angel findest (wo du also erklärt bekommst, was da passiert und warum das funktioniert): Flexboxen werden auch auf css−Tricks erklärt, der flex-Box−Guide ist aber wesentlich kürzer als der CSS-Grid-Guide. Den solltest du dir auf jeden Fall anschauen.
Und dann natürlich die ausführliche Erklärung hier im Wiki: Flexbox
Ok, kommen wir zum Fisch, damit du schnell satt wirst.
Für die flexbox-Lösung brauchst du zusätzliche Container, aber die hättest du bei der Tabelle auch.
Alles was du benötigst ist ein Container mit drei Kindern, je einer pro Tabelle.
Am schönsten wäre es einen Container zu nehmen, den du schon hast. Vielleicht passt ˋmainˋ. Wenn du für die Tabellen noch eine Überschrift hättest, würde ich für jede ein ˋsectionˋ-Element als Container nehmen, sonst ˋdivˋ.
Dann bekommst du folgendes HTML:
<main>
<section>
<h1>heading</h1>
<table>
<tr>
<th>
column heading
</th>
</tr>
</table>
</section>
<section>
<h1>heading</h1>
<table>
<tr>
<th>
column heading
</th>
</tr>
</table>
</section>
<section>
<h1>heading</h1>
<table>
<tr>
<th>
column heading
</th>
</tr>
</table>
</section>
</main>
Um die Sektionen nebeneinander zu stellen, machst du aus ˋmainˋ einen flex-container. Das macht die Kinder, im Beispiel also die Sektionen, automatisch zu flex-items.
Damit die sich den Platz untereinander aufteilen und die gesamte seitenbreite ausfüllen, gibst du für die Kinder ein ˋflex: autoˋ mit.
Dein css sieht dann so aus:
main {
display: flex;
}
main > * {
flex: auto;
}
Das funktioniert erst mal, lies dir aber auf jeden Fall die Theorie durch. Wenn man für andere Webseiten erstellt, sollte man wissen, was man tut. Auch wenn man dafür nicht bezahlt wird!
Marc
@@marctrix
Dreimal h1 in deinem Beispiel? Eher nicht. Die Überschriften wären gern auf niedrigerer Ebene.
Für die flexbox-Lösung brauchst du zusätzliche Container
Nein. Die Tabellen können die Flexitems sein:
<main>
<table>
<caption>heading</caption>
⋮
</table>
<table>
<caption>heading</caption>
⋮
</table>
<table>
<caption>heading</caption>
⋮
</table>
</table>
LLAP 🖖
Hej Gunnar,
@@marctrix
Dreimal
h1in deinem Beispiel? Eher nicht. Die Überschriften wären gern auf niedrigerer Ebene.
Es kommt nicht darauf an, was die Überschriften wollen, sondern ob das Dokument korrekt strukturiert ist. Ich fange immer bei 1 an zu zählen.
Für die flexbox-Lösung brauchst du zusätzliche Container
Nein. Die Tabellen können die Flexitems sein:
Lassen sich ˋcaptionsˋ von screenreadern anspringen?
Ich würde eher ˋdisplay: inline-table;ˋ verwenden, wenn es außer den Tabellen keinen Inhalt gibt. Was ich persönlich problematisch finde, denn so wie ich den Screenshot gesehen habe, gibt es da Bedarf an Überschriften und Erläuterungen.
Wenn es dann so viel Inhalt gibt, dass die Kästen eigenständig Sinn machen, wären es drei ˋarticleˋ — endgültig entscheiden lässt sich das erst, wenn man die tatsächlichen Inhalte kennt.
Dann weiß man auch welche Überschriften-Ebene zu verwenden ist. So lange es aber keine höhere gibt, ist ˋh1ˋ korrekt.
Marc
@@marctrix
So lange es aber keine höhere gibt, ist ˋh1ˋ korrekt.
Es sollte eine höhere geben: die Seitenüberschrift.
LLAP 🖖
Hej Gunnar,
@@marctrix
So lange es aber keine höhere gibt, ist ˋh1ˋ korrekt.
Es sollte eine höhere geben: die Seitenüberschrift.
Mein Beispiel kommt ohne aus. Dabei handelt es sich nicht um eine komplette Webseite. Die Tabellen-Struktur ist auch nur angedeutet.
Aber ja, ich fange bei eins an zu zählen. Danach mache ich mit zwei weiter. 😉
Ich weiß übrigens sehr wohl, was du meinst. Aber wenn ich hier eine h2 verwende, macht es keinen Sinn. Dann müsste ich mangels eines echten seitentitels noch ein <h1>foo</h1> drübersetzen. Oder <h1>Seitenüberschrift</h1>. Aber auch die könnte eine h2 sein, falls der Portal-Titel als h1 ausgezeichnet ist. In diesem Fall könnte sie aber auch eine h1 sein, das hängt dann von weiteren Faktoren ab. All das tut bei diesem Beispiel nichts zur Sache und lenkt nur vom eigentlichen Problem ab.
Wenn der OP die Überschriften-Hierarchie nicht anpassen kann, müssen wir uns mit ihm noch ganz anders unterhalten. Dann müssen nämlich die ganzen hier angedeuteten Fälle aufgedröselt, erklärt und begründet werden.
Marc
@@marctrix
<h1>Seitenüberschrift</h1>. Aber auch die könnte eine h2 sein, falls der Portal-Titel als h1 ausgezeichnet ist.
Der Fall sollte nicht eintreten.
☞ Thread
Auf sämtlichen SELFHTML-Seiten (Forum, Blog, Wiki) ist es falsch gemacht, da zusätzlich zur Seitenüberschrift auch das SELFHTML-Logo als h1 ausgezeichnet ist. Das h in h1 steht aber für Highlander: Es kann nur einen geben. Bug-Ticket erstellt.
LLAP 🖖
Hej Gunnar,
@@marctrix
<h1>Seitenüberschrift</h1>. Aber auch die könnte eine h2 sein, falls der Portal-Titel als h1 ausgezeichnet ist.
Der Fall sollte nicht eintreten.
Er darf aber eintreten. Überschriftenstrukturen müssen logisch nachvollziehbar sein und den Sitetitle als h1 auszuzeichnen ist weit verbreitet (Konventionen sind dein Freund).
Mit Gefühlen hat das nichts zu tun. Nicht einmal, wenn es die Gefühle von Leonie Watson sind.
Beides kann. Dass die h1 zunehmend als sitetitle verschwindet, finde ich persönlich schade, weil ich es gerne als highlander genutzt habe. Wenn du ohne eine h1 da oben die Seitenbereiche überschreiben willst (und das ist sinnvoll für Navigation, Seitenleiste, footer usw), bleibt dir dafür nur die h1 - finde ich persönlich zu stark (ich fand h2 eigentlich schon zu viel, nicht nur aber auch natürlich aus SEO-Sicht). Aber man beginnt nun mal mit der h1. Da beißt die Maus keinen Faden ab. Denn sonst wäre es keine nachvollziehbare Überschrittenstruktur mehr.
Marc
PS: mach doch mal einen Vorschlag oder gib den von Leonie weiter. Aber dabei nicht nur an Blinde denken!
@@marctrix
den Sitetitle als h1 auszuzeichnen ist weit verbreitet
Millionen Fliegen … Punkt 2 auf meiner Liste.
Aber man beginnt nun mal mit der h1.
für den Hauptinhalt der Seite, ja. Also für die Seitenüberschrift.
Die Site-Kennung ist gegenüber dem Hauptinhalt nur schmückendes Beiwerk. Warum sollte die Site-Kennung stärker hervorgehoben sein als die Hauptüberschrift des Hauptinhalts? Eben.
LLAP 🖖
Hej Gunnar,
@@marctrix
den Sitetitle als h1 auszuzeichnen ist weit verbreitet
Millionen Fliegen … Punkt 2 auf meiner Liste.
Konventionen sind dein Freund bei der Entwicklung nutzbarer, zugänglicher Internetseiten.
Aber man beginnt nun mal mit der h1.
für den Hauptinhalt der Seite, ja.
Wo steht das? Entscheidend ist nur eines: Nachvollziehbarkeit der Struktur. Ich finde die im Web Accesibility Tutorial „Headings“ gezeigte Struktur besonders verständlich, setze die seit Jahren ein, bin damit durch zahlreiche bitv-Tests gekommen und habe die oben erklärt.
Dein Vorschlag, den auch Leonie Watson präferiert, wird im zweiten Beispiel dargestellt. Ich wiederhole: beides ist möglich, so lange es verständlich ist.
Beides kann, keines muss. Eine Abwägung abhängig von der konkreten Seite macht Sinn. Dogmen dagegen sind selten hilfreich.
Marc
@@marctrix
den Sitetitle als h1 auszuzeichnen ist weit verbreitet
Millionen Fliegen … Punkt 2 auf meiner Liste.
Konventionen sind dein Freund bei der Entwicklung nutzbarer, zugänglicher Internetseiten.
weit verbreitet ≠ Konvention
Beides kann, keines muss.
Ich hatte im verlinkten Thread extra nachgefragt. Ich habe keinen Anlass, den dort gegebenen Antworten zu misstrauen.
Dogmen dagegen sind selten hilfreich.
Die Antworten von Fachleuetn als „Dogmen“ abzutun ist auch selten hilfreich.
LLAP 🖖
Hej Gunnar,
@@marctrix
Ich hatte im verlinkten Thread extra nachgefragt. Ich habe keinen Anlass, den dort gegebenen Antworten zu misstrauen.
Dogmen dagegen sind selten hilfreich.
Die Antworten von Fachleuten als „Dogmen“ abzutun ist auch selten hilfreich.
Das habe ich auch nicht, sondern deine etwas starrsinnige Haltung in dieser Frage. Ich habe mich heute eingehend mit dem Thema beschäftigt. Wie so oft gibt es eine aktuelle Entwicklung, die es sinnvoll machen könnte, die h1 für den Seitentitel zu verwenden: es wird immer häufiger gemacht.
Dennoch gibt es weitere nachvollziehbare und sinnvolle Möglichkeiten einer Überschriftenstruktur, die nach wcag erlaubt und für alle Menschen zugänglich sind.
Zum Beispiel kann es durchaus Sinn machen, die h1 mehrfach zu verwenden.
Insofern ist deine pauschale Behauptung, das Wiki mache das überall falsch, so nicht haltbar.
Marc
Hej marctrix,
Dennoch gibt es weitere nachvollziehbare und sinnvolle Möglichkeiten einer Überschriftenstruktur, die nach wcag erlaubt und für alle Menschen zugänglich sind.
title-Element direkt noch mal derselbe Text vorgelesenmain-Element.
Mag jeder selbst entscheiden ob das nötig ist: Drei Navigationsmöglichkeiten mit denselben Ziel, zwei davon exklusiv für Screenreader-Nutzer, eine weitere (Skip-Navi) exklusiv für Tastatur-Nutzer (was Screenreader einschließt) ist nett für Screenreader-Nutzer und es entstehen keine Nachteile für andere Nutzergruppen (dem einen oder anderen mag es bei eigenem CSS oder fehlendem CSS komisch vorkommen, dass ein Dokument nicht mit einer Überschrift/ nicht mit der größten Überschrift beginnt)
Außerdem müsste man mit demselben Argument auch Navigation, Seitenleiste und Foooter per h1 zugänglich machen. Siehe auch drittes Beispiel.main-Elementes)Kann theoretisch die Vorteile beider Lösungen verbinden. Dass es nur eine h1 in einem HTML-Dokument geben sollte, ist ein seit Anbeginn strittiges, nicht entschiedenes Thema. Die Zugänglichkeit wird jedenfalls nicht negativ beeinflusst, wenn die Struktur nachvollziehbar bleibt.
Was nicht geht ist jedenfalls, sich auf die in keinem Browser/UA implementierten HTML5-Outline-Algorythmus zu verlassen. Die Spee
Mir persönlich sagt diese Lösung dennoch am wenigsten zu, ich kann es aber schlecht begründen, es ist vermutlich nur Gewohnheit, also irrational. Über echte Gründe für oder gegen die Verwendung mehrere h1 würde ich mich freuen!
Marc
Korrektur
Der Nachteil „ Screenreader-Nutzern wird nach dem title-Element direkt noch mal derselbe Text vorgelesen “ betrifft die zweite Möglichkeit, in der es nur eine h1 gibt, die zum Überschreiben des hauptinhaltes verwendet wird. Sorry dafür…
@@marctrix
Das habe ich auch nicht, sondern deine etwas starrsinnige Haltung in dieser Frage.
Nix starrsinnig. Ich gebe das wieder, was Leute dazu sagen, die ich für Experten auf dem Gebiet halte. Zumal einige davon selbst betroffen sind.
Ich hab nochmal nachgefragt. Léonie wiederholt nochmal: ein h1 pro Seite. Heydons ♥️ werte ich mal als Zustimmung.
Ich könnte natürlich dazuschreiben: „Experten sagen so; aber wenn ihr meint, es besser zu wissen als die, die sich damit auskennen …“, halte das aber nicht für zielführend.
Wie so oft gibt es eine aktuelle Entwicklung, die es sinnvoll machen könnte, die h1 für den Seitentitel zu verwenden: es wird immer häufiger gemacht.
Da isses wieder: Machen andere doch auch so …
LLAP 🖖
Hej Gunnar,
@@marctrix
Das habe ich auch nicht, sondern deine etwas starrsinnige Haltung in dieser Frage.
Nix starrsinnig.
Dazu unten mehr.
Ich gebe das wieder, was Leute dazu sagen, die ich für Experten auf dem Gebiet halte. Zumal einige davon selbst betroffen sind.
Betroffenheit ist selten eine gute Voraussetzung für eine objektive Stellungnahme. Und das sieht man an der Antwort von Leonie Watson auch sehr gut, die nämlich zwischen der Spec und einem best practice einerseits und ihren persönlichen Präferenzen andererseits sehr gut unterscheiden kann. Sie kann nämlich als Betroffene objektive Antworten geben! Keine Selbstverständlichkeit. Daher schätze ich, was sie sagt!
Leider gibst du hier keineswegs einfach nur wieder, was sie sagt, sondern Deine Interpretation, die durch Deine Ergebniserwartung beeinflusst ist. So sagt sie nämlich ganz klar, dass eine h1 über dem Haupttext ihre persönliche Vorliebe ist (im englischen Original klingt das so: „My personal pref is 1 h1“.
Frage doch bitte, was du hier behauptest, nämlich, ob andere Überschriftenstrukturen grundsätzlich falsch und laut WCAG nicht zulässig sind.
Schließlich ist das deine Behauptung, die wir hier diskutieren.
Ich hab nochmal nachgefragt. Léonie wiederholt nochmal: ein
h1pro Seite. Heydons ♥️ werte ich mal als Zustimmung.
Das sind erst mal nur persönliche Meinungen. Zudem Meinungen von Nutzern, die Ihre Nutzeragenten besonders gut beherrschen. Ein Grund für die eine h1 über dem Haupttext ist allerdings, dass dies eine zusätzliche Möglichkeit ist, den Hauptinhalt direkt anzuspringen, weil es nicht den einen Nutzer gibt. Nirgends - auch nicht in "Inclusive Design Patterns" habe ich gelesen, dass sich irgendeine dieser Behauptungen und Annahmen repräsentativ belegen lässt. Auch das habe ich noch mal nachgelesen. Heydon erwähnt hier nur, dass es User gibt, die Überschriften zum Navigieren im Dokument nutzen. Ob die alle bei einem Druck auf die Taste 1 direkt im Hauptartikel landen möchten oder lieber einen Überblick über den Aufbau des HTML-Dokumentes wünschen, wird nicht thematisiert.
Dennoch: Ich schätze solche Meinungen, insbesondere weil ich die Antwortenden alle kenne und weiß, dass sie Ahnung haben. Und ich schätze Deine Meinung. Das ist der Grund, warum ich mehrere Stunden in die Recherche der Angelegenheit gesteckt habe, statt weitere Experten zu befragen oder dieselben Experten sinnvoll zu befragen, so dass wir eine Antwort auf die Frage nach der Zulässigkeit bekommen.
Das Ergebnis habe ich geschildert.
Allerdings habe ich nirgends gelesen, dass es nur eine erlaubte oder nur eine zugängliche Überschriften-Struktur gibt. Ausschließlich den Haupttext mit einer h1 zu versehen ist eine Möglichkeit unter anderen. Ein Beispiel dafür habe ich in dem WCAG-Tutorial gefunden — gleich neben dem Beispiel, das ich hier als ebenfalls zulässig bezeichnet habe.
Diese Möglichkeit als "falsch" hinzustellen, ist nicht in Ordnung. Einen Bug-Report zu verfassen und eventuell für einen Haufen Arbeit zu sorgen, der nicht unbedingt nötig ist, finde ich auch nicht gut.
Und an dieser Behauptung ohne jeden Beleg festzuhalten, ist starrsinnig.
Aber machen wir es anders: Ich habe mich schon öfters von Dir überzeugen lassen. Ein Link zur Spec reicht gewöhnlich.
Deswegen frage ich noch mal: wo steht das?
Wie so oft gibt es eine aktuelle Entwicklung, die es sinnvoll machen könnte, die h1 für den Seitentitel zu verwenden: es wird immer häufiger gemacht.
Da isses wieder: Machen andere doch auch so …
Ja, Ein wichtiger Punkt in meinem Abwägungsprozess. Wie ich mehrfach geschildert habe, gibt es verschiedene Arten von zugänglichen Überschriftenstrukturen. Eine zu wählen, die Nutzern vertraut ist, macht sehr viel Sinn. Da sich das mit den Jahren ändert, ist es kein „das haben wir immer schon so gemacht“, sondern eine Entscheidung nach einem Abwägungsprozess, bei dem ein Aspekt die Frage ist: „Können Besucher das so, wie ich es mir überlegt habe, intuitiv bedienen? Oder zwinge ich sie zum Nachdenken?“. Wenn die Antwort lautet: „Das müssten sie eigentlich von Millionen anderen Seiten so kennen“, finde ich das gut. Ein Punkt auf der Pro-Seite.
Das solltest du von mir inzwischen kennen. Übrigens sehen das Heydon Pickering, Steve Krug und andere auch so — du siehst, ein paar von den Millionen Fliegen kann ich namentlich nennen. 😉
Marc
@@marctrix
Zum Beispiel kann es durchaus Sinn machen, die h1 mehrfach zu verwenden.
Der Sinn wäre welcher?
Insofern ist deine pauschale Behauptung, das Wiki mache das überall falsch, so nicht haltbar.
Jedenfalls macht es nicht nur das Wiki, sondern der ganze SELF-Raum einschließlich Forum und Blog entgegen dem, was im Wiki gesagt wird (und das stammt nicht von mir): „Sie sollten auf einer Seite maximal eine Überschrift der ersten Ebene einsetzen“.
Sich an die eigenen Ratschläge nicht zu halten, würde ich schon „falsch“ nennen.
LLAP 🖖
Hej Gunnar,
@@marctrix
Zum Beispiel kann es durchaus Sinn machen, die h1 mehrfach zu verwenden.
Der Sinn wäre welcher?
Noch mal lesen bitte, steht in dem Beitrag.
Unter anderem macht es die Dokumentstruktur (Navi, Hauptinhalt, Weiterführende Infos, Anbieter-Informationen) per h1 zugänglich und passt somit prima zu Heydons Argumentation, mehrere Wege anzubieten. Ich gebe zu, es passt nicht zu seiner (unbelegten) Ansicht, dass es nur eine h1 geben darf.
Aber das gibt die Spec auch nicht her.
Insofern ist deine pauschale Behauptung, das Wiki mache das überall falsch, so nicht haltbar.
Jedenfalls macht es nicht nur das Wiki, sondern der ganze SELF-Raum einschließlich Forum und Blog entgegen dem, was im Wiki gesagt wird (und das stammt nicht von mir): „Sie sollten auf einer Seite maximal eine Überschrift der ersten Ebene einsetzen“.
Sich an die eigenen Ratschläge nicht zu halten, würde ich schon „falsch“ nennen.
Der Rat ist tatsächlich falsch: „Sie sollten auf einer Seite maximal eine Überschrift der ersten Ebene einsetzen“ bedeutet ja, dass man auch ohne h1 auskommen kann.
Hierzu sagt die WCAG auch eindeutig, dass mit der h1 zu beginnen ist und das auch in der Folge keine Ebenen ausgelassen werden sollen.
Marc
@@marctrix
Der Rat ist tatsächlich falsch: „Sie sollten auf einer Seite maximal eine Überschrift der ersten Ebene einsetzen“ bedeutet ja, dass man auch ohne
h1auskommen kann.
Ich hatte schon überlegt, da Hand anzulegen, dann aber innegehalten. Es könnte ja tatsächlich Seiten ohne irgendeine Überschrift geben.
(Jetzt willst du wieder, dass ich mir ein Beispiel aus den Fingern sauge‽)
LLAP 🖖
Hej Gunnar,
@@marctrix
Es könnte ja tatsächlich Seiten ohne irgendeine Überschrift geben.
(Jetzt willst du wieder, dass ich mir ein Beispiel aus den Fingern sauge‽)
Ich könnte auch deinem Beispiel folgend nach dem Sinn fragen… 😉
Nein, hätte ich jetzt ohne den Zusatz in der Klammer einfach so stehen gelassen…
Marc
Danke für Fisch und Angel;
aber ich hoffe doch,
das Folgende läßt sich so ändern das es auch bei vernünftig verringerter Fensterbreite funktioniert
<!DOCTYPE html><html lang="de"><head><meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>PREISLISTE</title>
<style>
.plz{width: 2.5%;} /* Platzhalter 4* 2.5% */
.dt0{width: 30%; border:1px solid black; /* + 3*30.0% = 100% */
vertical-align:top;
}
.tdtop{color: red; text-align:center; border-bottom: 1px solid black;}
.tdmid{ text-align:center; border-bottom: 1px solid black;
border-right : 1px solid black;
}
.tdmdr{ text-align:right ; border-bottom: 1px solid black;
border-right : 1px solid black;}
.tdrgt{ text-align:center; border-bottom: 1px solid black;}
.green{background: lightgreen;}
</style>
</head>
<body style="width:100%;">
<table style="width:98%; height:50em; border-collapse: collapse;
table-layout:fixed;
display:inline-table;">
<tr>
<td class="plz">
<td class="dt0">
<div style="overflow-x:auto; text-align: center;padding-top:0.2em;"
>Produktanalyseliste(Ausschnitt)
</div>
<table width="100%">
<tr style="max-width:100%;">
<td class="tdtop">Artikel</td>
<td class="tdtop">Leistung</td>
<td class="tdtop">Preis</td>
<td class="tdtop">gängig?</td></tr>
<tr><td class="tdmid green">BU-EIN-Teil</td>
<td class="tdmid green" >Gutachten mit 15 Messergebnissen &
3 Endergebnissen</td>
<td class="tdmdr green">300,00€</td>
<td class="tdrgt green">Ja</td></tr>
<tr><td class="tdmid">BU-Zwei-Teile</td>
<td class="tdmid">Gutachten mit 2x15 Messergebnissen &
2x3 Endergebnissen</td>
<td class="tdmdr">600,00€</td>
<td class="tdrgt">Ja</td></tr>
<tr><td class="tdmid green">BU-Zwei-Teile Baugruppe</td>
<td class="tdmid green">Gutachten mit 36 Messergebnissen &
3 Endergebnissen</td>
<td class="tdmdr green">900,00€</td>
<td class="tdrgt green">Ja</td></tr>
</table>
</td>
<td class="plz">
</td>
<td class="dt0">
</td>
<td class="plz">
</td>
<td class="dt0">
</td>
</tr>
</table>
</body>
</html>
Ich habe auch eine flex Lösung angedacht, komme da aber noch weniger weit,
Entfernen der Auskommentierung bringt alles durcheinander.
<!DOCTYPE html><html lang="de"><head><meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>PREISLISTE</title>
<style>
.inrtab{border:1px solid black; width:30%; height:100%;}
</style>
</head>
<body style="width:100%;">
obberhalb
<div style="width:100%; justify-content: space-evenly;
height: 20em;
display: flex; align-items: flex-start;"
>
<table class="inrtab">
<tr><th style="colspan:4; text-align:center;
vertical-align:top;"
>Produktanalyseliste(Ausschnitt)</th
></tr> <!--
<tr><td>Artikel</td>
<td>Leistung</td>
<td>Preis</td>
<td>gängig?</td> -->
</tr>
</table>
<table class="inrtab"><tr><td> T </td></tr></table>
<table class="inrtab"><tr><td> T </td></tr></table>
</div>
<br>unterhalb
</body></html>
Hallo mathefritz,
.plz{width: 2.5%;} /* Platzhalter 4* 2.5% */ .dt0{width: 30%; border:1px solid black; /* + 3*30.0% = 100% */ vertical-align:top; } .tdtop{color: red; text-align:center; border-bottom: 1px solid black;} .tdmid{ text-align:center; border-bottom: 1px solid black; border-right : 1px solid black; } .tdmdr{ text-align:right ; border-bottom: 1px solid black; border-right : 1px solid black;} .tdrgt{ text-align:center; border-bottom: 1px solid black;} .green{background: lightgreen;}
alles was dort mit border zu tun hat, wird vermutlich durch
table {
border-collapse: collapse;
border: 1px solid black;
}
auch erreicht.
<body style="width:100%;">
Über inline-styles wurde schon ausführlich gesprochen. Warum sind die immer noch drin?
<td class="tdtop">Artikel</td> wäre gern <th>Artikel</th>
Die vielen Klassenzuweisungen sind mMn. nicht nötig. Zur Breitenangabe kannst du col-Elemente mit den entsprechenden Klassen verwenden. Die Breiten werden dann auf alle entsprechenden Zellen übertragen. Alternativ geht das auch mit den th-Elementen.
Warum eine Tabelle innerhalb einer Tabelle ist, erschließt sich mir nicht. (Aus deinem Screenshot geht das jedenfalls nicht hervor.
Dem Screenshot entnehme ich außerdem, dass die Klasse .green nur dazu dient, jede zweite Zeile anders zu färben. Abgesehen davon, dass es eine präsentationsbezogene Klasse ist, gibt es tr(odd) { background-color: green;}.
Bis demnächst
Matthias
Hallo Matthias,
tr(odd) { background-color: red; }
möchte wohl eher
tr:nth-child(odd) { background-color: green; }
sein, oder gips da eine Kurzschreibweise die ich nicht kenne?
Rolf
Hallo Rolf B,
natürlich.
Nein, die von mir gewählte Schreibweise ist nicht korrekt.
Bis demnächst
Matthias
@@Matthias Apsel
gibt es
tr(odd)
Gibt es? That’s odd. Zu deutsch: Das is’ oll. 😉
LLAP 🖖
danke liebe Läute,
einkleinwenig hab ich gelern,
aber
das Problem ist aber die unflexible Tabelle
nach
<div style="overflow-x:auto; text-align: center;padding-top:0.2em;"
>Produktanalyseliste(Ausschnitt)
</div>
die nach Unterschreitung einer gewissen Fensterbreite den Rahmen sprengt statt in scroll überzugehen.
Hej mathefritz,
einkleinwenig hab ich gelern,
aber das Problem ist aber die unflexible Tabelle
Ja, das ist das Problem von Tabellen.
Dann nimm einfach meinen Vorschlag. 😉
Aber beachte die nachfolgende Diskussion mit @Gunnar Bittersmann, damit es gut wird.
Marc
na schön, hab mal hier etwas gespielt, aber der rechten Rand bleibt verschieden von den anderen Abstänen, egal wie breit man das Fenster macht. Die Abstandbreite mußte ich experimentell auf 0.5% herunternehmen damit es stimmte, obwoht (100 - 4*23)/5 = 1.6 wäre.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="stylesheet" type="text/css" media="screen" href="./Beispiel:SELFHTML-Beispiel-Grundlayout.css" />
<title>Raster-Layout display:table-cell</title>
<style>
body {
margin: 0 auto;
}
div.table {
display: table;
width: 100%;
}
div.spalte {
display: table-cell;
border: thin solid red;
width: 23%;
}
div.dist{display: table-cell; width:2%;}
</style>
</head>
<body>
<h1>Raster-Layout display:table-cell</h1>
<main>
<div class="table">
<div class="dist"> </div>
<div class="spalte">Ich bin eine Spalte.</div>
<div class="dist"> </div>
<div class="spalte">Ich bin eine zweite Spalte.</div>
<div class="dist"> </div>
<div class="spalte">Ich bin eine dritte Spalte mit noch mehr Inhalt.</div>
<div class="dist"> </div>
<div class="spalte">Ich bin eine vierte Spalte.
<br>
<br>
Ein Vorteil von display:table ist, dass sich dass Layout der Spalten automatisch an die Höhe der Spalten anpasst.
</div>
</div>
</main>
</body>
</html>
Die Frage für morgen ist dann, ob man in solche Kästchen statt reienm Text dann auch Tabellen packen kann, die scrollen wenn das Kästchen zu eng wird.
Hej mathefritz,
na schön, hab mal hier etwas gespielt, aber der rechten Rand bleibt verschieden von den anderen Abstänen, egal wie breit man das Fenster macht.
Du hast eine html-Tabelle durch eine css-Tabelle ersetzt. Damit kommst du vom Regen in die Traufe. - in meinem Beispiel habe ich flexboxen verwendet 😉
Marc
Danke Marc,
für Deine viele Arbteit; leider ist das Ergebnis für mich unbefriedigend;
auch mit .vt{justify-content: space-between;} im style
und <section class="vt"> statt nur <section> verwende.
Hier mal die ganze Aufgabenstellung
Eine borderless Box die die ganze Fensterbreite einnimmt,
oberhalb und unterhalb ist auch noch Inhalt,
soll
nebeneinander 3 borderd Boxen mit gleichen Abmessungen enthalten;
deren
Breite mit der Fensterbreite wächst / schrumpft;
ob
die Höhe eine fixe oder durch den Inhalt bestimmte sein soll ist noch offen.
Die
Abständen der Boxen voneinander und den Fensterrändern sollen gleich sein.
Inhalt
der linken und die mittleren Box sind Tabellen, links und recht borderless,
Tabellen-Breite immer mindestens Boxbreite,
soll
mit der Fensterbreite unbegrenzt wachsen,
kann aber
nicht schmaler als die durch die längsten whitespacefreien Zeichenfolgen
in td- und th-Elementen bedingte Mindesbreite werden.
Wenn
die Boxbreite unter dies Mindestbreite sinkt soll scrollen der ganzen Tabelle einsetzten.
Hej mathefritz,
für Deine viele Arbteit; leider ist das Ergebnis für mich unbefriedigend;
Es ist ja auch nicht fertig. Ich mache doch nicht deine Arbeit 😉
Nein im ernst. Du musst das natürlich an Deinen Bedarf anpassen. Den kannte ich ja nicht im Detail Erst mal habe ich Dir gezeigt, wie du drei Spalten ohne Tabelle nebeneinander bekommst.
auch mit
.vt{justify-content: space-between;}im style
und<section class="vt">statt nur <section> verwende.
justify-content gehört an das Container-Element, nicht an die Kinderspace-around wenn du auch einen Abstand zum Browserfenster möchtest.Hier mal die ganze Aufgabenstellung
Eine borderless Box die die ganze Fensterbreite einnimmt,
oberhalb und unterhalb ist auch noch Inhalt,
soll
Diese Box wird zur flexbox. - Falls du Grid nicht möchtest
nebeneinander 3 borderd Boxen mit gleichen Abmessungen enthalten;
deren
Breite mit der Fensterbreite wächst / schrumpft;
ob
Das ist das Standard-Verhalten von Flexboxen: Sie teilen den verfügbaren Platz untereinander auf (in welchem Verhältnis kannst du mittels flex-grow und flex-shrink festlegen).
die Höhe eine fixe oder durch den Inhalt bestimmte sein soll ist noch offen.
Entweder nichts machen oder align-items: flex-start verwenden (wenn die Höhen nicht identisch sein sollen)
Die
Abständen der Boxen voneinander und den Fensterrändern sollen gleich sein.
space-around
Inhalt
der linken und die mittleren Box sind Tabellen, links und recht borderless,
Tabellen-Breite immer mindestens Boxbreite,
soll mit der Fensterbreite unbegrenzt wachsen,
kann aber
nicht schmaler als die durch die längsten whitespacefreien Zeichenfolgen
in td- und th-Elementen bedingte Mindesbreite werden.
Wenn
die Boxbreite unter dies Mindestbreite sinkt soll scrollen der ganzen Tabelle einsetzten.
Die Scrollbalken halte ich für eine sehr schlechte Idee, sofern andere Möglichkeiten bereit stehen. Es geht zwar, aber warum sollte man die Tabellen nicht untereinander darstellen. Dann braucht man viel weniger zu scrollen?!?
Marc
Hallo marctrix, hallo Mathefritz,
wenn man in Marcs CSS diese Änderung durchführt:
// neu
html, body, main { margin:0; padding:0 }
// max-height hinzu
main {
display: flex; max-height: 100vh;
justify-content: space-around;
}
wird das Scrolling mMn besser. Wenn es noch Bereiche ober- und unterhalb des Flexbereichs gibt, muss man die max-height natürlich etwas anders steuern. Dann kommen wir in den Bereich der Flexbox-Lösung, zu der Gunnar bäh sagte 😉
Ich habe zu Mathefritzens Problem aber auch noch mal mit dem Grid gespielt - kann man daraus etwas machen?
Rolf
Hej Rolf,
wenn man in Marcs CSS diese Änderung durchführt:
// neu html, body, main { margin:0; padding:0 } // max-height hinzu main { display: flex; max-height: 100vh; justify-content: space-around; }wird das Scrolling mMn besser.
Ja, da lässt sich noch einiges verbessern.Ich meine auch, an den Container gehört ein flex-wrap: wrap; damit eben kein Scrollbalken kommt, sondern die Tabellen auf kleinen Bildschirmen untereinander stehen.
Aber ich fürchte, da wird mathefritz nicht auf mich hören 😉
Ansonsten sagte ich ja schon, dass ich gerne Tipps zu dem konkreten Problem gebe, aber nicht die komplette Arbeit erledigen werde 😉
Auch habe ich schon gesagt, dass ich inzwischen inline-table den Vorzug geben würde oder alternativ die Tabellen Kinder von main sein könnten. Abhängig davon, ob vielleicht noch mehr in die Kästen soll, beispielsweise eine Beschreibung dessen, was man in der Tabelle findet. Meiner Ansicht nach sinnvoll…
Erst dann benötigt man ein gruppierendes Element wie div oder section…
Wenn es noch Bereiche ober- und unterhalb des Flexbereichs gibt, muss man die max-height natürlich etwas anders steuern. Dann kommen wir in den Bereich der Flexbox-Lösung, zu der Gunnar bäh sagte 😉
Gunnar sagte zu zusätzlichem Markup bäh…
Ich habe zu Mathefritzens Problem aber auch noch mal mit dem Grid gespielt - kann man daraus etwas machen?
Auf jeden Fall. Ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen. Aber dazu hat sich mathefritz ja immer noch nicht geäußert. Ob er überhaupt schon die Rahmenbedingungen für sein Projekt kennt? 😉
Marc
@@marctrix
[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.
Welche alten Browser sollen das sein?
Wenn mangelnde Unterstützung ein Problem sein sollte, dann sind es aktuelle Browser wie UC und Samsung-Browser.
LLAP 🖖
Hej Gunnar,
@@marctrix
[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.
Welche alten Browser sollen das sein?
Die wurden im Thread schon benannt.
Wenn mangelnde Unterstützung ein Problem sein sollte, dann sind es aktuelle Browser wie UC und Samsung-Browser.
Wie du schon mehrfach angemerkt hast, sollten auf so kleinen Bildschirmen die Boxen untereinander stehen. Insofern hätten die Nutzer dieser Browser sogar das Glück, dass mathefritzens horizontale Scrollorgie entschärft würde… 😉
Aber klar, grundsätzlich sind die das Problem!
Marc
@@marctrix
[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.
Welche alten Browser sollen das sein?
Die wurden im Thread schon benannt.
Nested-Ansicht, cmd-F grid – ich finde keine. Wonach muss ich suchen?
LLAP 🖖
Hej Gunnar,
@@marctrix
[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.
Welche alten Browser sollen das sein?
Die wurden im Thread schon benannt.
Nested-Ansicht, cmd-F
grid– ich finde keine. Wonach muss ich suchen?
Hätte gedacht "ie10" habe ich aber nicht gefunden. Dann war es wohl ein anderer Thread. Sorry. Aber wozu? Weißt du doch selbst, welche Browser grid können!
Marc
@@marctrix
Hätte gedacht "ie10" habe ich aber nicht gefunden. Dann war es wohl ein anderer Thread. Sorry. Aber wozu? Weißt du doch selbst, welche Browser grid können!
Ja. IE 10 bspw. kann es.
LLAP 🖖
Hej Gunnar,
@@marctrix
Hätte gedacht "ie10" habe ich aber nicht gefunden. Dann war es wohl ein anderer Thread. Sorry. Aber wozu? Weißt du doch selbst, welche Browser grid können!
Ja. IE 10 bspw. kann es.
Also warum fragst du?
Marc
@@marctrix
Hätte gedacht "ie10" habe ich aber nicht gefunden. Dann war es wohl ein anderer Thread. Sorry. Aber wozu? Weißt du doch selbst, welche Browser grid können!
Ja. IE 10 bspw. kann es.
Also warum fragst du?
Weil ich von dir wissen wollte, welche alten (aber noch relevanten) Browser Grid nicht können. Du hattest gemeint, es gäbe solche.
LLAP 🖖
Hallo Gunnar,
für den IE muss man aber Spezial-CSS schreiben, gelle? Also alles voller -ms Geraffel.
Rolf
Hej Rolf,
für den IE muss man aber Spezial-CSS schreiben, gelle? Also alles voller -ms Geraffel.
Ja, auch für die Edge-Versionen bis einschließlich 15.
Aber der können vieles nicht und die Eigenschaften heißen auch ganz anders. Mit -ms- davor setzen ist es leider nicht getan
Marc
Hallo Rolf,
für den IE muss man aber Spezial-CSS schreiben, gelle? Also alles voller -ms Geraffel.
Dafür gibt es Autoprefixer.
LG,
CK
Hej Christian,
für den IE muss man aber Spezial-CSS schreiben, gelle? Also alles voller -ms Geraffel.
Dafür gibt es Autoprefixer.
Und wer macht das dann wieder raus? — Klar, der Autoprefixer. Wenn man ihn denn noch mal an eine fertige Seite lässt. Besser gesagt: regelmäßig.
Ich weise darauf hin, weil es noch die eine oder andere Seite im Web gibt, wo heute (und vermutlich bis in alle Ewigkeit) nicht mehr nötigen Vendor-Prefixe drin stehen…
Marc
Hallo marctrix,
für den IE muss man aber Spezial-CSS schreiben, gelle? Also alles voller -ms Geraffel.
Dafür gibt es Autoprefixer.
Und wer macht das dann wieder raus? — Klar, der Autoprefixer. Wenn man ihn denn noch mal an eine fertige Seite lässt. Besser gesagt: regelmäßig.
Das ist halt eh notwendig. shrug Eine Website machen und 20 Jahre nicht anfassen geht halt nicht, wenn man bleeding edge einsetzen will.
LG,
CK
Hej Christian,
für den IE muss man aber Spezial-CSS schreiben, gelle? Also alles voller -ms Geraffel.
Dafür gibt es Autoprefixer.
Und wer macht das dann wieder raus? — Klar, der Autoprefixer. Wenn man ihn denn noch mal an eine fertige Seite lässt. Besser gesagt: regelmäßig.
Das ist halt eh notwendig. shrug Eine Website machen und 20 Jahre nicht anfassen geht halt nicht, wenn man bleeding edge einsetzen will.
Oder muss. Aber oft glaubt man auch nur zu müssen. 😉
Marc
Hej Gunnar,
@@marctrix
Weil ich von dir wissen wollte, welche alten (aber noch relevanten) Browser Grid nicht können. Du hattest gemeint, es gäbe solche.
Vielleicht habe ich das geschrieben, aber auf keinen Fall gemeint.
Wo war das denn?
Marc
PS: Was bist du denn so garstig in letzter Zeit?
@@marctrix
Weil ich von dir wissen wollte, welche alten (aber noch relevanten) Browser Grid nicht können. Du hattest gemeint, es gäbe solche.
Vielleicht habe ich das geschrieben, aber auf keinen Fall gemeint.
Wo war das denn?
Hier: „[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.“
PS: Was bist du denn so garstig in letzter Zeit?
Was heißt hier „in letzter Zeit“? Schon immer! 😈
LLAP 🖖
Hej Gunnar,
@@Gunnar Bittersmann
Weil ich von dir wissen wollte, welche alten (aber noch relevanten) Browser Grid nicht können. Du hattest gemeint, es gäbe solche.
Vielleicht habe ich das geschrieben, aber auf keinen Fall gemeint.
Wo war das denn?
Hier: „[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.“
Also ich lese da nichts von relevant… — hätte mich auch gewundert. Obwohl ich ja manchmal auch Unsinn schreibe.
Welche Browser zu unterstützen sind, muss der Autor wissen. Bei mir sind das oft noch ziemlich alte und die können nur teilweise CSS-Grid. Aber das hätten wir doch schon?!?
PS: Was bist du denn so garstig in letzter Zeit?
Was heißt hier „in letzter Zeit“? Schon immer! 😈
😀
Was ich meine ist: es kommt doch gar nicht drauf an, ob ich das wirklich gesagt habe. Schreib doch einfach deine Sicht der Dinge. Es geht doch nicht darum jemanden nachzuweisen, dass er sich vertan hat.
Über mehrere Postings hinweg auch noch. Wenn ich Quatsch schreibe, ist es vollkommen richtig, dass das korrigiert wird.
Und meine Aussage da oben ist doch auch vollkommen in Ordnung. Bei den Problemen, die ich gerne mit CSS-Grid lösen würde, muss ich auf flexbox zurückgreifen, weil IE10 bis Edge 15 eben nur einen Teil vom aktuellen Grid-Standard können. Und das auch noch mit alter Schreibweise. Finde ich persönlich ziemlich unbefriedigend. Aber wenn der eingeschränkte Funktionsumfang reicht und Browser älter als ie10 nicht unterstützt werden müssen, dann kann Grid verwendet werden. Diese Einschränkungen sind aber wichtig genug, um genannt zu werden, finde ich.
Marc
@@marctrix
Hier: „[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.“
Also ich lese da nichts von relevant…
Ja, das habe ich da reingedeutet. Oder besser gesagt: das stand für mich implizit drin. Warum sollte man irrelevante Browser unterstützen wollen?
Bei den Problemen, die ich gerne mit CSS-Grid lösen würde, muss ich auf flexbox zurückgreifen, weil IE10 bis Edge 15 eben nur einen Teil vom aktuellen Grid-Standard können.
Und genau den Teil, den IE/Edge noch nicht können, kann man mit Flexbox lösen? Wenn ja, dann macht man das halt so. Oder man macht einen Fallback mit Floats – geht dann sogar in Browsern, die Flexbox nicht können. Aber welche relevanten sollten das sein?
LLAP 🖖
Hej Gunnar,
@@marctrix
Hier: „[Grid] ist sogar noch besser als flex, nur nicht, wenn alte Browser unterstützt werden sollen.“
Also ich lese da nichts von relevant…
Ja, das habe ich da reingedeutet. Oder besser gesagt: das stand für mich implizit drin. Warum sollte man irrelevante Browser unterstützen wollen?
Auch diese Frage kannst du dir selbst beantworten: Man wird irrelevante Browser nicht unterstützen wollen.
Ich hätte anders formulieren oder den Hinweis ganz weg lassen können, wenn ich das Projekt kennen würde. Tu ich aber nicht. Relevanz ist immer projektabhängig.
Wir hatten das Thema schon, auch die Tatsache, das ich aus einer Behörde komme, die Lösungen für andere Behörden bereit stellt, auf dessen Browser-Vorgaben wir keine Auswahl haben und die mitunter lange brauchen zum updaten.
Vielleicht bin ich darum in der Hinsicht etwas sensibler.
Aber wir hatten auch den Hinweis (von @Christian Kruse glaube ich?), dass ein Kunde aus der freien Wirtschaft gerade auf IE9 geupdatet hat…
Bei den Problemen, die ich gerne mit CSS-Grid lösen würde, muss ich auf flexbox zurückgreifen, weil IE10 bis Edge 15 eben nur einen Teil vom aktuellen Grid-Standard können.
Und genau den Teil, den IE/Edge noch nicht können, kann man mit Flexbox lösen?
Ja und auch ein Beispiel dafür haben wir hier im Forum besprochen.
Die Browser, die das verstehen, aber kein CSS-Grid, sind IE10 bis Edge (aktuelle Version).
Im Gegensatz zu deinen Vorschlägen (float oder inline-block) kann ich mit flexbox das gesamte Elternelement ausfüllen und eine vernünftige Darstellung auf Smartphones ohne media-queries bereitstellen.
Marc
Danke.
Das justify-content: space-around hab ich hier probiert aber der Abstand von den container-Rändern, links, rechts,
ist veschieden von denen zwischen den items
Hej mathefritz,
Danke. Das
justify-content: space-aroundhab ich hier probiert aber der Abstand von den container-Rändern, links, rechts, ist veschieden von denen zwischen den items
Wir müssen hier echt mal eine Pause machen.
Das nebeneinanderstellen von Tabellen, die nicht auf den Bildschirm passen, macht doch gar keinen mir erkenntlichen Sinn. Wozu ist das gut? Ist das wirklich nötig?
Welche Browser sollen denn unterstützt werden?
Wenn die beiden Fragen geklärt sind, können wir uns für die zu verwendende Technik entscheiden, was vermutlich CSS-Grid sein wird, dann brauchen wir die flex-Lösung nicht weiter zu diskutieren.
Die liegt nur wegen der breiten Browser-Unterstützung auf dem virtuellen Tisch…
Marc
@@mathefritz
… der Umfassenden einzeiligen Tabelle …
Es gibt keine einzeiligen Tabellen.
Der umfassende Container ist keine Tabelle; das table-Element dafür also falsch. Der umfassende Container ist ein Gestell.
Um mehrere Tabellen nebeneinander darzustellen, gibt es verschiedene Möglichkeiten:
display: inline-tableLLAP 🖖
Hej Gunnar,
@@mathefritz
Um mehrere Tabellen nebeneinander darzustellen, gibt es verschiedene Möglichkeiten:
display: inline-table
Oh verflixt. Das ist natürlich besser, wenn du nichts gruppieren willst, es also bei den Tabellen bleibt und diese keine Überschriften und begleitenden Texte erhalten.
Nur könnten die auf sehr breiten Bildschirmen vielleicht zu schmal sein. Dann musst du mit breitenangaben nachhelfen.
Smartphones nicht vergessen!
Achtenquf eine lesbare Darstellung bei kleinen Bildschirmen…
Marc