Ein Blog

Chrome experimentiert mit einem neuen Flag: Try text scaling support in Chrome Canary: <meta name="text-scale" content="scale">

Darin sagt der Author:

And that’s not great, because research by Appt shows around 37% of Android users and 34% of iOS users have changed their system-level text scale factor from the default. And web developers currently have no way to respect that.

Falls ihr das Problem jetzt schon lösen müsst: Das stimmt nicht ganz, aktuell kann man das auf iOS mit einem Trick lösen.

Auf iOS gibt es die CSS-Aliase mit dem Präfix -apple. Ihr kennt vielleicht -apple-system. Das ist ein Alias für die Systemfont auf Apple-Geräten (also quasi ein Alias für “San Francisco”).

Darüber hinaus gibt es noch mehr, unter anderem -apple-sytem-body. Das ist nicht nur ein Alias für die Font, sondern für alles, was zum Stil eines “Body-Textes” auf Apple-Systemen dazu gehört. Also auch die Font-Size.

Verwendet man (Fallbacks mal ausgelassen):

font: -apple-system-body;

Dann skaliert sich der Text auch mit den a11y-Settings des Betreibssystems. Das Problem: Das setzt dann die Font auf San Francisco. Das will man vielleicht nicht.

Dafür gibt es einen Trick: Man benutzt die Definition von -apple-system-body, um die komplette Font-Definition zu setzen (also Fontname, Größe, etc.) und überschreibt dann die font-famlily separat:

@supports (font: -apple-system-body) {
    :root {
        font: -apple-system-body;
        font-family: 'Courier New', Courier, monospace;
    }
}

So hat man auf iOS-Geräten automatisch angepasste Schriftgrößen. Wenn man das als Base-Größe verwendet, dann passt das in den anderen Größen mit rem auch wieder.

Ich hab das mal für einen Kunden untersucht, ein funktionierendes Beispiel ist hier deployed: https://nikeee.github.io/ios-dynamic-font-test/

Wer also nicht warten kann und jetzt eine Lösung braucht, die vielleicht nur auf iOS funktionieren muss (z. B. bei einem WebView in einer App), dann hat man hiermit eine okayish lösung. Auf Android funktioniert sie natürlich nicht. Das Ganze mit env-Vars zu standardisieren wirkt auf mich aber noch deutlich sinnvoller.

Ich habe schon eine PWA entwickeln müssen, die auch wirklich PWA-Features nutzt. Der Gedanke war, dass man sich damit spart, eine native App zu bauen (wie so oft). Also so richtig mit lokalen Daten, WebPush, Badges, Caching, Service Workern und so weiter.

Das hört sich auf dem Papier alles toll an, nur ist es in der Praxis kompletter PITA. Größtenteils, weil Safari, die mittlerweile ~30% der User ausmachen, die Hälfte der Sachen nicht kann, oder nur unter bestimmten Bedingungen mit gewisen Einschränkungen.

Hier ist ne tolle Übersicht: PWA iOS Limitations and Safari Support: Complete Guide

Firefox 147 ist da und kann jetzt Anchor-Positioning und die Navigation API (neuer Ersatz der History API).

Nach dem ganzen Drama hat Chrome jetzt JpegXL gemergt. Google hatte sich immer dagegen gewehrt, weil es ja AVIF und WebP gibt.

Modern Web Weekly hat einen tollen Beitrag zum neuen interestfor-Attribut. Erklären auch nochmal command/comandfor sowie popovertarget.

Firefox 145.

Es gibt eine neue Navigation API, mit denen man Client-Side linking machen kann. Als Alternative zur History API.

Chrome baut an einer neuen API, mit der man Content preloaden kann: <script type="speculationrules">

HTML Tags Memory Test

CSS content-visibility (for React devs).

The content-visibility CSS property controls whether or not an element renders its contents at all, along with forcing a strong set of containments, allowing user agents to potentially omit large swathes of layout and rendering work until it becomes needed. It enables the user agent to skip an element’s rendering work (including layout and painting) until it is needed — which makes the initial page load much faster.

MDN.

In HTML können manche Elemente ja nicht in anderen enthalten sein. Z. B. darf ein div nicht in einem span sein.

Manchmal ist man sich da nicht so sicher. Neulich hab ich auch überlegt, ob ein div in einem label sein darf und die Antwort zu finden hat echt gedauert. Hier kann man das nachschauen.

@starting-style ist mittlerweile ganz okay supported (Firefox fehlt noch, 129 kommt aber nächste Woche) und CSS-Sizing mit calc-size wurde vor 5 Tagen in den Standard gemergt. Chrome wird es in in der nächsten Version releasen, alle anderen Browser nicht. Damit kann man jetzt nach height: auto animieren und transitionieren. Mit progressive-enhancement-Techniken kann man es ja trotzdem schon nutzen.

WDS hat dazu gebloggt.

WebKit zieht eine gute Bilanz aus dem Bestreben, das Web mehr interoperabel zu machen. In der Liste darunter sind auch ein paar coole, neue Features. Darunter das inert-Attribut, font-size-adjust, @starting-style. Gerade das letzte sieht sehr spannend aus.

Ich finde es schön, dass die Browserhersteller zusammenarbeiten. Wenn man aber liest, auf was die sich so bei der Umsetzung konzentrieren: Das sind größtenteils alles neue Features, die sie am Ende wahrscheinlich eh alle umsetzen würden. Da liegt nicht wirklich der Fokus darauf, die Sachen zu fixen, bei denen die Browser schon länger divergent sind.

Aus der Sammlung “HTML-Sachen, die man nicht kennt”, hier noch ein post: Those HTML Attributes You Never Use

Uncommon Use Cases For Pseudo Elements (2019)

Neue Dinge in CSS und HTML in 2023.

Neu: HTML Sanitizer API, und die kommt mit Element.setHTML() für ein .innerHTML für untrusted Input.

HTML hat seit Kurzem ja ein Dialog-Element. Jetzt bald kommt das Popover-Element. Mehr hier.

Die neue React-Docs sind jetzt live.

HTML+CSS: The Double Emphasis Thing

Das img-Element hat ein decoding-Attribut, mit dem man sagen kann, ob das Bild asynchron oder synchron dekodiert werden soll. Gibt’s auch schon länger (Chrome 53, Firefox 63).

Interessant: Das Globale nonce-Attribut in HTML. Interessant für alle, die CSP machen.

24 Lesser-Known HTML Attributes You May Want to Use.

Die meisten waren schon hier im Blog, aber es ist ‘ne schöne Liste.