The weather is better than expected and so we’re staying a night longer than planned. Good times!
Remapping ⌘` to ⌘^
I only found out once I switched to an English keyboard layout that macOS has a useful and intuitive shortcut to toggle through windows of the current foreground app: ⌘` (CMD-backtick).
This makes perfect sense on an English layout, because the backtick key is right above the Tab key. And so it’s a very similar shortcut as CMD-Tab, which toggles between windows of all currently open apps.
On a German keyboard layout, it’s the same shortcut by default: CMD-backtick. This makes no sense at all, because the backtick is next to the backspace and requires the Shift-key modifier, too.
Of course I was missing this handy shortcut once I switched back to a German layout again. And so I remapped ⌘` to ⌘^ to keep my muscle memory working for switching windows. Because the ^-key on a German layout has the same position as the ` on an English one.
Out and about on a short camping trip. The first of the year. While it’s been raining for most of the day, we’re still very much enjoying ourselves. It just always feels good spending time in and around the camper. Especially when it’s been a while. Looking forward to the next two days!
By the way: did you know about the fantastic “A boy and his dad” photo blog? Well, now you do! You’re welcome!
Time for some music again: been listening to “Those Once Loyal” quite often recently. Best Bolt Thrower album. And “Salvo” might be my favourite track.
Man, that bass sound! 🤘
Tooling and Hosting options research
At IndieWebCamp, we collected an overview of everyone’s publishing software tools and hosting providers. And tonight I am doing a bit of research. I’m a little overwhelmed by only going through all those options. Of course, there’s an almost infinite amount of additional options out there, too.
Anyhow, to help narrowing it all down, I thought I’d write down some of my current thoughts on what I might want from both my future publishing tool and workflow for this blog, as well as the hosting options. Here we go:
Tooling
- I’d like the software to spit out a static site in the end. This makes it more easily portable and hostable – even when I myself can’t any longer. It’s much simpler to copy a simple folder and host that somewhere, than being required to run a certain software and database in order to build the site.
- An obvious choice here are Static Site Generators (SSGs).
- The downsides of using those and deploying something static, is that I won’t have dynamic features like – for example – search, comments or Webmentions. Or at least I would need an additional external service for that, since the site wouldn’t be able to accept any data to be put into it.
- If I end up bending over backwards to make those things work with an SSG, wouldn’t it be better to simply use something dynamic like a CMS? Then I’d have all the freedom. Plus, I would probably have a form via which I could post to the site.
- And posting to my site via a web form is a must, to be honest. I want to be able to post from multiple devices. And be able to upload files (mostly images I guess), too. Being able to do so only via a non-mobile device would be a show-stopper, I think.
- There’s an option, though to use something like Netlify CMS on top of an SSG to have an SPA admin interface that adds content directly to my git repository. Certainly an interesting option.
- A way to import my Tumblr blog would be really handy.
- And a way to redirect those old URLs would make sense, too.
- If I go with a CMS, it’d be nice to not rely on a database. I get a little uneasy relying on something so complex as a database. It’s simply easier to read plain text files than it is to get stuff out of a DB again. And I feel using a database is not really necessary for a blog.
- Should be something I would want to use in the long run.
Hosting
- I’d like to manage as little of the tech as possible and is feasible. For example, I feel like managing a VPS is a little too much. Shared webspace might do the job. Or even simple static hosting.
- The servers should probably be located in Germany.
- Preferably a focus on being environmentally friendly, too.
- I favour large storage space over high performance (because I don’t think I have high demands).
- Free or almost free SSL certificates, including wildcard certificates. Probably should offer the Let’s Encrypt ones.
- If possible, use one provider for all projects.
Phew. And that’s just some of the things I‘m considering. Running a risk of overthinking this and never get anything done. I feel this is important, though. Especially to choice for the software.
PWA notes
Making my Focal Length Equivalent utility a PWA at IndieWebCamp last weekend I made a few notes, which I thought I’d share:
- While iOS 12.2 does use the manifest.json file for most configuration options, it does not use the
iconsdeclaration. The icons are still specified via the<link>tag in the<head>. - And to make an icon actual appear on the home screen of iOS devices I found the
rel-attribute’s value must only containapple-touch-icon. With any other additional value – likeicon, for example, which is used for on Android non PWA-sites – it would not show it. It would always render the standard screenshot-icon. - Having said that, I’m not 100% certain about this. Because I also found that even when changes were deployed, iOS would sometimes still use some cached setting from a previous
<head>oder manifest.json configuration. Even after multiple refreshes of the page. So that was a bit tedious to debug. - As I found out you can have a
<noscript>tag in your<head>to only load certain (fallback) resources when JavaScript is disabled. Now, I wonder how this works in conjunction with a service worker and offline functionality. Because when no network request is made, my service worker will not cache them. Would it then make sense to manually cache them the first time the SW runs? Hm… haven’t done any testing around this. But I assume the SW doesn’t even kick in when JS is disabled, and therefor caching these resources is pointless, since a network request has to be made anyway. Actually, that’s probably the case and I have hereby answered my own question. Anyhow, I leave this rambling here, because that was something I wondered about.
More useful links
IndieWebCamp Recap
It’s Sunday evening, and I’m back home from two very enjoyable days (and one night, too) at IndieWebCamp Düsseldorf 2019.
I met lots of friendly and interesting new people, had interesting discussion and conversations, learned new things and was also productive implementing new technologies on one of my projects.
Saturday
Day one of the camp was the “Discussions” day: after the introduction round, everyone gathered to suggest discussions on IndieWeb-related topics. I spent my time at “URLs: How?”, “Offline Strategies”, “Hosting, SSG vs CMS vs Custom”, “Travel Data & Posts” and “Safety”. I learned something new in every one of them and/or contributed, too.
“Hosting, SSG vs CMS vs Custom” was maybe the most immediately interesting to me, since I’m keen to move my blog, and so I suggested this session myself. I was interested in how other folks publish to, host and deploy their own site. Everyone in the room shared their setup, which was absolutely fantastic! Now, I need to take some time, take those notes and research how I want to continue publishing this blog.
Sunday
Sunday was Hacking Day.
That means, whatever you fancied to work on, you simply did – either on your own or with (the help of) others.
I myself added a Service Worker to my “Focal Length Equivalents” site and also made this a “Progressive Web App (PWA)”. A topic I wanted to start with for a long time and now I finally did.
I used Jeremy’s Minimal viable service worker script, and modified it a little to suit this page’s needs even better. Following Daniel’s suggestion, I deployed this via GitHub Pages; I needed to switch hosts, because I needed a (free) SSL certificate. Because serving your site over HTTPS is a prerequisite for using a service worker (and thus making the site available offline). Then I created a quick icon and followed the “Add to Home Screen” guide to turn the site into a PWA.
So, when you now go to https://danielpietzsch.github.io/fl/, it’ll be available offline (after that first visit of course), and you can also add it to your home screen on iOS or Android, and it’ll behave very similar to a native app.
The final step would be to actually use my custom subdomain again, which so far hasn’t worked, unfortunately.
At the end of the day, everyone demoed what they’ve worked on. I was super impressed by all the things that got done.
A big thanks to Marc, Tantek, Aaron, Jeremy and Joschi for making all this happen! This will not have been my last IndieWebCamp for sure!
Originally, I thought I could easily write up my summary of day one of the IndieWebCamp here in Düsseldorf tonight. But instead I ended up in a Restaurant and only returned close to midnight. So, no summary. But I had a great time, meeting lots of interesting people. Looking forward to day two.
Super simple Dark Mode
I just read the article “Dark Mode Support in Webkit” on the Webkit blog. Among other things, it describes how you can opt-in to have your website auto-darkened by Webkit (which means Safari in this case):
Not all web content is simple. For this reason Safari and WebKit do not auto-darken web content — documents will need to opt-in to dark mode. The main way to signal that your content supports dark mode it to adopt the new
color-schemestyle property […].Specifying the values
lightanddarkon the root element lets the engine know both modes are supported by the document. This changes the default text and background colors of the page to match the current system appearance. Also standard form controls, scrollbars, and other named system colors change their look automatically.
So, to opt-in, you add this bit of CSS:
:root {
supported-color-schemes: light dark; /* For current Safari versions */
color-scheme: light dark; /* Available with Safari TP 81 */
}
This will tell the browser that your website supports both light and dark modes, and will automatically darken your website when dark mode is selected in the OS preferences. Without any additional CSS (via @media (prefers-color-scheme: dark)). That’s a super simple and convenient way to have a dark theme.
Existing issues
[UPDATE 28.05.2019]
Got some feedback from the original article’s author:
However, it is not an auto-dark mode. That property gives you dark mode ready defaults for the body background and base text color, along with form controls. Any custom colors will need handled with the
prefers-color-schememedia query.
And I also re-read the article and the spec regarding this topic. And the issues listed below are no bugs. According to the spec, the user agent should indeed only change the background and text colour plus form elements, and not much more.
So, I think the below still applies. But, that it’s not “perfect” is intentional and merely gives you a mechanism to opt-in to support a very basic version and is expected to be further extended and adjusted via custom CSS statements inside a prefers-color-scheme block.
[UPDATE END]
This automatic dark mode is not perfect. While updating my Focal Length Equivalent page to use it (which previously had a complete custom – but very similar – dark theme already), I noticed a few things:
:hoverand other pseudo-classes are not darkened.border-colorandoutline-colorare not darkened.- Link colour don’t seem to get adjusted.
For border-color and outline-color, I could remove those statements from the standard (light mode) CSS to rely on the page’s standard colours. Then, the borders got auto-darkened, too. For the :hover-issues, I kept my custom CSS rules around.
Verdict
Relying on this auto-dark mode reduced the number of CSS statements I had to overwrite in the @media (prefers-color-scheme: dark) section of my stylesheet and made it much simpler.
Generally, for simple sites likes this one, I think it’s very handy to be able to rely on Webkit to do most of the dark-mode work for you. And then only adjust things where you see the need for.
I am definitely going to experiment with this some more.
clamp()
Just learned about the CSS clamp() function. This would actually be really handy for specifying a width based font size, without the need for an extra media-query.
Unfortunately, this does not have any browser support right now.
I amended my photo journal’s design once again. I wanted to make all images fit completely on screen, no matter what the actual dimensions of the image are.
That images wouldn’t fit was mainly an issue with photos shot in portrait orientation or in square format. If a screen was wider than it’s tall – typical for most non-mobile devices – and you had less than 960px available vertical space, those images would be cropped. That’s no longer the case. And I find it much more enjoyable when the whole picture fits on screen.
As a minor downside, this update also decreases the size of landscape-oriented images, which would still have fitted previously. But this way, everything’s aligning well and portrait and landscape images still have the same size.
Ok, finally put up the scanner at the new apartment. Catching up on scanning…
October 2018 – Daniel Pietzsch’s Photo Journal
photojournal.danielpietzsch.com
In Paris.
My selected photos from last October. Mostly shots from Paris.
I’m pretty happy with how they turned out. Especially the ones from the Rolleiflex.
Just finished developing two rolls of APX 400 rated at 1600. It’ll probably be the last two pushed 35 mm rolls for a while. Because while in winter and standard time, I mostly tend to rate my 400-speed film at said EI 1600, I usually rate it at box speed during daylight savings.