Michael_K: Visualisierung bei overflowing content

Hallo,

nach meiner Recherche gibt es keinen CSS Selector für DOM-Elemente, die einen overflowing content besitzen. Ich würde gerne die Bestandteile einer html-Seite farblich umranden, deren Inhalt "überfliesst", d.h. nicht in den verfügbaren Platz passen.

Ich könnte via Javascript ermitteln, ob overflow vorliegt und dann eine entsprechende CSS-Klassen setzen (oder lokales style-Attribute). Mich würde aber interesieren, ob es einen eleganteren Weg gibt? Eine reine CSS Lösung scheint nicht möglich, da es keinen CSS Selector für overflow content gibt.

Ich hatte ein Beispiel mit einem Intersectionobserver gefunden, das habe ich aber noch nicht wirklich gut verstanden, wie so eine IntersectionObserver funktioniert.

Hat vielleicht jemand einen Tipp, wie eine solche Lösung aussehen kann, bei der permanent überprüft wird, ob es content overflow gibt und wenn ja, dieses element highlight (z.B. roter Rahmen)?

Viele Grüße Michael

  1. @@Michael_K

    nach meiner Recherche gibt es keinen CSS Selector für DOM-Elemente, die einen overflowing content besitzen. Ich würde gerne die Bestandteile einer html-Seite farblich umranden, deren Inhalt "überfliesst", d.h. nicht in den verfügbaren Platz passen.

    Zunächst einmal: Wenn man Webdesign richtig macht, gibt es i.A. keinen Inhalt, der nicht in den verfügbaren Platz passt. Weil sich der Platzbedarf nach dem Inhalt richtet, und nicht der Platz künstlich (aus fadenscheinigen Gründen) beschränkt wird.

    Und ist die auftauchende Scrollbar nicht genug visuelle Markierung? (Ggfs. müsste man sein System so einstellen, dass auch wirklich eine Scrollbar auftaucht.)

    Ich könnte via Javascript ermitteln, ob overflow vorliegt und dann eine entsprechende CSS-Klassen setzen (oder lokales style-Attribute). Mich würde aber interesieren, ob es einen eleganteren Weg gibt?

    Was es nicht gibt: „CSS-Klassen“.

    Einen eleganteren Weg sollte es geben: nicht den Platz künstlich beschränken. Warum gehst du den nicht?

    🖖 Живіть довго і процвітайте

    --
    „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
    — @Grantscheam auf Twitter
    1. Ähm, ich bin nicht der, der den Platz beschränkt. Sondern der, der dieses schlechte Design aufdecken möchte ;-) Danke für dein Beispiel mit dem IntersectionObvserver, ich glaube, ich taste mich langsam vorwärts in die richtige Richtung.

      1. @@Michael_K

        Ähm, ich bin nicht der, der den Platz beschränkt. Sondern der, der dieses schlechte Design aufdecken möchte ;-)

        Ah, sowas wie Revenge.css

        🖖 Живіть довго і процвітайте

        PS: s.a. „grad gesehen“

        --
        „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
        — @Grantscheam auf Twitter
      2. @@Michael_K

        Danke für dein Beispiel mit dem IntersectionObvserver, ich glaube, ich taste mich langsam vorwärts in die richtige Richtung.

        Ich glaube, nicht. IntersectionObvserver ist wohl nicht die beste Idee. Der läuft ja ständig – muss er aber gar nicht. Man muss ja nur einmalig[1] scrollHeight mit clientHeight vergleichen.

        🖖 Живіть довго і процвітайте

        --
        „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
        — @Grantscheam auf Twitter

        1. Unveränderliche Inhalte vorausgesetzt. Und – wie gesagt – müsste man das bei Änderung der Viewportgröße wieder tun. ↩︎

        1. @@Gunnar Bittersmann

          Man muss ja nur einmalig[^1] scrollHeight mit clientHeight vergleichen.

          Wenn du auch Boxen hast, wo horizontal gescrollt wird, das dann auch mit scrollWidth und clientWidth.

          Und – wie gesagt – müsste man das bei Änderung der Viewportgröße wieder tun.

          Gesagt, getan: mit ResizeObserver.

          🖖 Живіть довго і процвітайте

          --
          „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
          — @Grantscheam auf Twitter
          1. @@Gunnar Bittersmann

            Gesagt, getan …

            … aber du willst ja nicht nur bestimmte Elemente (in meinem Beispiel section) prüfen, sondern alle – mit Ausnahme von html und body, bei denen ja normal ist, dass darin gescrollt werden muss. Auch head und alles darin muss nicht überprüft werden, sofern du nicht irgendwas davon anzeigen lässt.

            Also den Selektor zu body * geändert (und den Variablennamen angepasst!) – und prompt bekamen in meinem Beispiel auch alle h2-Elemente den roten Rahmen[1]. Da wurde wohl bei scrollHeight aufgerundet und bei clientHeight abgerundet. Also noch den Schwellenwert für die Differenz um 1 erhöht: overflow detection 4 for all elements.

            Um auch nachträglich per JavaScript generierte Elemente in die Prüfung einzubeziehen, müsste man noch einen MutationObserver verwenden. Das überlasse ich jetzt mal dir.

            🖖 Живіть довго і процвітайте

            PS: Und was sich bislang auch der Prüfung entzieht, sind Pseudoelemente, bei denen ja auch Overflow auftreten könnte. Die überlasse ich auch dir.

            --
            „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
            — @Grantscheam auf Twitter

            1. für den Rahmen outline verwenden, nicht border, um das Layout nicht zu ändern ↩︎

            1. Cool, tausend Dank!!!!

              Jetzt muss ich es nur noch verstehen lernen.

              Gruss, Michael

  2. @@Michael_K

    Ich hatte ein Beispiel mit einem Intersectionobserver gefunden, das habe ich aber noch nicht wirklich gut verstanden, wie so eine IntersectionObserver funktioniert.

    Ich bin mir nicht sicher, ob ich das tue. 😉

    Aber meine Bastelei scheint zu funktionieren. Allerdeings nur initial; das reagiert nicht auf Änderungen der Viewportgröße. Da müsste man das Ganze noch in einen ResizeObserver packen.

    🖖 Живіть довго і процвітайте

    --
    „Im Vergleich mit Elon Musk bei Twitter ist ein Elefant im Porzellanladen eine Ballerina.“
    — @Grantscheam auf Twitter