Der rote Kreis ist rund stehend oval und liegend oval je nach Betriebssystem

[Günter]

Ein frohes Jahr euch allen! Ich bin dabei, die als problematische Seite genannte zu entwickeln und habe folgendes Problem: Unter jedem Bild ist ein Button platziert, dem ich einen Border und eine Hintergrundfarbe gegeben habe. Meine Erwartung ist einen runden roten Kreis zu sehen in dem ein eingekreistes "I" zu sehen ist. Der Kreis ist zu sehen unter Windows 11 und Ubuntu bei allen Browsern mit denen ich getestet habe. Die gleichen Browser zeigen jedoch unter iOS ein liegendes Oval und unter Android ein stehendes Oval. Ist das ein bekanntes Problem? Mir fehlt jede Idee, an welcher Schraube ich drehen muss, um überall den roten Kreis zu sehen. Bin dankbar für jeden Tipp. Mit freundlichem Gruß Günter

[Matthias Scharwies]

Servus!

Ein frohes Jahr euch allen! Ich bin dabei, die als problematische Seite genannte zu entwickeln und habe folgendes Problem: Unter jedem Bild ist ein Button platziert, dem ich einen Border und eine Hintergrundfarbe gegeben habe. Meine Erwartung ist einen runden roten Kreis zu sehen in dem ein eingekreistes "I" zu sehen ist.

Danke für Dein Online-Beispiel.

Ich habe FF121 unter Windows 11 und sehe auch ein Oval!

#t_b {
  font-size: 1.5em;
  color: #000;
  text-align: right;
  vertical-align: top;
  margin-left: 8em;
  border: outset 6px;
    border-top-color: currentcolor;
    border-right-color: currentcolor;
    border-bottom-color: currentcolor;
    border-left-color: currentcolor;
  border-radius: 2em;
  border-color: transparent;
  cursor: pointer;
  background: #f00;
}

Du hast keine Größenangabe, deshalb stellt es jeder Browser ein bisschen anders dar.

Mein Vorschlag:

button {
  width: 1em;
  aspect-ratio: 1;
 border-radius: 50%;
}

Setze eine Breite! Das Seitenverhältnis und auch der border-radius wachsen dann bei einer späteren Änderung mit.

In einem runden Button würde ich den Inhalt zentrieren, nicht oben und rechts positionieren.

Achtung

Du solltest an der Grundstruktur der Seite (Tabellen-Layout, Navigation mit select und option, etc) arbeten. Das entspricht nicht dem Standard.

Überprüfe Deine Seite mal im Validator!

Herzliche Grüße

Matthias Scharwies

[Felix Riesterer]

Lieber Matthias,

Achtung

Du solltest an der Grundstruktur der Seite (Tabellen-Layout, Navigation mit select und option, etc) arbeten. Das entspricht nicht dem Standard.

hast Du nicht gesehen, dass hier mit Grid gearbeitet wurde? Zugegeben, die Bilder-Boxen möchten <figure>-Elemente werden, damit keine noch so kleinen Layout-Tabellchen mehr übrig bleiben.

Überprüfe Deine Seite mal im Validator!

Naja, nur 795 Meldungen, darunter einige Warnings und viele der Fehlermeldungen wegen mehrfach verwendeter ID-Namen.

Liebe Grüße

Felix Riesterer

[Felix Riesterer]

Lieber Günter,

in Ergänzung zu Matthias' Hinweisen auf technische Fehler in Deinem HTML: Eine ID muss ohne Ausnahme in diesem Dokument einmalig sein! Deine ID für den Button kommt bei jedem Button vor und verstößt damit gegen diese Vorschrift. Wenn Du alle Buttons so gestalten willst, dann verwende als Selektor den Tagnamen (button), oder gib jedem der Buttons eine entsprechende Klasse.

Deine Seite passt nicht in meinen Browser! Ich sehe nur einen Teil links, der Rest nach rechts wandert in einen unsichtbaren Bereich. Wenn ich mit der Maus darüber fahre, sehe ich, dass man da seitlich scrollen könnte. Das ist sehr umständliche Bedienung und verleitet vor allem das jüngere Publikum dazu, Deine Seite fluchtartig zu verlassen. In der mobilen Ansicht kann ich durch Wischen das seitliche Scrollen vielleicht leichter bedienen, aber einen sichtbaren Hinweis, dass das eine gegebene Funktionalität ist, sehe ich auch keinen.

Die Schrift auf dem Desktop ist mir zu groß, in der mobilen Ansicht empfinde ich sie als zu klein.

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

er styled den Scrollbar per -webkit Eigenschaften und hat dabei das # vor den RGB-Farben vergessen, deshalb siehst Du ihn nicht. Das ist lösbar.

Auf meinem Desktop ist die Schrift ebenfalls zu riesig. Warum sie mobil kleiner ist, hm, die Viewport-Metaangabe ist da, die font-size ist korrekt im em angegeben. Auf meinem Handy empfinde ich sie auch nicht zu klein. Merkwürdig…

Argh. ARGH! HAAAAA!!!

<meta name="viewport" main="width=device-width, initial-scale=1.0">

Welch ein heimtückischer Fehler! Seht ihr das frisch gepresste Schlangenöl?! Ich habe eine halbe Stunde gebraucht, mein Browser aber nur 0.5 Sekunden und sagt: pfft, 960px Emulation herbei. @media (min-width:30em)? Klaaaar, immer doch.

Möglicherweise hat Günter die großen Schriften eingesetzt, damit auf einem Mobilgerät überhaupt etwas lesbar ist. Aber leider muss die Seite für die Darstellung auf Mobilgeräten nochmal komplett überarbeitet werden. Die Kompatibilitätsdarstellung des Browsers hilft ein wenig, aber nicht so richtig.

Richtig ist übrigens:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Wenn ich das per USB-Debugging in mein Handy injiziere, fliegt das Layout komplett auseinander.

Rolf

[Günter]

Hallo Rolf, Danke!

Ich habe also keine Langeweile vor mir 😉

Viele Grüße

Günter

[Günter]

Lieber Felix,lieber Matthias,

vielen Dank für eure Analyse! Das mit den IDs werde ich überarbeiten und das css für den Button anpassen. "figure", da muss ich mich mal einlesen.

Die Seite ist zu groß? Na ja, vielleicht ist das Geschmackssache. Gerade bei jüngeren Testerinnen habe ich "cool" zurückbekommen, mit dem Wischen zur Seite. Aber es stimmt auch, dass es schwer zu erkennen ist, unter Android sieht man bei verschiedenen Versionen und Geräten dass es nach Rechts weiter geht und unter iOS leider nicht. Das ist tatsächlich auch noch ein offener Punkt...

Mit euren Hinweisen werde ich aber schon mal weiter kommen.

Viele Grüße Günter

[Gunnar Bittersmann]

@@Günter

Die Seite ist zu groß?

Die Schrift ist zu groß, ja. Und muss es Helvetica sein oder nicht doch besser eine Schriftart mit Charakter?

Gerade bei jüngeren Testerinnen habe ich "cool" zurückbekommen, mit dem Wischen zur Seite.

Nicht alle Nutzer können wischen.

Das mit einzeiliger Leiste und horizontalem Scrollen kann man machen, wenn visualisiert wird, dass man da horizontal scrollen kann. Da könnte es genügen, wenn die nächste Card angeschnitten ist. Besser aber Pfeile ←/→, die dann auch anclickbare Buttons sind. Wie scrollt man sonst bei Tastaturbedienung?

Ich habe vor nicht allzu langer Zeit eine solche Komponente gebaut und darüber erzählt, wie sie funktioniert: TIL how to make another kind of carousel. Das sollte anhand der dort verlinkten Codepens 1️⃣ bis 5️⃣ einigermaßen nachvollziehbar sein.

Das kann man live in action auf allen Tagesspiegel-Seiten auf breiten Viewports im Hauptmenü sehen; auf schmalen Viewports im Kalender im Archiv.

Kwakoni Yiquan

[Günter]

Hallo Gunnar,

Danke für dein Beispiel, da kann ich was lernen.

Viele Grüße Günter

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Das kann man live in action auf allen Tagesspiegel-Seiten auf breiten Viewports im Hauptmenü sehen; auf schmalen Viewports im Kalender im Archiv.

… und auf Artikelseiten ganz unten.

Kwakoni Yiquan

[Rolf B]

Hallo Günter,

die Buttons bekommst Du rund, so wie Matthias es schrieb.

Problem ist die Ausrichtung des eingekreisten i im Button. Du kannst zwar mit der font-size spielen, bis es auf deinem Gerät gut aussieht, aber Du hast keine Garantie, dass es auf einem anderen Gerät passt.

Eine horizontale Zentrierung im Button bekämest Du mit text-align:center hin. Ist aber eigentlich nicht nötig, ein Verzicht auf width und etwas padding führt automatisch zu einer horizontalen Zentrierung. Durch aspect-ratio:1/1; wird Dir ein quadratischer Button garantiert.

Eine vertikale Zentrierung ist hingegen nicht so einfach. Das Zeichen &#x24D8 liefert Dir zwar das ⓘ, aber dieses Zeichen scheint mir nicht in den Grenzen des Schriftrahmens zentriert. Deshalb ist das ⓘ zu tief. Ich würde Dir eher raten, eine SVG Grafik zu erzeugen und diese im Button darzustellen.

Aber selbst wenn das ⓘ taugen würde - die vertical-align Eigenschaft dient nicht dazu, Text in einem Button vertikal zu zentrieren. Das ist etwas, was nur in td und th Elementen funktioniert und ist eigentlich eine Altlast. vertical-align richtet die Textbasislinie des Elements in Bezug auf die Textbasislinie seines Umfeldes aus.

Wenn das Zeichen taugen täte, dann könnte man den Button zur Flexbox machen und mit align-items:center den Text vertikal zentrieren. Aber es taugt nicht.

Speichere Dir dieses Snippet als "info.svg":

<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 200 200' width='50' height='50'>
  <circle cx='100' cy='100' r='60' fill='none' stroke='black' stroke-width='8' />
  <rect x='94' y='65' width='12' height='12' fill='black' stroke='none' />
  <line x1='100' y1='90' x2='100' y2='140' stroke='black' stroke-width='12' />
</svg>

Das ist ein schwarzes i in einem schwarzen Kreis, das im SVG zentriert ist. Eine Hintergrundfarbe gibt's nicht. Die intrinsische Größe ist auf 50x50 gesetzt, die ist aber eigentlich wurscht. Dieses SVG kannst Du dem Button zusammen mit einer roten Grundlage als Hintergrundgrafik geben:

.info-button {
button {
   width: 3em;
   aspect-ratio: 1/1;
   border: none;
   border-radius:50%;
   margin: 0;
   padding: 0;
   background: url("images/info.svg"), red;   /* Oder wo auch immer Du Icons ablegen willst */
   background-size: 100%;
}

Dadurch hast Du einen rot hinterlegten Button und vor dem roten Hintergrund das eingekreiste i. Es gibt auch andere Möglichkeiten für SVG Icons, dazu gibts einen Artikel über SVG-Icons im Selfwiki.

Dem Button sind alle visuellen Standardfeatures entzogen, außer einem: Ein Fokusrahmen, wenn man mit der Tab-Taste dorthin navigiert. Und so soll's sein. Du könntest jetzt noch per :hover eine Reaktion auf's Mäuslein herbeiführen.

Die Gruppe aus Bild mit Jahresangabe und Button sollte, wie Felix schrub, eine Figure-Gruppe sein.

<figure>
  <img src="./Reeperbahn/Schwalbe13.jpg" alt="Reeperbahn, Bordsteinschwalbe">
  <figcaption>
    <span><b>Jahr:</b> 2017</span>
    <button class="info-button"><snap class="visually-hidden">Info</span></button>
  </figcaption>
</figure>

Dass der Alt-Text nicht nur sagt "Bild zur Reeperbahn", sondern den Inhalt aussagekräftig beschreibt, ist für die Zugänglichkeit wichtig. Das gleiche gilt für den visuell versteckten Text im Button. Wie eine Klasse zum visuellen Verstecken aussehen kann, findest Du im Selfhtml Wiki im Bereich Navigation.

Eine figure hat per Default noch störenden margin, den musst Du wegschmeißen. Die Card-Breite setzt Du in Form der figure-Breite. In der h2-Überschrift nimmst Du die Unterstriche weg, die skalieren ganz schlecht und dafür gibt's die bessere Alternative text-decoration:underline oder ein border-bottom.

Die figcaption machst Du zur Flexbox:

.card figcaption {
   display: flex;
   justify-content: space-between;
   align-items: center;
}

Wenn Jahr und Jahreszahl in einem span stehen, hast Du damit automatisch Jahresangabe und Button am linken und rechten Rand.

Auf die Klasse "info-button" kannst Du auch verzichten, du musst den Button im CSS dann geeignet selektieren. Z.B so:

.card figcaption button {
   ...
}

Nächster Punkt: Frei erfundene HTML Elemente. Die Elemente main, section und article haben spezielle Semantik, die für die Dokumentgliederung wichtig ist (das ist wieder mal was für die Zugänglichkeit). Wenn Du die durchnummerierst (main1, main2, ...), hast Du unbekannt Elemente, die keinerlei Semantik haben. Das solltest Du nicht tun.

• Es gibt genau ein main-Element
• Einen Dokumentenbereich wie main, section, article, header oder footer kann man in sections einteilen, muss aber nicht. Man kann einen Bereich auch in arcticles einteilen, muss aber nicht. In deinem Fall würde ich empfehlen, die Scrollcontainer als <section> darzustellen und die Cards als <article>. Aber immer diese Elemente, nicht die Tags durchnummerieren. Wenn Du eine Möglichkeit brauchst, gezieht einzelne Elemente anzusprechen, gib ihnen eine eindeutige ID.

Dein Grid: Du hast im scrolling-wrapper grid-template-areas definiert. Aber Du verwendest diese Namen nicht. Dann kannst Du diese Eigenschaft auch weglassen. Verwendet werden diese Namen in der grid-area Eigenschaft eines Grid-Items (bei dir also: einer card). Ich sehe dafür allerdings keine Notwendigkeit. Die IDs, die Du den cards gegeben hast, interagieren mit den Area-Namen in grid-template-areas nicht. Vermutlich ist dieses horiontale Scroll-Dings auch viel einfacher lösbar, wenn man die figures mit display:inline-block versieht und den Scroll-Container mit white-space:pre vor Umbrüchen schützt.

So, genug Dreck geschmissen. Du hast schöne Fotos im Portfolio!

Rolf

[Günter]

Lieber Rolf,

mit solchem Dreck darfst du gerne schmeißen. Vielen Dank für deine Mühe!

Danke auch für deine Hinweise zu dem eingekreisten i, da hatte ich schon gedacht, dass akzeptiere ich so ein wenig verschoben, aber deine Lösung ist besser.

Danke auch für das Feedback zu den Bildern.

Viele Grüße Günter

[Günter]

Lieber Rolf,

Dass der Alt-Text nicht nur sagt "Bild zur Reeperbahn", sondern den Inhalt aussagekräftig beschreibt, ist für die Zugänglichkeit wichtig.

Ja, das verstehe ich. Nun habe ich zu den Bildern jeweils nur ein paar Worte zur Beschreibung und da dachte ich, dass eine Aufteilung ein Teil im Alt-Text und der Rest unter dem Bild. Würde das nicht zusammen vorgelesen werden? Würde anders herum der Text nicht zweimal vorgelesen werden, wenn ich den gesamten Text im Alt-Text unterbringe und unter dem Bild?

Viele Grüße Günter

[Rolf B]

Hallo Günter,

einfache Antwort: kommt drauf an…

Die HTML Spec gibt sich eine Menge Mühe, die Anforderungen für Bild-Ersatztexte an Fallbeispielen zu erklären.

Kurz formuliert: Der alt-Text soll erklären, was ein Sehender auf dem Bild wahrnimmt. Die figcaption dazu gibt Informationen, die Sehende UND Blinde bekommen.

Ein Foto von der Elbphilharmonie wie dieses könnte als Alt-Text etwas bekommen wie "Die Elbphilharmonie vom Wasser aus gesehen, vor dunklem Nachthimmel. Strahler vor dem Gebäude und auf dem Besucherrundgang erzeugen einen blauen Lichterkranz". Die Figcaption kann "Lichtspektakel an der Elbphilharmonie bei ihrer Eröffnung" sein.

Die Wikipedia (hier) macht es ganz schlecht: sie verlassen sich nur auf die figcaption und lassen das alt-Attribut ganz weg.

Es gibt auch andere Fälle, wo als alt-Text ein Wort genügt, sofern das Umfeld hinreichend erklärt, was das Bild zeigt.

Rolf

[Günter]

Hallo Rolf, vielen Dank, deine Tipps (und die von Matthias auch) bekomme ich gut umgesetzt und es wird funktionieren, jedoch mit

Die Card-Breite setzt Du in Form der figure-Breite. In der h2-Überschrift nimmst Du die Unterstriche weg, die skalieren ganz schlecht und dafür gibt's die bessere Alternative text-decoration:underline oder ein border-bottom.

habe ich meine Probleme. Wenn ich in der h2-Überschrift die Unterstriche wegnehme, dann wird die Breite der Card von dem Bild bestimmt. Das führt zu einem Mecker bei meiner sehbehinderten Freundin, der dann die Bilder zu klein sind. Deshalb hatte ich bisher mit diesen Unterstrichen gearbeitet und damit eine größere Breite der Card erzwungen (Deshalb sind am Desktop die Bilder auch so groß). Damit skalierten dann die Bilder ebenfalls und wurden entsprechend größer.

Wie kann ich die Breite einer Card sonst beeinflussen? "figure-Breite" verstehe ich nicht, deren Breite wird doch auch über deren Content bestimmt. Jedenfalls nützt ein "width=100%" für figure erwartungsgemäß nichts.

Viele Grüße Günter

[Günter]

Hallo Günter,

das Problem ist gelöst. Die Überschrift bekommt ein margin-left und margin-right und schon breitet sich das Teil aus.

Danke!

Gruß Günter

[Rolf B]

Hallo Günter,

sorry, dass ich jetzt länger keine Zeit zum antworten hatte.

Nein. Die Breite muss aus den .card divs kommen. Diese divs könnten - meine ich - auch gerne article Elemente sein, und deine scrolling-wrapper könnten section Elemente sein. Das scheint mir semantisch am passendsten. Ich würde das so machen:

(1) Entferne aus der Regel für .scrolling-wrapper die drei grid-Eigenschaften. Verwende statt dessen

.scrolling-wrapper {
  display:flex;
  gap: 1em;
  ...
}

(2) Entferne in der Monsterregel die Liste aller IDs. Die Elemente mit diesen IDs sind alles Cards, und mir scheint, als würden diese IDs nirgends verwendet als in dieser Regel. Alle Cards haben aber auch die .card Klasse, also kannst Du das, was da drin steht, auch in die .card Regel übertragen. Ergänze für die .card Regel dann noch flex: 0 0 17em; - oder so, die 17em sind die Basisbreite ("flex-basis") für die Flexitems der Flexbox, zu der Schritt 1 den Scrolling-Wrapper gemacht hat. Die beiden Nullen (flex-grow und flex-shrink) bewirken, dass die Elemente diese Basisbreite auch behalten, wenn die Flexbox breiter oder schmaler ist als die Summe der Breiten ihrer Kinder.

Also:

.card {
    border-radius: 1em;    /* einmal 1em reicht, das gilt für alle Ecken */
    border: 5px outset;
    padding: 0.5em;
    background: #dddd00;
}

display:inline-block ist in einer Flexbox unnötig (im Grid auch), und der Margin wird durch die gap-Angabe im scrolling-wrapper ersetzt.

(3) Entferne aus den h2 die Unterstriche. Gib den h2 ein border-bottom: 2px solid black und ein text-align: center. Oder hast Du andere Vorstellungen von der Unterstreichung?

(4) Es scheint, als wolltest Du die Bilder und die Jahresangabe etwas schmaler haben als den Text darunter. Dazu hatte ich ja schon figure und figcaption erwähnt, das figure-Element kann ein Padding bekommen, womit die Bilder und die Caption darunter etwas schmaler werden.

Hast Du deine Änderungen schon in einer Testgalerie online? Vermutlich müsste man da iterativ noch weiter drüber…

Rolf

[Günter]

Hallo Rolf,

so schnell bin ich nicht…

Einiges habe ich schon übernommen, jedenfalls in Ansätzen. Es sind ja aber über 700 Meldungen😀

figure und figcaption habe ich als Ersatz für die Tabellen übernommen, die Überschriften haben keine Unterstreichungen mehr, es gibt einen sichtbaren Scrollbalken am Notebook, aus IDs wurden Klassen. Gunnars Beispiel muss ich noch erschließen und deine tollen Hinweise muss ich erst mal alle verkraften. Was der Validator dann noch alles bemerkt.

Super, wie du dich da engagierst, es wird jedoch dauern, bis ich eine neue Version vorzeigen kann. Ich kann nur nebenbei an der Seite arbeiten. Also musst Du dich bitte noch gedulden.

Danke für deine Hilfsbereitschaft.

Viele Grüße Günter

[Günter]

Guten Tag,

jetzt habe ich fast alle Anregungen von euch umgesetzt (es fehlt noch das Blättern nach rechts und links per Pfeil). Das habe ich noch aufgespart, weil ich ein Problem mit der Breite der Seite in Chrome habe. Dort wächst die Seite in der Breite stetig an, mit jedem Eintrag mehr. Im Firefox dagegen nicht, dort hat die Seite eine (sichtbare) Breite von 100vw.

Der Validator ist mittlerweile recht zufrieden mit der Seite nur noch eine Warnung und ein Fehler (den ich aber nicht verstehe, jedoch das Gefühl habe, ihn ignorieren zu dürfen?).

Wenn ihr mir bitte einen Tipp geben könntet, worin das Problem mit der angezeigten Seitenbreite unter Chrome liegt. Danke für eure Hilfe, die hat mich weiter gebracht!

[Rolf B]

Hallo Günter,

möglicherweise hast Du altes CSS im Cache, bei mir wächst die Seite nicht beliebig an. Sie ist lediglich eine Prise zu breit. Lösch mal den Cache (Strg+F5 im Browser oder "Cache deaktivieren" auf dem Netzwerk-Tab der Entwickerwerkzeuge).

Die "Prise" Überbreite liegt an deiner Breitenkontrolle, die unnötig viel tut und sich mit dem Scrollbars beißt. 100vw ist - leider - das ganze Fenster und nicht Fenster minus Scrollbar. Um "Fensterbreite minus Scrollbar" zu bekommen, muss man dem Browser die Breitenkontrolle überlassen, weil Dir keiner garantiert, dass ein Scrollbar immer 17px breit ist. CSS entwickelt sich da gerade (scrollbar-gutter, scrollbar-width), das ist aber noch sehr neu.

Damit sich der body dann nicht beliebig ausdehnt, muss man bei den darinliegenden Elementen dafür sorgen, dass ihre Breite kontrolliert ist. Das ist bei Dir der Fall, dein Body ist ein Grid und das, was richtig breit werden kann, scrollt automatisch horizontal.

• Entferne vom body das width:100vw und ersetze es durch (beispielsweise) max-width:100em. Damit ist der Body so breit wie das Fenster minus Breite des Scrollbars. Und maximal 100em. Ob die 100em für Dich passen, musst Du Dir anschauen. Zusammen mit dem margin:0.5em auto passt damit die Body-Ausrichtung.
• Gib dem Body ein padding: 0 0.5em; und ein box-sizing: border-box. Ohne box-sizing würde das padding den Body zu breit machen. Das Padding macht Links/Rechts Margins für die Grid-Items des Body unnötig.
• Gib dem Body auch noch gap:0.5em (Abstand zwischen Grid-Items). Damit entfallen auch Top/Bottom Margins für die Hauptelemente der Seite.
• Entferne aus der header, nav, main, section, aside, footer-Regel die margin-Angabe.
• Entferne die width-Angabe für article, das ist ein Grid-Item, deshalb soll das Grid auch die Breite kontrollieren
• Dito für .scrolling-wrapper. Das ist ein Blockelement, das per Default so breit ist wie sein Elternelement (der article). Durch overflow-x:auto entsteht ein Scrollbar, wenn sein Inhalt zu breit wird, und er guckt definitiv nicht über die article-breite hinaus.
• Die grid-template-areas im scrolling-wrapper können weg, das schrieb ich Dir schon. Auf die beziehst Du Dich nicht. Ob grid-template-columns: repeat(24,1fr) richtig ist, bezweifle ich auch. Hier sollten Auto-Columns verwendet werden. Bzw. das ganze Grid könnte auch eine Flexbox sein, das Layout ist ja nur eindimensional.

Mit diesen Änderungen sollte schon mal nichts mehr rechts in den Scrollbar hineinragen. Und die überbreiten Scroll-Wrapper - ja, wie gesagt, möglicherweise Caching.

Rolf

[Gunnar Bittersmann]

@@Rolf B

CSS entwickelt sich da gerade (scrollbar-gutter, scrollbar-width), das ist aber noch sehr neu.

?? Das hatten wir doch gerade erst! Zwei Jahre sind bei CSS alles andere als „noch sehr neu“.

• Entferne vom body das width:100vw und ersetze es durch (beispielsweise) max-width:100em.

?? Warum nicht 100%? Oder – da default – gar keine Angabe?

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

scrollbar-gutter braucht beim Safari immer noch eine Aktivierung durch den User. Aus meiner Sicht ist es damit noch nicht generell einsetzbar, sondern noch dabei, sich zu verbreiten.

Was hat du auf einmal gegen max-width? Bei anderen Serien wolltest du es haben.

Rolf

[Gunnar Bittersmann]

@@Rolf B

scrollbar-gutter braucht beim Safari immer noch eine Aktivierung durch den User. Aus meiner Sicht ist es damit noch nicht generell einsetzbar, sondern noch dabei, sich zu verbreiten.

Es ist schon generell einsetzbar, denn man braucht das Feature in Safari nicht.

Was hat du auf einmal gegen max-width?

Nichts. Aber warum nicht in %?

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Gunnar Bittersmann

scrollbar-gutter braucht beim Safari immer noch eine Aktivierung durch den User. Aus meiner Sicht ist es damit noch nicht generell einsetzbar, sondern noch dabei, sich zu verbreiten.

Es ist schon generell einsetzbar, denn man braucht das Feature in Safari nicht.

Und selbst wenn, wäre es schon generell einsetzbar, denn es ist progressive enhancement.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar Bittersmann,

Nichts. Aber warum nicht in %?

Weil es Blödsinn wäre. Prozent wovon? Vom Viewport? Mit max-width auf dem Body will ich doch erreichen, dass die sinnvolle Lesebreite der Seite nicht überschritten wird – also das, was in der Wikipedia beispielsweise fehlt. Und dafür muss es eine „Konstante“ sein (soweit man bei em-Angaben von Konstanten reden kann).

Man könnte bei der konkreten Seite höchstens einwenden, dass hier die Lesebreite durch die Größe der Fotokacheln automatisch begrenzt wird und eine max-width-Angabe deshalb überflüssig ist. Oder sogar stört, weil man unnötig scrollen muss. Eine Prozentangabe wird dadurch an dieser Stelle immer noch nicht sinnvoll.

Dass es andere Anlässe geben kann, wo eine max-width Angabe in Prozent sinnvoll ist, bestreite ich ja gar nicht. Aber darum geht es hier nicht, es geht um diese konkrete max-width Angabe für diesen konkreten Fall.

Rolf

[Günter]

Hallo Rolf und Gunnar,

vielen Dank für die vielen Hinweise! Ich glaube ich habe alle umgesetzt und dabei erfahren:

grid-template-columns braucht ein repeat, ohne bekomme ich keine Zeilen. Mit grid-auto-columns erscheinen alle Bilder untereinander. Mit "auto" bei grid-template-columns kann ich mehrere Zeilen erzeugen, muss dann aber so oft "auto" schreiben, wie ich Bilder in einer Zeile haben will.

Die Breitenangabe für den Body habe ich mit 100% versucht, dadurch wird der Body jedoch etwas zu breit. Habe jetzt wie Gunnar vorschlug die Angabe einfach weggelassen. Ist okay. "max-width" für den Body ändert nichts an dem zu breiten Body in der Anzeige vom Chrome.

Margin und Padding habe ich reduziert. Die noch vorhandene Angabe ist erforderlich. Wenn ich die auch noch wegnehme habe ich nur noch eine kaum zu sehende Linie zwischen den Zeilen.

Den Cache in meinem Chrome-Browser (Version 120.0.6099.225) habe ich geleert. Das hat jedoch keine Veränderung ergeben. Chrome erzeugt am Notebook (nicht auf dem Smartphone) einen enorm breiten Body, der mit jedem zusätzlichen Bild in einer Zeile noch breiter wird. Ja, im Anzeigebereich ragt nichts über die Bildschirmbreite hinaus, da wird ein Scrollbalken erzeugt, wie es zu erwarten ist. Der Firefox ist weiterhin dabei, den Body nicht breiter zu machen als den Bildschirm (am Notebook und am Smartphone). Schon merkwürdig, dass dieses Phänomen bei euch nicht vorhanden ist. Der Validator gibt mir keinen Hinweis.

Danke! Grüße Günter

[Günter]

Hallo,

jetzt lief der erste Test mit Chrome unter iOS. Der Inhaltsteil der Seite, also die Zeilen mit den Bildern kommen auf etwa ein Viertel in der Breite des Viewports, der Rest ist roter Hintergrund vom Body. Ich muss also doch wieder mit Breitenangaben arbeiten, wenigstens um die Inhalte gut angezeigt zu bekommen. Chrome unter Android zeigt dieses Verhalten jedoch nicht, da ist alles erwartungskonform.

Das wird jetzt dauern, bis ich mit einer neuen Version komme.

Grüße Günter

[Günter]

Hallo Günter,

du hast da etwas nicht ganz korrekt berichtet.

Auch Chrome unter Android zeigt dieses Ausweiten des Bodys. Es fiel nur nicht auf, aber wenn man den roten Rand rechts berührt und ihn nach links zieht sieht man es.

Ein "max-width=100em;" für den Body ist eingetragen und bringt keine Veränderung.

Grüße

Günter

[Rolf B]

Hallo Günter,

so, jetzt weiß ich was Du meinst und sehe, dass ich das auch habe. Und ich kapiere es nicht. Die Scrolling-Wrapper sind so breit wie der Viewport, das ist okay. Sie haben overflow-x:auto (was zum Scrollbar führt), das ist auch okay. Selbst dann, wenn ich sie auf overflow:hidden zwinge, bleibt der Body überbreit - dabei ist da rechts alles leer.

Wenn ich dem article Element ein overflow:hidden gebe, ist es immer noch nicht gut. Erst ein overflow:hidden auf dem Body schafft Ruhe. Aber das ist nur ein Workaround, der das Problem nicht behebt.

Ich weiß nur (noch) nicht, worin es besteht. Kann das ein Chrome-Bug sein?!

Ein Minimalbeispiel in jsFiddle, dass das nachstellen soll (also ein überbreites Grid in einem Scrollcontainer), zeigt das Verhalten nicht. Da ist irgendwas subtiles am Würg.

Update: Im Firefox (leider älter: 102.15.1esr) besteht das Problem bei mir auch. Allerdings anders: dort wird das article-Element in die Breite gezogen. Ein width:100% auf dem article behebt im FF das Problem. Im Chrome wird das article-Element scheinbar nicht in die Breite gezogen, aber seine Inhalte verbreitern den Body dennoch. Und ein width:100% tut dort gar nichts, auch nicht zusammen mit overflow:hidden. Das ist wirklich seltsam.

Rolf

[Rolf B]

Hallo Günter,

heureka^[1]!

Die "visually-hidden" Spans im Button sind schuld. Sie sind position:absolute, und es gibt kein Elternelement mit expliziter Angabe von position:relative. Dadurch orientieren sie sich am Body und befinden sich außerhalb des Scroll-Kontextes vom scrolling-wrapper. Dadurch produzieren sie Breite.

Lösung: Gib dem Button ein position:relative;!

Ich habe den Wiki-Artikel aktualisiert.

Rolf

---

1. Altgriechisch für „Wo ist mein Handtuch?“ ↩︎

[Günter]

Hallo Rolf,

vielen Dank! Dein Einsatz beeindruckt mich, sowie deine Kenntnisse.

Viele Grüße

Günter

[Günter]

Hallo Rolf,

der Tipp ist klasse und tatsächlich funktionierend.

Er hat aber eine Nebenwirkung: Der versteckte Text wird sichtbar. Ich musste dem Text die Farbe des Hintergrundes geben, damit er nicht mehr sichtbar ist.

Viele Grüße

Günter

[Rolf B]

Hallo Günter,

Lösung: Gib dem Button ein position:relative;!

Das hast Du aber nicht! Guck Dir im Zweifelsfalls nochmal an, wie das Beispiel im Wiki den Button mit verstecktem Text erzeugt.

Hintergrundinfo: Ein span-Element hat von Hause aus display:inline;. Ein inline-Element akzeptiert die width- und height-Eigenschaften nicht, sondern berechnet sie aus seinem Inhalt (unter anderem, weil es umgebrochen werden kann). Ein absolut positioniertes Inline-Element hingegen bekommt vom Browser display:block; zugewiesen, so dass man width und height setzen kann. Hab ich auch gerade erst gelernt, ich hatte mich schon gewundert, weshalb das Wiki-Beispiel kein display:block; gesetzt hatte. Du hast das span-Element auf position:relative gesetzt, wodurch die inline-Eigenschaft zurückkam, width und height nicht mehr wirken und der Text sichtbar wurde.

Rolf

[Günter]

Hallo Rolf,

du hast so Recht. Ich brauche Urlaub, zum Glück geht es morgen los.

Jetzt habe ich die Pfeile zum Blättern eingebaut und wieder gibt es ein Problem mit iOS, dort sind sie nicht zu sehen...

Aber nun mache ich ein paar Wochen Pause, danach geht es weiter.

Vielen Dank noch mal.

Grüße

Günter

[Günter]

Hallo an alle die geholfen haben,

jetzt ist es gut. Das letzte Problem mit den nicht angezeigten Pfeilen unter iOS hat sich geklärt. Das Problem lag hier:

		font-family: sans-serif;

Das geht, aber unter iOS werden dann viele Zeichen nicht angezeigt. Besser ist jetzt diese Variante:

		font-family: "Times New Roman", arial, serif;

damit werden alle Zeichen angezeigt.

Danke noch mal an alle die mir geholfen haben.

Grüße Günter