Ein Blog

Posts mit Tag "html"

Es gibt jetzt ein Proposal fĂŒr das W3C: WebSkil (hier die offizielle Seite). Ziel ist es, agentische FĂ€higkeiten in den Browser zu integrieren und die auch im Browser-Kontext in isolierten Workern laufen zu lassen. Es baut auf WebMCP auf. llms.txt gibt es ja auch noch. Aber das ist ja eher fĂŒr Agents, die außerhalb des Browsers laufen.

Das ganze ist ja alles noch ziemlich neu. Da bin ich mir ech tunsicher, ob jetzt ein schon guter Zeitpunkt ist, das in Standards zu integrieren. MCP wurde ja gerade erst stark erweitert in Version 2.0. Die Entwicklung ist allein innerhalb des letzten halben Jahres so schnell vorangeschritten, dass wir da vielleicht etwas warten sollten. Das erinnert mich alles an die Anfangszeit von TypeScript, wo es 100 Sachen fĂŒr das gleiche gab, es alle 2 wochen was neues gab und es erstmal 5-6 Jahre gedauert hat, bis sich Lösungen etabliert haben, die sich nicht stĂ€ndig Ă€ndern.

Ihr kennt sicher open graph meta tags oder habt sie schon im Einsatz gesehen. Mit denen kann eine Webseite verschiedenen Clients ermöglichen, schönere Link-Previews anzuzeigen. Mit großen Vorschau-Bildern oder sogar -Videos. OGP ist ein offener Standard. Dann kam Twitter und hat fĂŒr sich selbst eigene HTML-Tags definiert. Die haben dann andere Clients auch verwendet und sind deshalb mittlerweile nicht mehr nur ein Twitter-Ding. Man benutzt mittlerweile beides. Das geht auch teilweise ĂŒber einfache Video-Embeds hinaus. Wer schonmal einen TikTok-Link bei Discord verschickt hat, sieht, dass dort dann nicht der native Video-Player ist, sondern ein komplett von TikTok servierter HTML-IFrame.

Wo wir bei Discord sind: Discord selbst hat ja fĂŒr Bot-Interaktionen und WebHooks ein eigenes Komponentensystem mit ganz rudimentĂ€ren Layout-Komponenten, Buttons, Dropdowns etc. Sie haben jetzt den Twitter gepullt. Eine Webseite kann jetzt ĂŒber Meta-Tags solche Komponenten definieren, die dann in Discord als richtige Components gerendert werden. Es gibt ein paar EinschrĂ€nkungen aber im Prinzip könnte das die nĂ€chste Stufe der OGP-Twitter-Meta-Tags sein.

Wer das mal im Einsatz sehen will, hier ist ein Demo-Link, den ihr mal in Discord pasten könnt.

DarĂŒber hinaus sind hier noch ein paar weitere Ressourcen (die ich jetzt eigentlich nur fĂŒr mich noch hier notiere):

Ich berichtete mal ĂŒber navigator.sendBeacon. Damit kann man HTTP-Requests absetzen, die der Browser dann macht, sobald der User den Tab schließt. sendBeacon hatte den Nachteil, dass man nut GET-Requests machen kann.

Chrome hat da mal wieder was gebaut: fetchLater. Das ist identisch zum normalen fetch, nur dass es wie sendBeacon erst abschickt, wenn der Tab geschlossen wird. Sie gibt nur kein Promise zurĂŒck, sondern ein FetchLaterResult, wo einfach nur drin steht, ob das Einreihen des Requests geklappt hat.

Wer schon lĂ€nger ein bisschen HTML und CSS macht, wird sich sicher noch ein einige Hacks von frĂŒher erinnern. Hier gibts zwei tolle Artikel mit ein bisschen Nostalgie dazu: Antiquated HTML Snippets and Artefacts + CSS Curiosities of the Past. Und das umgehekrte dazu: New Things You Should Know About HTML Here in Mid 2026

Chrome hat eine neue Origin Trial: Declarative partial updates

Man kann damit Platzhalter im HTML definieren:

<ul id="results">
  <?start name="results">
  Loading

  <?end>
</ul>

Und dann in derselben Server-Antwort (Ă€hnlich wie Server-Sent-Events) den Stream offen lassen und noch weitere Daten nachschieben, die dann dort eingesetzt werden. Z. B. fĂŒr das oben:

<template for="results">
  <li>Result One</li>
  <?marker name="results">
</template>

Gibt da noch ein paar mehr Use-Cases, die im Chrome-Blogpost gezeigt werden.

Wilde Sachen, die man mit dem neuen stylebaren <select> machen kann: Abusing Customizable Selects.

Die nÀchste Safari-Preview kann jetzt stylebare <select>s.

Josh hat einen schönen, neuen Artikel ĂŒber (Sprite-)Animationen in HTML/CSS: Sprites on the Web.

Wer schonmal eine PWA gebaut hat, der wird erfahren haben, wie nervig das ist, wenn man einen “klick hier zum Installieren”-Button bauen muss. Da braucht man erstmal JavaScript fĂŒr und man muss auf irgendwelche Events lauschen, die manche Browser ĂŒberhaupt gar nicht emitten.

DafĂŒr gibt’s jetzt ein bald vielleicht HTML-Element: <install>.

Hier ist eine Testseite. Chrome hat es gerade im Origin Trial.

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.

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">

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.

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.

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.