Vanessa und Peter tauschen sich in dieser Revision überraschend ausgiebig zu diversen CSS-, HTML- und Accessibility-Problemchen/Features aus.
Schaunotizen
- [00:00:00] Kleinkram
- Vanessa hat festgestellt, dass Viewport-relative Einheiten und vor allem
vh
nur bedingt existieren – zumindest in mobilen Browsern. Browser-Heuristiken und bestimmte Verhaltensweisen von (mobilen) Browsern treiben uns in Sachen horizontalem Scrolling, Accessible Dialog-Design und:focus-visible
um. Wir quatschen kurz über Safari-Bugs und Selektor-Hacking, agitieren für die Verwendung voninput[type=email]
sowie die Nicht-Verwendung vonautofocus
. Über Peters Geheimtipp PostHTML (wie PostCSS, nur für HTML) kommen wir zur Frontend-Gretchenfrage, zur Digital Ocean App Platform, Mobilfunktarifen und G’schichten aus’m Zug. Themenrelevant geht es weiter mit unserer (erfolglosen) Suche nach Use Cases für fit-content undinline-flex
(zu finden in Tailwind UI), CSS Debugging, noch mehr Scrolling/Overflow-Problemen Emoji-Bugs in Chrome, Can I Include, Inclusive Card Components und CSS Modules.
Kommentare
Schepp #
Geschrieben am 16.11.2021 um 16:45
Huhu, schöne Folge habt Ihr wieder Mal eingetütet! :)
Folgende Ergänzungen hätte ich aus dem Off noch anzubieten:
:focus-visible
Dass
:focus:not(:focus-visible)
im Safari nicht geht liegt daran, dass dieser Selektor nur ein Teil einer dreiteiligen Technik ist. Matthias Ott hat das in diesem Blogpost gut beschrieben.Komplett sieht der Ablauf also folgendermaßen aus:
1. Du definierst einen Focus-Style ganz traditionell,
2. Du nimmst ihn für Browser wieder weg, die :focus-visible unterstützen, wenn diese der Meinung sind er müsse nicht sichtbar sein,
3. Du setzt ihn erneut für :focus-visible:
Jetzt könnte man ja noch auf die Idee kommen, die Deklarationen für :focus und :focus-visible zu einer zusammenzufassen, allerdings geht das nicht, weil die Browser per Spec die gesamte Deklaration verwerfen, sobald sie auch nur einen der aufgelisteten Selektoren nicht verstehen.
vh und Browser-UI, die ständig dazwischen funkt
Im Safari könnte Euch bei Eurem Problem
height: -webkit-fill-available
weiterhelfen. Das Keyword-webkit-fill-available
steht dabei für die aktuell sichtbare Höhe des Viewports.Dass es dieses Problem gibt, ist der CSS Working Group aber auch schon aufgefallen, weswegen die neue Viewport Units spezifiziert hat, die uns aus dieser Styling-Hölle heraushelfen sollen:
Die „lv“-Familie, für den größtmöglichen „Large Viewport“:
lvh
,lvw
,lvmin
,lvmax
.Die „sv“-Familie, für den maximal beschnittenen „Small Viewport“:
svh
,svw
,svmin
,svmax
.Die „dv“-Familie, für den aktuell verfügbaren „Dynamischen Viewport“:
dvh
,dvw
,dvmin
,dvmax
.Supported werden die jetzt schon von der Safari Technical Preview.
Ernesto Sun #
Geschrieben am 19.11.2021 um 12:09
Hallo liebe Gurus und Gurinen!
CSS width:fit-content brauch ich zusammen mit margin:auto zum Zentrieren von Block Elementen.
Aber könnte man von außen her mit Flex usw. auch bewirken.
—-
Autofokus: ich check sowieso im Resize-Event ob ich ein Handy mit softkeyboard bin usw. und setz entsprechende Body Klassen.
—-
Danke fürs vh-Verteufeln. Das ist superwertvoll. Und geht ja auch ohne.
Vielen Dank Ihr Lieben!
Schepp #
Geschrieben am 22.11.2021 um 22:11
Ah, das ist cool – vor allem wenn eine Komponente, sich ohne Zuhilfenahme eines Elternelements horizontal zentrieren möchte. Guter Tipp, danke!
Lippe #
Geschrieben am 23.11.2021 um 12:24
Ich nutze **inline-flex** sehr gerne, um darin enthaltene, zusammenhängende Elemente vertikal zu zentrieren, zum Beispiel bei Links den Text mit einem daneben stehenden Icon oder Counterbadge. Vermutlich ist die Badge-Komponente in TailwindUI für so eine Eventualität schon vorbereitet. Wenn man das Element aber nur mit Text befüllt, dann wäre, wie schon erwähnt wurde, auch **inline-block** ausreichend.
Schepp #
Geschrieben am 1.12.2021 um 10:32
👏🏻
Ingo Steinke #
Geschrieben am 1.12.2021 um 10:06
Hey, danke für die Folge (und den Podcast überhaupt)! Frage: wo ist denn das Issue mit dem verschluckten Leerzeichen zu finden, das noch Sternchen gebrauchen kann?
Folge 503 ab ca. 1h 20m als „kapitaler Bug“ genannt. Finde das leider auch hier in den Schaunotizen nicht, auch eine Suche nach „emoji layout with character too small large stackoverflow“ bei Ecosia und Google brachte mich nicht weiter. Möchte ja gerne mit diskutieren und unterstützen.
Danke
Ingo
Ingo Steinke #
Geschrieben am 1.12.2021 um 10:09
Ach, jetzt sehe ich zumindest den Chrome Bug, der ist ja ganz oben verlinkt. Besser erst lesen, dann schreiben, Ingo!
Aber Vanessa erwähnte auch einen StackOverflow-Beitrag dazu?
Vanessa #
Geschrieben am 2.12.2021 um 11:43
https://stackoverflow.com/questions/42016125/emoji-rendered-in-chrome-have-different-widths-than-in-other-browsers
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.