Du hast nach Beiträgen mit diesem Tag gesucht:
CSS

App-Icons mit Squircle-Radius

Mit clip-path kann man App-Icons auch einen Squircle-Radius verpassen:

<img src="https://kegelclub-tüddern.de/assets/app/icons/icon-384.png" width="200" height="200" alt="Kegelclub">
img {
  border-radius: 22%;
}

@supports (clip-path: path("")) {
  img {
    border-radius: unset;
    clip-path: path("M100,200c43.8,0,68.2,0,84.1-15.9C200,168.2,200,143.8,200,100s0-68.2-15.9-84.1C168.2,0,143.8,0,100,0S31.8,0,15.9,15.9C0,31.8,0,56.2,0,100s0,68.2,15.9,84.1C31.8,200,56.2,200,100,200z");
  }
}

Demo auf CodePen

postcss-opacity-percentage

Nachdem Stylelint alpha-notation: percentage per Default in stylelint-config-standard aktiviert hat, habe ich dieses PostCSS-Plugin geschrieben, um prozentuale Werte für opacity zu kompatibleren Float-Werten zu transformieren.

Bin ich jetzt behindert?

In der Umfrage State of CSS 2021 (an der jeder Web-Entwickler unter Euch teilnehmen sollte) gab es gegen Ende bei den demografischen Angaben diese Frage nach einer möglichen Art der Behinderung:

Und da geriet ich ins Grübeln: Zählt meine Ellbogensteife nun zu den Mobilitätseinschränkungen, nach denen dort gefragt wird? Es ist doch (hoffentlich) nichts Dauerhaftes! Und so kreuzte ich – aus falschem Stolz wohl – nichts an.

Dennoch erwische ich mich noch Tage später, wie ich über diese Frage nachdenke. Ich bin seit über vier Monaten krank geschrieben, weil ich nicht lange mit Tastaturen arbeiten kann, ohne dass nach kurzer Zeit überanstrengte Schulter- und Handgelenke schmerzen. Hätte ich also vielleicht doch etwas anderes ankreuzen sollen? Ich predige im Job immer und immer wieder, dass Accessbility im Web nicht nur heißt, die Seiten für blinde Nutzer zugänglich zu machen – aber wenn es um einen selber geht, wird man schnell zurückhaltend. Ist doch alles nicht so schlimm, ne?

Statische Ressourcen besser cachen

Ich habe vor einigen Wochen die Website meines Musikvereins einem Relaunch unterzogen. Nicht nur das Frontend ist erneuert, auch den kompletten technischen Unterbau habe ich neu geschrieben. So ist auch das Caching statischer Ressourcen neu, also CSS, Skripte oder Bilder. Im Folgenden beschreibe ich, was ich getan habe. Vorab: Ich nutze kein CMS oder Framework.

Weiterlesen …

Adressleiste im iOS-Safari einfärben

Eine nette Sache, die im mobilen Chrome (und in einer Reihe von anderen Browsern) funktioniert, ist das Einfärben der Adressleiste. Man setzt einfach dazu einfach ein Meta-Tag:

<meta name="theme-color" content="lime">

Im iOS-Safari ist das nicht möglich, auch nicht mit dem Web App Manifest.

Beim längst überfälligen Redesign der Vereinsseite bin ich aber zufällig auf einen netten Effekt gestoßen: Mittels einer background-color auf dem body färbt diese Farbe die Adressleiste ein. Die „normale“ Hintergrundfarbe legt man dann auf dem direkten Kind-Element des Bodys. Zum Beispiel so:

body {
  /* this will color the address bar in iOS/iPadOS Safari */
  background-color: lime;
  /* reset body margin for full background-color of wrapper */
  margin: 0;
}

body > *:first-child {
  /* apply default background-color and “body” padding here */
  padding: 1em;
  background-color: white;
}

Das Ergebnis wäre dieses:

Ups, der Content ist zu kurz, die Hintergrundfarbe soll so aber nicht aussehen. Der Trick ist, jetzt noch eine Hintergrundfarbe auf html zu setzen:

html {
  background-color: white;
}

Idealerweise ist es die gleiche Farbe wie die des ersten Kind-Elements. Aber man kann natürlich auch etwas kreativer sein und eine ganz andere Farbe nehmen:

Hinweis am Rande: Im macOS-Safari sorgt die Farbe übrigens für das Einfärben der Scrollleiste.

Den „Dark Mode“ mit CSS abfragen

Mein Blog präsentiert sich seit Kurzem im Dark Mode, wenn das System und der Browser das unterstützen. In der Safari Technology Preview für macOS Mojave ist das zum Beispiel bereits möglich:

Seit Jahren verwende ich bereits dunkle Themes für die Editoren meiner Wahl, darum mag ich auch einen systemweiten Dark Mode. Ich finde ihn viel angenehmer für die Augen, und längere Texte lassen sich so – gerade am Abend – viel besser lesen. Darum denke ich auch, dass jedes Blog ein dunkles Theme mit sich bringen sollte. Ich habe das hier kurzerhand mit CSS Custom Properties (oder einfacher gesagt: CSS-Variablen) gelöst, etwa so:

:root {
  --text: gray;
  --background: white;
}

@media (prefers-color-scheme: dark) {
  :root {
    --text: white;
    --background: gray;
  }
}

Schon ziemlich lässig.

Entdeckt habe ich das übrigens ursprünglich in den Show Notes zu ATP #299 und dem anschließenden Forschen im CSS. Dort war zunächst das bereits seit dem IE9 in allen großen Browsern unterstützte @media (color-index: ...) im Einsatz, der technischen Basis von prefers-color-scheme.

Die Syntax ist allerdings deutlich kruder:

  • @media (color-index: 48) ist das Pendant zu @media (prefers-color-scheme: dark), weil 48 der Keycode für 0, dem Hexidezimalwert von Schwarz ist.
  • @media (color-index: 70) ist das Pendant zu @media (prefers-color-scheme: light), weil 70 der Keycode für F, dem Hexidezimalwert von Weiß ist.
  • @media (color-index: 22) ist das Pendant zu @media (prefers-color-scheme: no-preference).

Völlig Banane.

Andy Clarke geht in seinem Artikel Redesigning your product and website for dark mode noch etwas mehr ins Detail und zeigt auch einige typografische Anpassungen für den Dark Mode auf.

CSS verkleinern mit CSSTidy

Zum Bloggen gezwungen, wieder mal. Diesmal aber nicht von Ina, sondern vom Kollegen gegenüber. Es geht sich um das Zusammenführen und Verkleinern von CSS-Dateien.

Weiterlesen …

hasLayout

Ich wusste doch, dass es gut war, für neu.de die CSS-Klasse .hasLayout einzuführen:

.hasLayout {
  zoom: 1;
}

Was uns das bringt, erfährt man in dem wirklich hervorragenden Artikel Über hasLayout – Das Konzept des IE/Win.

Via Gerrit.

Rounded Corners: Out! Square Corners: In!

Während wir uns in der Firma noch über runde Ecken und mein neues Datenbankformat »CSSsql« beömmeln, gibt es bei Drivl schon den neuesten Hit:

So macht Ihr eckige Ecken mit CSS!

Der Feuerkäfer ist da

Es gibt jetzt nur noch zwei Erweiterungen, die man als Webentwickler unbedingt für seinen Firefox haben sollte:

  • Firebug ist jetzt endlich in der Version 1.0 erhältlich, wenn auch erstmal nur als Beta. Die Erweiterung bietet Werkzeuge zur HTML-Analyse, CSS-Fehlersuche und -Layout, lässt das DOM erkunden, die Kommunikation mit dem Server analysieren und JavaScript debuggen oder testen.
  • Die Web Developer Toolbar ist wie eh und je auch ein Muss für Webentwickler. Sagt ja allein schon der Name. 🙂

Download- und Installationsbefehl!