Last.fm 2018

2018 habe ich (natürlich) wieder sehr viel Daft Punk gehört. Aber dass es der Soundtrack zu „Black Panther“ zum Top-Album schafft, hätte ich nicht gedacht. Und möglicherweise habe ich mein Solowerk für Weihnachten etwas zu oft gehört …

Uhr-Icon mit Uhrzeit

Nachdem ich vor einigen Tagen schon von einem Icon-Font zu SVG-Icons gewechselt bin, um das Rendering ein wenig zu beschleunigen, habe ich mir heute morgen noch ein kleines Gimmick zurecht gebastelt.

Das Uhr-Icon gibt nun die Uhrzeit des Posts wieder. Vorher war es lediglich ein statisches Vier-Uhr-Icon:

16:00 Uhr

Dank SVG Transforms lassen sich die Pfade für die Zeiger aber wunderbar drehen, so kann ich z.B. jetzt 18:06 Uhr darstellen:

18:06 Uhr

Den Stundenzeiger rotiere ich dabei jeweils um 30° (360° / 12), den Minutenzeiger jeweils um 6° (360° / 60):

<svg version="1.1" viewBox="0 0 12 12" xmlns="http://www.w3.org/2000/svg">
  <title>18:06 Uhr</title>
  <circle cx="6" cy="6" r="5.425" stroke="black" stroke-width="1.15" fill="none"/>
  <line x1="6" y1="6" x2="6" y2="4" stroke="black" stroke-linecap="round" stroke-width="1.35" transform="rotate(180 6 6)"/>
  <line x1="6" y1="6" x2="6" y2="2.5" stroke="black" stroke-linecap="round" stroke-width="1.35" transform="rotate(36 6 6)"/>
</svg>

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.

Die perfekte Komponenten-Bibliothek?

Ich versuche mich gerade am Schaffen einer React-basierten Komponenten-Bibliothek für das Blog der Zukunft und vielleicht sogar noch viele andere Seiten. Ziel soll es sein, irgendwann mittels Lerna oder einem anderen Monorepo-Tool jede Komponente einzeln ziehen zu können, quasi so:

import Button from "@mrcgrtz/elements/button";

Mal schauen, ob mir das gelingt. Denn in der Firma haben wir gerade folgendes Problem: Wir haben eine von unseren React-Apps getrennte Komponenten-Bibliothek geschaffen, die zwar fürs Code Sharing wunderbar ist, aber nicht fürs Code Splitting – denn tatsächlich lädt man immer das komplette Bundle mit allen Komponenten. So hat man schnell ein paar hundert Kilobyte mit React-Komponenten, die man gerade gar nicht braucht.

Daher gibt es nun zwei Ideen: Die erste Idee ist, das „Haupt-App“-Repo mit dem Komponenten-Repo zusammen zu packen. Mal abgesehen davon, dass eine Git-Historie dann sicher flöten geht und ich sowas ganz, ganz schlimm finde, verlieren wir so auch den Sharing-Vorteil – allerdings ist das sicher auch der schnellste Weg. Und den kenne ich so quasi schon von weg.de, wo wir das Frontend in einem einzelnen Repository hatten. Die andere Idee ist die eines Monorepos für Komponenten und sich so nur das zu ziehen, was man braucht.

Das hoffe ich jedenfalls. Ich werde also wohl mal ein paar Dinge ausprobieren.

Good bye, Edge

Die Gerüchte haben sich bewahrheitet: Microsoft gibt EdgeHTML zugunsten von Chromium auf. 😔 Damit befinden wir uns wohl wieder auf dem Weg zu einer Monokultur á la IE6, denn jetzt ist nur noch Firefox der einzige Nicht-Chromium-Browser – jedenfalls unter Windows und auf Android. Und wie sagt es das Smashing Magazine so schön:

So, please, for the love of Web: TEST IN FIREFOX.

Also: Testet auch immer alles im Firefox, Internetfreunde!

Mozilla hat natürlich eine ähnliche (und meiner Meinung nach absolute vertretbare) Meinung zum Thema.

Ich hab Edge immer gemocht, und hätte ich Windows genutzt, wäre er vermutlich mein Default-Browser geworden, so wie Safari das auf macOS und iOS geworden ist. Good bye, Edge!

Microsoft baut einen eigenen Chromium-Browser, um Edge zu ersetzen

Holy shit. Demnächst also nur noch Blink, WebKit und Gecko.

Ich weiß noch nicht, wie ich das finden soll.

„Exclude checkins“

Supergutes neues Feature von OwnYourSwarm:

So nerve ich Euch hoffentlich nicht mehr mit wirklich jedem mothereffin’ Swarm-Checkin, sondern nur noch mit den (hoffentlich) relevanteren Checkins! Whoop whoop! 🎉

This is Eliza Cassan …

… reporting to you live from Picus.

Grundgütiger. 😳

Was tun mit Flickr?

Dank Markus bin ich darauf aufmerksam geworden, dass Flickr – jetzt wo es zu Smugmug gehört – Nicht-Premium-Konten drastisch beschränkt:

Ab dem 8. Jan. 2019 sind nicht premium Accounts auf insgesamt 1000 Fotos beschränkt. Hat man mehr als 1000 Photos kann man keine mehr Hochladen.

Okay, 1.000 Fotos sind immer noch fünf mal so viele wie sie bis 2013 im Gratis-Konto angeboten haben. Und man denkt erstmal: „Okay, sind halt nur die letzten 1.000 Fotos sichtbar, wie damals mit den 200 Fotos.“ Aber der Hammer ist tatsächlich: Im Kleingedruckten auf der aktualisierten Startseite steht, dass bei Überschreitung des Limits alle anderen gelöscht werden! 🤬

After February 5, 2019, free accounts that contain over 1,000 photos or videos will have content actively deleted — starting from oldest to newest date uploaded — to meet the new limit.

Ich weiß noch nicht genau, was ich jetzt mit meinen über 1.200 Fotos dort tun werde. Ich habe jetzt nicht so starke Gefühle Smugmug gegenüber wie Markus, und könnte ihnen durchaus die 50 Dollar pro Jahr für meinen teils echt alten Content dort sowie fürs Instagram-Backup in den Rachen werfen. 🤔

In jedem Fall ist aber jetzt wohl der Moment gekommen, sämtliche Flickr-Fotos herunterzuladen: Zum einen hat nicht jedes Foto auch ein lokales Backup. Und zum anderen kann ich dann das Ganze in guter own-your-data-Manier hier veröffentlichen (was ja seit einigen Monaten ohnehin automagisch passiert).

Ein Menü mit mehr Accessibility

In den letzten Tagen habe ich immer mal wieder an meinem Hamburger-Menü auf kleinen Devices gearbeitet und es zugänglicher gemacht. Zunächst einmal war es ja sowieso schon eine Checkbox, was den einfachen Vorteil hat, dass das Menü auch dann noch funktioniert, wenn JavaScript einmal deaktiviert oder kaputt ist: Ich prüfe im CSS einfach auf die :checked-Pseudoklasse des input und zeige abhängig davon mittels general sibling combinator das Menü an oder eben nicht:

nav input:checked ~ ul {
  display: block;
}

So etwas mit einem button umzusetzen ist ohne JavaScript nicht möglich.

Weiterlesen …