Absolut positionierte Elemente im Textfluss

[heinetz]

Hallo Forum,

In dem Beispiel löse ich den Container .bottom mit position:absolute; aus dem Textfluss.

Beipspiel

So liegt .bottom natürlich über den anderen Elementen in .container. Das würde ich gerne vermeiden. Um das zu vermeiden, könnte ich bspw. mit einem padding-bottom im Container entsprechend Platz für .bottom schaffen. Leider weiss ich aber nicht, wieviel, weil die Höhe von Container abhängig von dessen Inhalt ist.

Lässt sich das elegant lösen?

danke für Tipps und

gruss, heinetz

[Gunnar Bittersmann]

@@heinetz

In dem Beispiel löse ich den Container .bottom mit position:absolute; aus dem Textfluss. […] So liegt .bottom natürlich über den anderen Elementen in .container. Das würde ich gerne vermeiden. […] Lässt sich das elegant lösen?

Ja: .bottom nicht aus dem Textfluss nehmen, also nicht absolut positionieren.

Je nachdem, was du erreichen willst:

• Seitenlayout mit Grid oder Flexbox
• position: sticky

LLAP 🖖

[heinetz]

... position:sticky kannte ich nicht.

danke und

gruss, heinetz

[heinetz]

... läuft aber leider nicht im IE 11 ;(

[beatovich]

hallo

... läuft aber leider nicht im IE 11 ;(

Deshalb dürfte flex auch die geignetere Lösung sein.

[marctrix]

Hej heinetz,

... läuft aber leider nicht im IE 11 ;(

Na und? - Progressive enhancement: Gutes Webdesign beginnt mit einem Fallback 😉

Marc

[beatovich]

hallo

Hej heinetz,

... läuft aber leider nicht im IE 11 ;(

Na und? - Progressive enhancement: Gutes Webdesign beginnt mit einem Fallback 😉

Ja gut, damit wären wir halt wieder am Anfang der Aufgabe angelangt.

[marctrix]

Hej beatovich,

... läuft aber leider nicht im IE 11 ;(

Na und? - Progressive enhancement: Gutes Webdesign beginnt mit einem Fallback 😉

Ja gut, damit wären wir halt wieder am Anfang der Aufgabe angelangt.

Die Aufgabe ist eh nicht lösbar. Wie @heinetz selber sagt, ist der Inhalt der Box unbekannt, somit auch deren Höhe. Ebenso unbekannt (hat keiner hier angemerkt) ist die Größe des Viewports. Es ist also wahrscheinlich, dass diese Box sämtliche anderen Inhalte überdecken wird, ja sogar, dass die Box selber teilweise nicht sichtbar sein wird.

Man kann eine Box von unbekannter Größe also nicht in einem Viewport unbekannter Größe unten positionieren, wenn zusätzliche Inhalte sichtbar sein sollen!

Das ist schon bei den für Cookies bekannten Hinweisen schwierig auf mobilen Geräten, umso mehr, als diese jetzt auch noch oft Datenschutz-Hinweise enthalten. Nutz mal ein relativ kleines iPhone SE mit der größtmöglichen Schrifteinstellung und dann schau dir mal besagte Boxen an… 😉

Da die Inhalte rechtlich relevant sind, sollten sie tunlichst auch zugänglich sein!

Heißt: Lasst die Box im normalen ELementfluss und reizt die Möglichkeiten von flexbox und grid aus (falls man das noch als "normalen Elementfluss" gelten lassen möchte)…

Marc

[beatovich]

hallo

Die Aufgabe ist eh nicht lösbar.

BS!

Man kann eine Box von unbekannter Größe also nicht in einem Viewport unbekannter Größe unten positionieren, wenn zusätzliche Inhalte sichtbar sein sollen!

Die Frage ist, ist das unabhängige Positionieren das Ziel oder lediglich ein Mittel gewesen.

MSIE 11 versteht flex-box.

Und das war meine Antwort.

[Gunnar Bittersmann]

@@beatovich

MSIE 11 versteht flex-box.

MSIE 11 versteht auch -ms-grid.

LLAP 🖖

[Gunnar Bittersmann]

@@marctrix

Die Aufgabe ist eh nicht lösbar.

Die Lösbarkeit hängt von den Mitteln ab.

Wie @heinetz selber sagt, ist der Inhalt der Box unbekannt, somit auch deren Höhe. Ebenso unbekannt (hat keiner hier angemerkt) ist die Größe des Viewports.

Beides lässt sich mit JavaScript auslesen.

Man kann eine Box von unbekannter Größe also nicht in einem Viewport unbekannter Größe unten positionieren, wenn zusätzliche Inhalte sichtbar sein sollen!

Man kann mit JavaScript die Höhe der Box (plus etwas Luft) dem Hauptinhalt als padding-bottom verpassen. Und auch die Box nur dann fixieren, wenn JavaScript ausgeführt wird.

Und dafür sorgen, dass fokussierte Link sichtbar sind. Beispiele: fixed overlay • sticky navigation

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Die Aufgabe ist eh nicht lösbar.

Die Lösbarkeit hängt von den Mitteln ab.

Stimmt. In der Aufgabe stand nichts von CSS only und macht in einer echten Website nicht unbedingt Sinn, auf verfügbare Techniken zu verzichten. Wobei will man JS für Layout-Aufgaben? - Ich eher nicht. Hier würde ich die Frage stellen, ob der Designwunsch so viel zur Verbesserung der Usability beiträgt, dass sich das auch lohnt.

Leider gibt es keinen konkreten Anwendungsfall, sondern nur: ist so was möglich.

Marc

[Gunnar Bittersmann]

@@marctrix

Wobei will man JS für Layout-Aufgaben?

Kommt drauf an. Und wenn, dann als progressive enhancement.

LLAP 🖖

[beatovich]

hallo

@@marctrix

Wobei will man JS für Layout-Aufgaben?

Manchmal führt wohl kein Weg daran vorbei.

Hier ist mein aktuelles Problem:

#ex12{
	--var1:0.5;
	width:calc( var(--var1) * 100vw);
	height:calc( var(--var1) * 100vh);
	font-size: calc( var(--var1 ) * 3 * ( 1vw + 1vh ) );
}
~~~

Ich will aber, dass die Breite 100% des parent ist und die Höhe dann die Proportion des Viewports wiedergibt:

~~~~css
#ex12{
	--var1:1;
	width:calc( var(--var1) * 100%); /* einfach so breit wie der Parent*/
	height:calc( var(--var1) * 100% / 100vw * 100vh); /* proportional umgerechnet */
	font-size: calc( var(--var1 ) * 3 * ( 1vw + 1vh ) );
}
~~~

Geht so was mit CSS?



-- 
<https://beat-stoecklin.ch/pub/index.html>

[marctrix]

Hej beatovich,

@@marctrix

Ich will aber, dass die Breite 100% des parent ist und die Höhe dann die Proportion des Viewports wiedergibt:

#ex12{
	--var1:1;
	width:calc( var(--var1) * 100%); /* einfach so breit wie der Parent*/
	height:calc( var(--var1) * 100% / 100vw * 100vh); /* proportional umgerechnet */
	font-size: calc( var(--var1 ) * 3 * ( 1vw + 1vh ) );
}
~~~

Geht so was mit CSS?

Ne, weil du die Höhe dadurch ja änderst (so habe ich das verstanden). 100% von etwas, das du erste berechnest ist ja nicht bekannt. Der Browser rechnet ja mit den Pixeln, die ermittelt und wie viele Pixel 100% sind, ist ja abhängig von dem Rest der Rechnung, kann also keinen festen Pixelwert annehmen und somit nicht zur Berechnung herangezogen werden. Wie gesagt: sofern ich das korrekt verstanden habe, ist das generell das Problem bei Höhen.

Marc

PS: "ICh will" ist natürlich kein Grund, etwas zu tun. Ich nehme mal an, du meintest "ich brauche das aus $gruenden" 😉

[Gunnar Bittersmann]

@@beatovich

Geht so was mit CSS?

Vermutlich nicht, weil der Divisor b bei calc(a/b) eine Zahl ohne Einheit (bzw. ein calc-Ausdruck, der eine solche als Ergebnis liefert) sein muss. [Spec, MDN]

LLAP 🖖

[beatovich]

hallo

@@beatovich

Geht so was mit CSS?

Vermutlich nicht, weil der Divisor b bei calc(a/b) eine Zahl ohne Einheit (bzw. ein calc-Ausdruck, der eine solche als Ergebnis liefert) sein muss. [Spec, MDN]

Ja die calc funktion ist da wohl beschränkt.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Geht so was mit CSS?

Vermutlich nicht, weil der Divisor b bei calc(a/b) eine Zahl ohne Einheit (bzw. ein calc-Ausdruck, der eine solche als Ergebnis liefert) sein muss. [Spec, MDN]

Kommt Zeit, kommt Level 4.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

Vermutlich nicht, weil der Divisor b bei calc(a/b) eine Zahl ohne Einheit (bzw. ein calc-Ausdruck, der eine solche als Ergebnis liefert) sein muss. [Spec, MDN]

Kommt Zeit, kommt Level 4.

spannend: calc(1vh / 1rem * 0.2ch)
Und was darf man sich unter 0.2 vh pro rem mal ch vorstellen? Wird da alles in Pixel umgerechnet?

Gruß
Jürgen

[heinetz]

Hallo Forum,

danke für diese sehr ausführliche Antwort. Ich wollte tatsächlich wissen, ob das mit reinem CSS möglich ist oder ob ich JS benötge.

Meine Lösung sieht wie folgt aus: Da der IE11 in meiner Browsermatrix steht und ich keinen vernünftig funktionierenden polyfill für IE finden konnte, baue ich den Effekt von display:sticky nach. Dazu eignet sich das waypoints als node-modul ganz gut und ob ich die Höhe auslese, oder eine fixe Höhe definiere, hängt davon ab, wie gut ich mich mit dem Designer einige 😉

danke und

lieben gruss, heinetz

[Gunnar Bittersmann]

@@heinetz

Meine Lösung sieht wie folgt aus: Da der IE11 in meiner Browsermatrix steht und ich keinen vernünftig funktionierenden polyfill für IE finden konnte, baue ich den Effekt von display:sticky nach.

Überlegen wir mal gemeinsam, ob das eine gute Idee ist.

Auf was für Systemen läuft noch ein IE 11? Auf neuen, vor Rechenpower nur so protzenden Kisten? Wohl kaum. Eher auf alten langsamen Kleppern.

Was bedeutet display: sticky mit JavaScript nachzubauen? Auf welches Element muss da gelauscht werden? Genau, auf scroll. Wie oft feuert das scroll-Event beim Scrollen? Oft. Sehr oft.

Ist es sinnvoll, auf alten langsamen Systemen viel JavaScript in kurzer Zeit ausführen zu lassen? Na wohl eher nicht.

Das könnte dazu führen, dass das UI beim Scrollen ruckelt. Das ist etwas, was der Nutzer als durchaus störend empfinden wird. Das Anspringen des Lüfters und das Leersaugen des Akkus auch.

Was sie nicht als störend empfindet: Wenn das betreffenden Element nicht sticky ist. (Der IE-Nutzer hat ja gar keinen Vergleich.)

Fazit: Nicht machen. Nicht sticky mit JavaScript nachbauen (oder polyfillen).

Was du tun kannst: Das Ding fixed positionieren und den Platz dafür mit padding freihalten. Den notwendigen Wert mit JavaScript ermitteln (und das bei jedem resize erneut).

Und dafür sorgen, dass das jeweils fokussierte Element nicht hinter dem Ding verborgen ist (aufs focus-Event lauschen und ggfs. in den sichtbaren Bereich rücken).

Ich hab meinen Pen mal beispieltauglich gemacht.

ob ich die Höhe auslese, oder eine fixe Höhe definiere, hängt davon ab, wie gut ich mich mit dem Designer einige 😉

Nein. Wenn es sich um einen Webdesigner handelt, dann wird sie wissen, dass man die benötigte Höhe von Elementen in den seltensten Fällen kennt und „the ebb and flow of things“ akzeptieren muss. [John Allsopp: A Dao of Web Design]

Wenn der Designer auf fester Höhe besteht, dann ist es kein Webdesigner.

LLAP 🖖

[beatovich]

hallo

Wenn der Designer auf fester Höhe besteht, dann ist es kein Webdesigner.

pft... Das ist er auch dann nicht, wenn er die Dinge im Fluss behält.

Wir sind Frontend-Entwickler, das heisst, Leute die sich um Gestaltung von User-Interfaces kümmern. Und wenn du da überdogmatisch bist, bekommst du in einer gewissen Branche, für die Grafik nun mal sehr wichtig ist, keinen Job.

[Gunnar Bittersmann]

@@beatovich

Und wenn du da überdogmatisch bist, bekommst du in einer gewissen Branche, für die Grafik nun mal sehr wichtig ist, keinen Job.

Die Erkenntnis, dass es im Web wenig Festes gibt, sondern dass Webseiten nirgendwo genauso aussehen wie auf dem Schirm des Designers/Entwicklers, ist wohl das Gegenteil von Dogma. Denn das Web ist – wie Eric Meyer es ausdrückt – „the most hostile environment to developer assumptions imaginable.“

Und der Job in dieser „gewissen Branche“ ist nichts Festes, sondern eine Reise – wie John Allsopp sagt: “The journey begins by letting go of control, and becoming flexible.”

LLAP 🖖

[marctrix]

Hej beatovich,

Und wenn du da überdogmatisch bist, bekommst du in einer gewissen Branche, für die Grafik nun mal sehr wichtig ist, keinen Job.

Keine Prinzipien zu haben, ist nie eine gute Idee. Es ist nicht schwer „in einer gewissen Branche“ einen anderen Arbeitgeber zu finden. Und wenn der auch stur ist, geht man halt zum nächsten.

Oder wie Mike Monteiro macht man sich dann irgendwann selbständig, wird berühmt und so reich, wie man es mit seinem Gewissen vereinbaren kann.

Wir sind verantwortlich für das, was wir machen oder lassen!

Nur du bist schuld, wenn du — auf wessen Wunsch und Drängen hin auch immer — schlechte Arbeit ablieferst. Viele Chefs, sind einfach Schweine, die an nichts interessiert sind, außer an Profit. Aber es gibt auch in Deutschland Typen, die das Maul nicht halten. Das funktioniert also nicht nur in Amerika.

Und man kann sich auch zusammentun:

Never code alone!

Marc