Walter P.: Probleme mit der Ausrichtung auf der Seite

Hallo,

nachdem wir im Team Lydia, Gerhard, Liss, u.a einzelne Fragen angingen und mit Eurer Hilfe klärten, haben wir nun alles zusammengeworfen in ein Codepen. Leider hatten wir versäumt, zuvor Vereinbarungen zu treffen über Tabellennamen u.a. Begriffe. Dadurch kann es zu Problemen in der Zusammenstellung gekommen sein. Trotzdem sieht es ganz passabel auf. Jetzt aber das Problem: Nach den kleinsten Änderungen, wie Einfügen von Rahmenlinien, längere oder kürzere Texte im nav- oder aside-Bereich kommt es zu gravierenden Änderungen in der Seitenansicht. Man kann doch nicht, wenn man im aside-Bereich den Text verändert gleich an der Struktur ändern.

Hier einige Beispiele unserer "Werke".

Version 1

Version 1a

Version 2

Version 2a

Version 3 - Unser Favorit

Version 4

Schönen Gruß

Walter

  1. Hallo Walter,

    mir scheint, euer Layout ist jetzt aus diversen Bausteinen zusammengeworfen worden und am Ende passt überhaupt nichts mehr zusammen.

    Ich meine, ich hätte es schonmal geschrieben: Es ist semantisch falsch, für den Hauptteil der Seite (die Tabelle) das aside-Element zu verwenden.

    Es ist semantisch ebenfalls suboptimal, die Navigation ins main-Element zu verlegen.

    Aber das zerreißt euch das Layout nicht. Ihr habt für das main-Element ein display:flex mit flex-flow:wrap gemacht. Die Tabelle hat eine bestimmte vorgegebene Breite (90vw), und wenn der nav-Bereich zu breit wird, bricht die Flexbox das um und die Tabelle steht unter der Navigation.

    Die Borders führen ebenfalls zu Verschiebungen. Das liegt daran, dass die Größe einer Box standardmäßig durch die Größe des Inhalts bestimmt wird. Wenn Du einem div sagst: width:20em, und ihm dann einen Rand von 2px und ein Padding von 1em gibst, ist die Gesamtbox eben 22em+2px breit. Wenn Du möchtest, dass die angegebenen Abmessungen border und padding enthalten, musst Du die box-sizing Eigenschaft verwenden und auf border-box setzen, damit bekommst Du die Internet Explorer Quirksmode Messmethode, die oft die sinnvollere ist.

    Kurz gesagt: Responsive Ansätze mit fixen Abmessungen zu kombinieren gelingt eher selten. Vor allem bei einer Flexbox mit Umbruch (flex-flow:wrap).

    Bevor man ein Layout zusammenschmeißt, muss man die Regeln definieren, denen es folgen soll. Das kann man durch eine Skizze ergänzen. Was hingegen nicht hilft, ist, es durch Beispiele anzudeuten.

    Mir scheint, ihr wollt folgendes:

    Reihe 1:

    • Höhe nach Bedarf.
    • Ein Headerbereich über die ganze Fensterbreite, mit einem Logo, einem Link zur englischen Version und einer Überschrift.

    Reihe 2:

    • Höhe: ???
    • Eine Navigation, linksbündig, so breit wie die darin enthalten Navigationspunkte. Eventuell: Limitiert auf eine bestimmte Maximalbreite
    • Der Hauptteil, schließt sich an die Navi an und füllt die Fensterbreite auf. Enthält eine Tabelle. Ist der Hauptteil breite als die Tabelle, soll die Tabelle darin zentriert sein.
    • Navi und Hauptteil sollen nebeneinander stehen. Frage: IMMER? Was ist bei schmalen Viewports?

    Reihe 3:

    • Höhe: nach Bedarf?
    • Sichtbarkeit: Ständig? Oder soll man bei langen Inhalten die Seite scrollen, um zum Footer zu gelangen?
    • Ein Footer-Bereich mit Links zu Impressum und Kontaktseite. Links linksbündig, mit etwas Abstand

    Unklar ist das gewünschte Höhenverhalten von Hauptteil und Gesamtseite. Eure Beispiele zeigen oft genug zwei Scrollbars, einen für die Seite und einen für die Tabelle. Vor allem, wenn man das Fenster verkleinert. Wollt ihr das? Ich finde es falsch. Entweder ist die Gesamtseite höhenlimitiert, so dass der Footer ständig sichtbar ist und man nur den Hauptteil scrollt, oder man scrollt die gesamte Seite (was die sticky-Überschrift der Tabelle unsinnig macht).

    Diese "Reihen" sind eigentlich ein klarer Hinweis darauf, dass Flexbox das falsche Werkzeug ist. Ich habe schon vor ein paar Tagen (äh, hier) empfohlen, das Layout per Grid zu erstellen.

    Wäre das eher eure Vorstellung?

    Die Flexbox im Header ist vermutlich suboptimal. Eigentlich sollte der Logo/Englisch Link (der mir merkwürdig vorkommt) in Grid-Spalte 1 stehen und die h1 in Grid-Spalte 2. Dafür muss man dann aber entweder das header-Element wegschmeißen oder ich müsste euch auch noch mit fiesen Tricks wie display:contents belästigen. Darum habe ich es erstmal so gelassen, wie ihr es erstellt habt.

    Die tr in der Nav-Liste habe ich weggeschmissen. Die haben da nichts zu suchen, eine Liste ist keine Tabelle.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. Hallo Rolf,

      Wäre das eher eure Vorstellung?

      Nach erstem Test trifft Dein Vorschlag zu 150% 🙂 unsere Vorstellungen!

    2. Hallo Rolf, danke für die ausführlichen Erläuterungen

      Ihr habt für das main-Element ein display:flex mit flex-flow:wrap gemacht. Die Tabelle hat eine bestimmte vorgegebene Breite (90vw), und wenn der nav-Bereich zu breit wird, bricht die Flexbox das um und die Tabelle steht unter der Navigation.

      Bei schmalen Viewports soll die Navigation unter den Header und darunter das main. Da dachten wir an Deine Vorschlag "summary-Element".

      Mir scheint, ihr wollt folgendes:

      Reihe 1:

      • Höhe nach Bedarf.
      • Ein Headerbereich über die ganze Fensterbreite, mit einem Logo, einem Link zur englischen Version und einer Überschrift.

      Ja

      Reihe 2:

      • Höhe: ???

      Welche Höhe? Höhe abhängig von der Anzahl der Tabellenzeilen? Unten sollte bei schmalen displays der Scrollbalken sichtbar sein.

      • Eine Navigation, linksbündig, so breit wie die darin enthalten Navigationspunkte. Eventuell: Limitiert auf eine bestimmte Maximalbreite

      Ja Maximalbreite müssten wir noch festlegen und auch wann die breie Version umkippt zur schmalen Version. Wichtig ist, dass ein möglichst großer Teil der Tabelle sichtbar ist.

      • Der Hauptteil, schließt sich an die Navi an und füllt die Fensterbreite auf. Enthält eine Tabelle. Ist der Hauptteil breite als die Tabelle, soll die Tabelle darin zentriert sein.

      Ja

      • Navi und Hauptteil sollen nebeneinander stehen. Frage: IMMER? Was ist bei schmalen Viewports?

      siehe oben

      Reihe 3:

      • Höhe: nach Bedarf?

      ja

      • Sichtbarkeit: Ständig? Oder soll man bei langen Inhalten die Seite scrollen, um zum Footer zu gelangen?

      Ursprünglicher Gedanke: Ja, über scrollen oder über einen Link im Nav-Bereich.
      Nach Deinen Bedenken aber untenstehende Variante.

      • Ein Footer-Bereich mit Links zu Impressum und Kontaktseite. Links linksbündig, mit etwas Abstand

      Möglicherweise auch in der Mitte mit etwas Abstand. Möglicherweise noch ein dritter Punkt "Datenschutzhinweise" o.ä. Aber das gelangt uns jetzt dann wohl😉

      Unklar ist das gewünschte Höhenverhalten von Hauptteil und Gesamtseite. Eure Beispiele zeigen oft genug zwei Scrollbars, einen für die Seite und einen für die Tabelle. Vor allem, wenn man das Fenster verkleinert. Wollt ihr das? Ich finde es falsch.

      Das hat uns auch schon gestört!

      Entweder ist die Gesamtseite höhenlimitiert, so dass der Footer ständig sichtbar ist und man nur den Hauptteil scrollt, oder man scrollt die gesamte Seite (was die sticky-Überschrift der Tabelle unsinnig macht).

      Demnach korrigieren wir unsere ursprüngliche Vorstellung, dass die Fußeile ganz am Ende steht.

      Diese "Reihen" sind eigentlich ein klarer Hinweis darauf, dass Flexbox das falsche Werkzeug ist. Ich habe schon vor ein paar Tagen (äh, hier) empfohlen, das Layout per Grid zu erstellen. Wäre das eher eure Vorstellung?

      Ja

      Die Flexbox im Header ist vermutlich suboptimal.

      War für uns einfacher. Das grid hat ja so viele Möglichkeiten, die uns noch verwirren. Allein schon Deine body-Angabe ist für uns noch gewöhnungsbedürftig:

         body {
        --body-margin: 8px;
        margin: var(--body-margin);
        height: calc(100vh - 2*var(--body-margin));
        display: grid;
        grid: "head head" auto
              "nav main" 1fr
              "foot foot" auto / minmax(auto,12em) 1fr;
        gap: 0.5em 1em;
      }
      

      An solchen Beispielen blieben wir immer wieder hängen. Die Form --body-margin mussten wir verstehen, wohl wegen der Wartungsfreundlichkeit, die Funktion calc u.a. Vergeblich haben wir gesucht nach der Syntax von grid u.a. Daher mussten wir die Beispiele hernehmen und alles mögliche verändern, um die Wirkung zu sehen.

      In Deinem Beispiel habe ich jetzt aber keinen Unterschied bemerkt, wenn ich auto oder 1fr entfernt habe.

      Schönen Gruß

      Walter

      1. Hallo Walter,

        ich habe kein Archiv der diversen Threads, die hier zu eurem Thema gelaufen sind. Was nicht im aktuellen Thread steht, das ist meinem Gedächtnis ziemlich sicher entglitten. Vor allem ist es schwierig für uns, nachzuhalten, wer von den aktuellen Forenbesuchern zu einem Team gehört.

        Dieser Thread von Lydia legt nahe, dass ihr das Menü im schmalen Modus per details/summary aufklappbar haben wollt.

        An dieser Stelle seid ihr ohne JavaScript verloren, denn ihr wollt ja im breiten Viewport das Details-Element ständig aufgeklappt haben und das ist ohne JS nicht lösbar.

        Aber ich meine, es wäre diskutiert worden, dass ihr das Menü auf schmalen Viewports per details/summary auf- und zuklappen wollt.

        https://jsfiddle.net/Rolf_b/k2btqc8o/

        Dieses Fiddle führt die Medienumschaltung per JavaScript durch, mit einer window.matchMedia-Abfrage. Diese Abfrage im Script ist nötig, um das details-Element bei breitem Viewport zu öffnen, und ich möchte die Regel nicht im Script und im CSS doppeln. Deshalb gibt's keine @media-Rule, sondern das Script setzt eine Klasse "wideScreen" auf dem Body und die nötigen Layout-Umbauten im CSS reagieren auf diese Klasse. Die Umschaltbreite ist im Parameter des matchMedia-Aufrufs zu finden. Was matchMedia tut, findet ihr im Wiki.

        Das Gesamtlayout ist "small first", d.h. die "Normaldarstellung" des Body ist der schmale Bildschirm. Die wideScreen-Klasse baut das Layout für breiten Bildschirm um, indem das Body-Grid eine zweite Spalte bekommt und die absolut-Positionierung des Menüs zurückgebaut wird.

        Das Menü ist oben links im Main-Bereich positioniert (grid-area:main und place-self: start start). Als Kommentar ist eine Alternativplatzierung im Header dabei (grid-area:head und place-self: end start).

        Bei Unklarheiten gerne fragen bzw. die Stichwörter im Wiki nachlesen.

        Rolf

        --
        sumpsi - posui - obstruxi