For the last five months I’ve been writing some form of text every single day. And last week I stopped. I didn’t specifically plan for that – at least not at that point. But it just happened. I missed one day. And then didn’t write the next day, either, etc etc.
I had occasionally thought about giving up on this project, because it often felt like a chore. It was too much self-imposed pressure for me to write something every day. So, I think it was just a matter of time. But that I stopped already was accidental. I guess once I missed a day, the pressure fell and I simply thought “fuck it, who cares!?”.
I still want to write more regularly than I did before this project, though. I hope I’ll find the motivation to do so, even without a fixed schedule. Time will tell.
IndieWebCamp keeps inspiring me. Having had so much interesting conversations with interesting people that care about similar things, motivates me to work on my own homepage, blog and other web projects.
And so I’m currently still excited about IndieWeb stuff and am researching potential tools, hosting options and workflows for my personal sites.
And I’m still fancying going static with my blog, too. Most of my other projects are static already. It’s either indeed a plain hand-written static site, or generated via Jekyll, my SSG of choice (so far).
While researching, I found the following (somewhat random) articles and resources interesting and helpful so far.
I think as a first step, I might neglect the “hosting” part of my upcoming solutions a little bit. I want the hosting and deployment to be as simple as possible. And so I might sacrifice my other principles about server location and using renewable energy sources in the short term. I’m currently looking into these hosting options:
Am Sonntag kann man hier in Deutschland seine Stimme zur Europawahl 2019 abgeben. Ich habe bereits diese Woche meinen Stimmzettel per Briefwahl abgeschickt.
Wahlkämpfe an sich ignoriere ich meistens so gut es geht. Klar, man bekommt verstärkt (angebliche) Positionen und Leistungen der Parteien mit, aber ich stempel’ die Plakate etc. unter “Werbung” ab. Es ist mir auch äußerst suspekt, dass sich anscheinend viele Leute davon beeinflussen lassen.
Mich interessiert hauptsächlich die grundlegende Haltung und Position einer Partei und wofür sie sich in der Tat in der Vergangenheit eingesetzt hat. Und da tut sich bei den einzelnen Parteien immer nicht viel. Seit Jahren gibt es für mich eigentlich nur zwei, die für mich wählbar sind.
Und auch wenn ich den Wahlkampf versuche zu ignorieren, checke ich vor einer Wahl trotzdem nochmal verstärkt, ob “meine” Parteien für mich immer noch die beste Wahl sind, und ob die nicht-wählbaren Parteien immer noch solche sind. Das war in den letzten Jahren immer der Fall.
Und so brauchte ich auch dieses Mal nicht lange überlegen.
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.
While iOS 12.2 does use the manifest.json file for most configuration options, it does not use the icons declaration. 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 contain apple-touch-icon. With any other additional value – like icon, 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.
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.
“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.
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!
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-scheme style property […].
Specifying the values light and dark on 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.
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-scheme media 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.
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.
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.
I’m not quite sure yet what my personal goal is going to be during this year’s camp. I feel like my next step towards independence is to finally dump Tumblr, and start hosting my own site.
But I’m still undecided what stack to use: a static site generator or a dynamic site? With database or simply flat files? An existing software or build something from scratch? Hosting on a VPS, simple webspace, or use a PaaS (like Heroku or Netlify for example)?
Maybe I can get some inspiration at the event and start a little prototype.
At some point I want one. A Widelux. A Horizon. Or even an XPan. Maybe a cheap Sprocket Rocket at first.
I was just looking at some of Jeff Bridges’ photos, and really like how he uses the Widelux to document the making of the movies he’s starring in. I mean, they are interesting and unique pictures to begin with, but that wide frame makes them even more so.
I recently had to pull-develop a roll of APX 400, which I unintentionally had exposed at EI200 or even EI100. And I couldn’t find developing times for XTOL online for pulling APX. But I found an entry in a Flickr group, that suggested using 2/3s of the original developing time per stop pulled. That sounded reasonable. So, for my APX 400 in XTOL 1:1, this meant instead of 12 minutes at 20 ℃, I developed for 8 minutes. The negatives came out looking fine.
(This little accident happened, because I loaded APX 400 via a bulk-rolled canister with a 200 ISO DX code into my Leica Mini, which is an automated camera, where you can’t set the ISO manually. And the DX code was even partially covered by tape that I used to label the film. The tape meant, the camera might not have been able to read the DX code at all, making it fall back to its default ISO setting. Which is probably ISO 100 from what I gathered online. Either way, I ended up with an overexposed roll. The question was if it was one stop or two. I decided it was two. But I only compensated for one stop in development, as I thought it’s probably safer to overdevelop a little bit, rather than ending up with too-thin negatives in case it was actually only one stop overexposed.)
For my photo journal, I wasn’t sure how to mark up the piece of HTML that makes up a photo element. And re-reading the spec now, I am still not quite sure.
The site features monthly entries with all the selected photos from that month. Each photo element on a page contains the image itself, plus an optional caption. So I thought it makes sense to group them inside a parent tag (for grouping and styling reasons, as well as semantically). And kind of knowing about the <figure> element, it seemed obvious at first to use exactly that, together with <figcaption>. Like so:
The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.
[…]
A figure element’s contents are part of the surrounding flow. If the purpose of the page is to display the figure, for example a photograph on an image sharing site, the figure and figcaption elements can be used to explicitly provide a caption for that figure.
As far as my site is concerned, the photos themselves are the main content or flow. I’m not illustrating an article. I’m not referencing images. The images are the article.
And the second quote even speaks specifically of “an image sharing site” – which my photo journal is. But that reads as if the spec speaks about a web page that hosts a single figure – i.e. one that can be referenced from somewhere else.
And that’s why I think <figure> is not the appropriate HTML tag for my use case.
Am I interpreting this incorrectly? Is this nitpicky nonsense? I don’t know. But for now, I decided against <figure>.
I must say, the older Zoe gets, the more enjoyable and interesting I find it to spend time with her and watch her play and explore. She’s 19 months old now, and it seems like almost every day she’s learning something new.
I’m more and more getting used to a German keyboard layout again. But muscle memory really takes a while to re-adjust after around eight years on an English layout. And I remain sceptical I can ever be as efficient on a German layout when programming. There are just too many common characters “hidden” behind a “shift”-, “option”- or even “shift-option”-shortcut. Symbols like semicolon, brackets, curly braces or backticks are all more cumbersome to type on a German keyboard. And on the Mac terminal I no longer like to set the “Use Option as Meta key”-option – like I used to, to get word-deletion and -skipping – because the pipe (”|”) character is “option-7″ and a backslash is fuckin’ “shift-option-7″. And neither works when that option takes over “option”.
The upside is, I can type German umlauts again easily. Hüürääy!
