header position: fixed; padding-top des darunter liegenden Elements anpassen

[michaah]

Meine gerade im Umbau befindliche, nun responsive Website (mobile first) hat (zumindest in der schmalen Schlauchversion für Smartphones) einen oben festgenagelten header. Beim Zusammenschieben (gut, das ist bei Smartphones nur sehr begrenzt der Fall, dennoch ... dann sagen wir Tabletts ;-)) kommt es zu Zeilenumbrüchen, und das unter dem festgenagelten header liegenede Element (main) wird teilweise überdeckt, weil nun das padding-top nicht mehr ausreicht. Einfach den padding Wert generell höher zu setzen sieht nicht gut aus und soll vermieden werden.

Gibt es mit reinem CSS (also ohne JS) eine Möglichkeit per calc(), oder?, oder?, den tatsächlichen heigth-Wert des headers als padding-top Wert (+X) für main zu nutzen? Ich vermute eigentlich nein, weil wie ich es verstehe kann man vielleicht ein Attribut auslesen, nicht aber einen berechneten Wert.

Ok, dann anders: Habe ich Unrecht und es geht doch irgendwie (ohne JS)?

[Rolf B]

Hallo michaah,

spontan würde ich Nein sagen.

Aber muss der Header fixed sein? Geht nicht auch sticky? Damit sollte sich das auflösen (kann's grad nicht probieren).

Rolf

[michaah]

Geht nicht auch sticky? ...

Gute Idee, unterm Strich sogar besser.

Danke.

[Gunnar Bittersmann]

@@michaah

Geht nicht auch sticky? ...

Gute Idee, unterm Strich sogar besser.

Njein.

Ich hab je hier auch schon öfter erzählt und gezeigt, mit sticky sei all gut. Weit gefehlt.

Das löst zwar das Problem, dass der Seiteninhalt initial nicht unterm Header verschwindet. Andere Probleme fangen aber erst an:

Wenn seiteninterne Sprungmarken vorhanden sind, werden die beim Anspringen am oberen Bildschirmrand plaziert, d.h. hinter dem Header versteckt. Die müsste man dann doch mit JavaScript um die Headerhöhe (plus etwas Luft) nach unten scrollen. Und das nach Möglichkeit etwas intelligenter als in diesem Beispiel, wo auch Artikel 30 unnötigerweise nach unten und damit aus dem Viewport heraus gescrollt wird.

Wenn die Seite interaktive Elemente (Links, Formularfelder, …) enthält, werden diese bei Bedienung mit Tastatur^[1] bei Bedarf auch am oberen Bildschirmrand plaziert, d.h. hinter dem Header versteckt. Auch die müssen per JavaScript in den sichtbaren Bereich gescrollt werden.

(Just in dem Moment bin ich gerade dran, das in dem Projekt, an dem ich arbeite, umzusetzen.)

Ohne JavaScript geht bei sticky fing header gar nichts. position: sticky sollte also auch mit JavaScript erst dann gesetzt werden, wenn das dazu nötige JavaScript geladen wurde.

Oder man setzt halt nicht position: sticky für den Header, sondern man macht den Hauptbereich (main-Element) scrollbar.

😷 LLAP

---

1. nachträglich eingefügt ↩︎

[djr]

@Gunnar Bittersmann

Wenn seiteninterne Sprungmarken vorhanden sind, werden die beim Anspringen am oberen Bildschirmrand plaziert, d.h. hinter dem Header versteckt.

Dagegen hilft in immer mehr Browsern:

html {
	scroll-padding-top: 6rem;
}

(Um ältere Chromium-Browser zu unterstützen, muss zusätzlich der body selektiert werden.)

[Auge]

Hallo

Dagegen hilft in immer mehr Browsern:

Wer zu Himmel hat dem Betreiber von CanIUse? dieses neue, meiner Meinung nach grauenhafte und schlecht interpretierbare Farbschema aufgeschwatzt? Nicht nur, dass für mich die Farben grau (unbekannt) und grün (unterstützt) schwer unterscheidbar sind, auch die diagonale rotbasierte Streifung (nicht unterstützt) ist für mich von der senkrechten grünbasierten Streifung (teilweise unterstützt) aufgrund der konkret benutzten Farbtöne schwer zu unterscheiden.

Für mich hat das Tool damit seine Nützlichkeit eingebüßt. Schade auch. 😒

Tschö, Auge

[Der Martin]

Hi,

Wer zu Himmel hat dem Betreiber von CanIUse? dieses neue, meiner Meinung nach grauenhafte und schlecht interpretierbare Farbschema aufgeschwatzt?

vielleicht jemand, der noch nie von einer Rot-Grün-Schwäche gehört hat?

Nicht nur, dass für mich die Farben grau (unbekannt) und grün (unterstützt) schwer unterscheidbar sind, auch die diagonale rotbasierte Streifung (nicht unterstützt) ist für mich von der senkrechten grünbasierten Streifung (teilweise unterstützt) aufgrund der konkret benutzten Farbtöne schwer zu unterscheiden.

Dann bist du anscheinend genau davon betroffen? Denn ich bin zwar kurzsichtig, aber bezüglich der Farbwahrnehmung nicht beeinträchtigt, und für mich sind die Farbtöne sehr gut unterscheidbar.

Ich weiß aber auch, dass z.B. rote Schrift auf grünem Hintergrund (oder umgekehrt) sehr schlecht lesbar ist, obwohl es Komplementärfarben sind. Aber der Kontrast ist sehr gering, weil die Grauwerte nah beieinanderliegen.

Für mich hat das Tool damit seine Nützlichkeit eingebüßt. Schade auch. 😒

Ich ärgere mich aus demselben Grund immer wieder über die für mich schlecht unterschiedbaren Farbschemata in Microsoft-Anwendungen. Alles grau in grau, kaum Kontrast. Oder, wie Linuchs einmal formuliert hat: Text in Hellgrau auf einem Hintergrund in Hellhellgrau.

Live long and pros healthy,
 Martin

[Auge]

Hallo

Wer zu Himmel hat dem Betreiber von CanIUse? dieses neue, meiner Meinung nach grauenhafte und schlecht interpretierbare Farbschema aufgeschwatzt?

vielleicht jemand, der noch nie von einer Rot-Grün-Schwäche gehört hat?

Vermutlich ja.

Nicht nur, dass für mich die Farben grau (unbekannt) und grün (unterstützt) schwer unterscheidbar sind, auch die diagonale rotbasierte Streifung (nicht unterstützt) ist für mich von der senkrechten grünbasierten Streifung (teilweise unterstützt) aufgrund der konkret benutzten Farbtöne schwer zu unterscheiden.

Dann bist du anscheinend genau davon betroffen?

$schtring = str_replace("?", ".", "Dann bist du anscheinend genau davon betroffen?");

Für mich hat das Tool damit seine Nützlichkeit eingebüßt. Schade auch. 😒

Ich ärgere mich aus demselben Grund immer wieder über die für mich schlecht unterschiedbaren Farbschemata in Microsoft-Anwendungen. Alles grau in grau, kaum Kontrast. Oder, wie Linuchs einmal formuliert hat: Text in Hellgrau auf einem Hintergrund in Hellhellgrau.

Anderes System, ähnliches Problem.

Tschö, Auge

[Matthias Scharwies]

Servus!

Hallo

Dagegen hilft in immer mehr Browsern:

Wer zu Himmel hat dem Betreiber von CanIUse? dieses neue, meiner Meinung nach grauenhafte und schlecht interpretierbare Farbschema aufgeschwatzt? Nicht nur, dass für mich die Farben grau (unbekannt) und grün (unterstützt) schwer unterscheidbar sind, auch die diagonale rotbasierte Streifung (nicht unterstützt) ist für mich von der senkrechten grünbasierten Streifung (teilweise unterstützt) aufgrund der konkret benutzten Farbtöne schwer zu unterscheiden.

Für mich hat das Tool damit seine Nützlichkeit eingebüßt. Schade auch. 😒

Ganz unten rechts: Enable color-blind friendly colors (in orange)

Damit kann man umschalten ("Customize default website color scheme and select preferred support table colors.")

Schöner wär natürlich, das gleich als Standard zu nehmen.

Herzliche Grüße

Matthias Scharwies

[Auge]

Hallo

Wer zu Himmel hat dem Betreiber von CanIUse? dieses neue, meiner Meinung nach grauenhafte und schlecht interpretierbare Farbschema aufgeschwatzt?

Ganz unten rechts: Enable color-blind friendly colors (in orange)

Ah, ja. Danke für den Tip. Das entspannt die Situation erheblich. Das Farbschema ist zwar gewöhnungsbedürftig, aber gut „lesbar“.

Damit kann man umschalten ("Customize default website color scheme and select preferred support table colors.")

Schöner wär natürlich, das gleich als Standard zu nehmen.

Noch schöner wäre wohl gewesen, das frühere (zumindest für mich gut funktionierende) Farbschema erst gar nicht „kaputt“ zu machen a.k.a. zu ersetzen.

Tschö, Auge

[Gunnar Bittersmann]

@@djr

html {
	scroll-padding-top: 6rem;
}

Was es nicht alles gibt! Das ist ja einfach. –

Wenn man denn die Höhe des sticky headers kennt. Wenn sich die aber nach den Gegebenheiten beim Client (Viewportgröße, Schriftgröße, …) richtet (was nicht die schlechteste Idee ist!), dann muss man da doch mit JavaScript ran.

Das JavaScript muss aber nicht mehr tun als die Höhe des Headers auslesen und in eine custom property schreiben – initial und bei Änderung der Viewportgröße.

Und natürlich das position: sticky anschalten – das darf ja nur wirken, wenn das JavaScript läuft.

☞ Pen geforkt

😷 LLAP

[michaah]

@@michaah

Geht nicht auch sticky? ...

Gute Idee, unterm Strich sogar besser.

Njein.

Danke für deine Hinweise.

OK, wenn nicht mit sticky sondern doch mit position: fixed, hast du ne Idee ob/wie man (möglichst ohne JS) bei Zeilenumbrüchen im fixed header den paddingwert des drunterliegenden blocks vergrößern kann?

Was mir eben noch einfällt, wenn man statt eines padding dort ein div mit text nutzen würde, welcher dann auch umbricht (unter dem header liegend) sollte es doch klappen? Nein, wirklich gefallen würde mir diese "Lösung" nicht. Vielleicht bringt sie aber jemanden auf eine Idee (falls das überhaupt so machbar wäre)?

... Wenn seiteninterne Sprungmarken vorhanden sind, werden die beim Anspringen am oberen Bildschirmrand plaziert, d.h. hinter dem Header versteckt. Die müsste man dann doch mit JavaScript um die Headerhöhe (plus etwas Luft) nach unten scrollen. Und das nach Möglichkeit etwas intelligenter als in diesem Beispiel, wo auch Artikel 30 unnötigerweise nach unten und damit aus dem Viewport heraus gescrollt wird.

Außer einer Sprungmarke von ganz unten nach ganz oben habe ich keine weiteren, sollte also nicht zum Problem werden.

Wenn die Seite interaktive Elemente (Links, Formularfelder, …) enthält, werden diese bei Bedienung mit Tastatur[^edit] bei Bedarf auch am oberen Bildschirmrand plaziert, d.h. hinter dem Header versteckt. Auch die müssen per JavaScript in den sichtbaren Bereich gescrollt werden.

Das muß ich mir erstmal anschauen. Bislang verstehe ich das Problem noch nicht ...

Gruß

Michael