2024-11-02 ⇒
2024-08-16 ⇒

Updated: Neonix

A significant update of Neonix was made on 2024-08-16 @ 11:20 AM EDT.

→ Add update regarding new location of Bill Mill's "modern unix tool list"

The post was originally published 2024-06-06 @ 03:35 PM EDT.

This is an automatically generated post.
2024-07-01 ⇒

Updated: The 'iffy' XML namespace

A significant update of The 'iffy' XML namespace was made on 2024-07-01 @ 02:40 PM EDT.

→ Major revision of iffy:synthetic, generalize iffy:initial, iffy:update, iffy:update-history, define iffy:uid.

The post was originally published 2024-05-13 @ 04:10 AM EDT.

This is an automatically generated post.
2024-06-22 ⇒

Condensing updates that appear in digests

In the previous post, I claimed to be "finished" my exploration of handling updates.

Ha!

I don't like how my update notifications appear in digests — in e-mail newsletters that gather up all the posts over a period of time.

There are two problems:

  1. Update notifications appear in digests as separate, cookie-cutter posts, which bury and dilute "real" posts.

    On websites, we can make synthetic update posts visually distinct to help guide visitors past them. We could do that in HTML mail digests too, but I think update posts will still put people off actually reading new material when they are going quickly through their e-mail, particularly when updates are more recent and therefore come before the "real" posts.

  2. Updates appear even for posts that are included in the current digest.

    feedletter digests always include the most recently seen version of a post, so from the digest reader's perspective, the "update" notification tells them about nothing that isn't already in the post.

To address this, I mean to do a bunch of things.

  1. I'm going to modify the definition of iffy:synthetic, reversing course on my my current admonition that

    Applications that include iffy:synthetic as a direct child of channel SHOULD NOT also mark individual items as iffy:synthetic, unless there is some meaningful sense in which some items are more synthetic than others. It serves no purpose to mark every item of a feed iffy:synthetic when the channel is already so marked.

    Never mind.

    Until now, iffy:synthetic has been basically just a marker, so there was no point in marking posts twice. Marking at the channel level implied the syntheticness and the types at the item level.

    But now we'll reconceive of iffy:synthetic as also the carrier of the data on which the item content (in description, content:encoded, or atom:content) is based.

    The item content, of course, remains the post's HTML, whether it is a synthetic post or not. But we'll want the information we used to compose synthetic posts to be available, in an iffy:type-dependent way, inside item > iffy:synthetic. So even when a channel is marked synthetic, with a type that implies the type of elements, we will want explicitly to include an iffy:synthetic element in each item.

    For synthethic items of type UpdateAnnouncement — the relevant case here — we've already defined an element that carries most the relevant data, iffy:update.

    We'll also need the guid of the post updated. So we'll bring back iffy:original-guid, with a slightly modified role.

  2. I'll define a feedletter content Customizer that

    1. filters away upates to items already in the post;
    2. combines the remaining updates into a single notification post; and
    3. places that notification post at the end of the digest.

So. We have a plan!

Let's see if it works.

2024-06-20 ⇒

Updated: Sprouted

A significant update of Sprouted was made on 2024-06-20 @ 05:50 PM EDT.

→ Add bold update crediting Maggie Appleton for some of these ideas.

The post was originally published 2024-06-20 @ 03:05 PM EDT.

This is an automatically generated post.

Sprouted

➣  This post was meaningfully revised at 2024-06-20 @ 05:50 PM EDT. The previous revision is here, diff here. (See update history.)

I've finally "finished" my reaction to Chris Krycho's provocation, Feeds are Not Fit for Gardening. (ht Erlend Sogge Heggen).

I think I now have infrastructure sufficient to publish evolving content, that might start as an unfinished sketch and "blossom" over time (and with help and interaction from you, dear reader).

The approach I've taken — of course since I am an RSS fanboy — is to graft what I need on top of existing RSS infrastructure. Among RSS infrastructure, I include both conventional feed readers and "announcers": RSS consumers that notify parties about new items in ways that may be more disruptive than just another item in a well-populated feed.

An example on an announcer is my own feedletter, which notifies RSS items by e-mailing posts one at a time or in digests, and also by posting to Mastodon.

My approach is quite manual. No software determines when an "update" has been made. "Tweaks" — which may include correcting typos, reworking sentences, or even rewriting whole paragraphs without changing the intended meaning — shouldn't be notified as updates. Modifications, however big or small, that substantially augment or alter the content of the item usually should be notified. In my view, which is which is the author's judgment call. So authors manually add an item to their post's update history when they wish to provoke such a notification.

Once authors begin to define an update history, that history becomes appended to the end of posts. Example.

When authors declare a meaningful update, all they must provide is a timestamp. An atom:updated element will be included in the RSS item with that timestamp.

Authors also may provide a description, a "revision-spec" (usually a git commit identifier) for the revision superceded, and an author list (if authorship as well as content is changing with the update). Example.

The more authors provide, the richer the update history. Update histories will include any description given, along with links to the prior ("superceded") revision, and a diff between the updated post and the superceded revision.

Whenever a new update is declared, a synthetic post will be produced, whose publication date is the moment of the update, announcing the update. Example.

That post will have its own RSS guid and permalink. So, without requiring any change to the behavior of existing feed readers, followers will be notified of these updates.

The RSS items generated for these updates will be marked "synthetic", of "type" UpdateAnnouncement, so that announcers (for the moment only my feedletter, but please join in!) can decide whether they wish to notify these items.

They include a "hint" for announcers to adopt a Piggyback policy, meaning the synthetic update notifications should be included in digests and other multi-post announcements that include at least one not-piggyback post, but they should not trigger announcements on their own. Announcers are free to follow this hint, or to make a different choice.

For subscribers to notication services that accept the hint, synthetic update posts will not cause people to get spammed with "here's an update!" messages. That would be annoying. On the other hand, e-mail subscribers will not be notified of all updates to existing posts. One-at-a-time subscribers will see none of the update notifications. Digest subscribers will see update notifications only when the digest would also include at least one "organic" post. There is a trade-off to navigate between annoyance and information.

For posts intended to evolve over time, that might invite the attention of particular followers or collaborators, authors can explicitly declare a post to be a "sprout". Example.

The term is taken from Chris Krycho's essay. These posts will be accompanied by their own RSS feeds (example), and will track declared updates only to that particular item. The implementation is not great — ideally each notification would include and highlight the changes — but so far my diffs are too lame for that. However, subscribers will be notified, via a dedicated feed, of each update to evolving items that they mean attentively to follow.

Obviously, nothing is really "finished". Everything in life is a garden!

But I think that this is enough that I can start sketching and evolving posts intended to develop over time, rather than finished-product "atomic" posts.

Thanks to Chris Krycho and Erlend Sogge Heggen for inspiring me to think about all this!

Update: Chris Krycho credits Maggie Appleton for some of these ideas, so I will too!

Last major update at 2024-06-20 @ 05:50 PM EDT

Updated: Feedletter tutorial

A significant update of Feedletter tutorial was made on 2024-06-20 @ 01:10 PM EDT.

→ Add note to Section 16, "Advanced: Customize the content" documenting feedletter API changes that slightly modify this section of the tutorial.

The post was originally published 2024-01-29 @ 10:30 AM EST.

This is an automatically generated post.
2024-06-16 ⇒

HTML iconography

➣  This post was meaningfully revised at 2024-06-17 @ 02:35 PM EDT. The previous revision is here, diff here. (See update history.)

My web skillz are very old-school.

I only recently learned we're not supposed to use <tt> anymore. (<code> is what the kids use.) We're not supposed to use <a name="whatev"> for our in-document link targets. We should just use <a id="whatev">.

(To be fair, it's pretty cool the targets don't have to be <a> tags any more.)

Anyway, back in my day, to add little icons that might represent your website, we just added a 16x16 pixel /favicon.ico file in some weird, nonstandard Microsoft image format.

Thank you Internet Explorer, the very first evil internet silo that kids these days have never encountered!

My ancient "interfluidity main" site has one of those old-school /favicon.ico files, and I'm not messing with it. But I thought I'd add fresh icons for this site and interfluidity drafts. One 16x16 icon file isn't enough for the modern world. Your site might need an icon on a phone, a tablet, a watch, whatver. Android and Apple devices treat icons differently. Firefox, I discovered, chooses icons differently than other browsers.

The best resource I found to help make sense of the brave new world of website icons was an article by Mathias Bynens.

That article's last update was in 2013, so maybe it's not current? It's a decade newer than my old habits, so hey.

I used Affinity Photo to take the photo I use as an avatar on social media, and label it, for this website as "tech". For prettiness as icons on mobile devices, I also needed to give it rounded corners. I wanted to select a rectangle, round the corners, then invert the selection, and delete to transparent to make rounded corners.

That'a basically what I did, but there's nowhere to set a corner radius on a straight-up rectangualar selection in Affinity Photo.

However, there is a rounded rectangle drawing tool, which draws on its own layer, and — very useful to know! — there is a Selection From Layer menu item, that converts a shape drawn in a layer to a selection. Once I had my selection, invert and delete was no problem and I got my rounded corners.

I gather one can omit rounding corners oneself, if you only care about Apple devices. Apple defines apple-touch-icon and apple-touch-icon-precomposed, and if you supply the not-precomposed version, devices should round corners and maybe drop shadow to "compose" your icon.

Most resources I looked at suggested taking control, so you know what you will get and can use the same icons crossplatform, so that's what I did. So, I rounded my own corners yee-haw!

Then I exported my image as a PNG in all of the sizes recommended by the Bynens article, stole his recommended HTML snippet, and added it — with some modification, see below! — to the main layout of my unstatic-based static-site generators.

    <!-- icons / favicons -->

    <!-- we just want the squared-corner image with no overlays for traditional favicon uses at tiny sizes -->
    <!-- swaldman added, ick, firefox scales down the biggest size for its tab icon, so we use the graphic we want for small sizes as the largest... -->
    <link rel="icon" type="image/png" sizes="500x500" href="<( iconLoc.relative )>/interfluidity-wave-blank-square-500x500.png"> 
    <link rel="icon" type="image/png" sizes="32x32" href="<( iconLoc.relative )>/interfluidity-wave-blank-square-32x32.png">     <!-- swaldman added, for standard favicon size -->
    <link rel="icon" type="image/png" sizes="16x16" href="<( iconLoc.relative )>/interfluidity-wave-blank-square-16x16.png">     <!-- swaldman added, for standard favicon size -->
    <link rel="icon" type="image/png" href="<( iconLoc.relative )>/interfluidity-wave-blank-square-57x57.png">                   <!-- swaldman added, for small icons by default -->

    <!-- at bigger sizes, we overlay a bit of text -->
    <!-- icons as recommened by https://mathiasbynens.be/notes/touch-icons -->
    <!-- For Chrome for Android: -->
    <link rel="icon" sizes="192x192" href="<( iconLoc.relative )>/interfluidity-wave-tech-192x192.png">
    <!-- For iPhone 6 Plus with @3× display: -->
    <link rel="apple-touch-icon-precomposed" sizes="180x180" href="<( iconLoc.relative )>/interfluidity-wave-tech-180x180.png">
    <!-- For iPad with @2× display running iOS ≥ 7: -->
    <link rel="apple-touch-icon-precomposed" sizes="152x152" href="<( iconLoc.relative )>/interfluidity-wave-tech-152x152.png">
    <!-- For iPad with @2× display running iOS ≤ 6: -->
    <link rel="apple-touch-icon-precomposed" sizes="144x144" href="<( iconLoc.relative )>/interfluidity-wave-tech-144x144.png">
    <!-- For iPhone with @2× display running iOS ≥ 7: -->
    <link rel="apple-touch-icon-precomposed" sizes="120x120" href="<( iconLoc.relative )>/interfluidity-wave-tech-120x120.png">
    <!-- For iPhone with @2× display running iOS ≤ 6: -->
    <link rel="apple-touch-icon-precomposed" sizes="114x114" href="<( iconLoc.relative )>/interfluidity-wave-tech-114x114.png">
    <!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≥ 7: -->
    <link rel="apple-touch-icon-precomposed" sizes="76x76" href="<( iconLoc.relative )>/interfluidity-wave-tech-76x76.png">
    <!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≤ 6: -->
    <link rel="apple-touch-icon-precomposed" sizes="72x72" href="<( iconLoc.relative )>/interfluidity-wave-tech-72x72.png">
    <!-- For non-Retina iPhone, iPod Touch, and Android 2.1+ devices: -->
    <link rel="apple-touch-icon-precomposed" href="<( iconLoc.relative )>/interfluidity-wave-blank-square-57x57.png">

    <!-- end icons / favicons -->

A complication emerged, in that my text-labeled icons looked busy and bad, and the text was illegible, when rendered at very small sizes. So you'll note that, for small sizes, I use interfluidity-wave-blank-square files rather than interfluidity-wave-tech. (I thought the very small icons looked better with square corners as well.)

But Firefox kept picking up the largest <link rel="icon" ... > and downsampling from that, rather than downloading the nearest or nearest-larger icon.

So I added the image I want used only for small icons also as a very large icon.

    <link rel="icon" type="image/png" sizes="500x500" href="<( iconLoc.relative )>/interfluidity-wave-blank-square-500x500.png">

Less quirky browsers hopefully never choose this to render from, because there is always a better-sized icon to choose from. But Firefox does choose this one and downsample to render its very small icons-in-a-tab, so the trick gets rid of the ugly, illegibly scaled text in tiny icons under Firefox.

(It does seem a bit wasteful to trick Firefox into downloading 500x500 images to render at 16x16 or 32x32, but if it smartens up, it can download icons prerendered in just those tiny sizes!)

Anyway, that was what I did to add icons to this site and to drafts.

Please let me know if there are much better ways!

Update (17-June-2024):

Carlana Johnson points me to a great article by Andrey Sitnik, How to Favicon in 2024: Six files that fit most needs.

For now, because I'm lazy, and because my icons are not SVG-friendly, I'm leaving things as they are.

But perhaps someday I'll make better, vector, logos and icons, rather than just repurpose my social media avatar. Then I will try out this carefully thought-out approach.

Last major update at 2024-06-17 @ 02:35 PM EDT
2024-06-08 ⇒

Should blogs adopt the itunes:category RSS tag?

Apple organized a whole slew of standard categories or genres for podcasts, when they defined the itunes RSS namespace for podcasts. This helped discoverability of podcasts, as podcast applications and indexers can let users search or browse by genre, or make suggestions based on genres users seem to prefer.

Apple seems to have done a pretty good job at this. It's not obvious that "podcast genres" are meaningfully distinct from "blog genres". We could, of course, invent some analogous kind of categorization just for blogs, but why? As Dave Winer hath writ:

Fewer format features is better

If you want to add a feature to a format, first carefully study the existing format and namespaces to be sure what you're doing hasn't already been done. If it has, use the original version. This is how you maximize interop.

Podcasts got a huge lift from what was originally the blog-centric RSS format. Why haven't blogs adopted podcast-RSS best practices to get a lift right back?

There's a potential issue that some applications may use the presence of itunes RSS tags to imply an RSS feed is for a podcast. But that's pretty dumb. If applications expecting podcasts import blogs without soundfiles because they use this heuristic, well, bad on them. They should fix that. When blogs do contain some posts with audio <enclosure/> elements, then arguably they are podcasts inter alia. Client applications should use intelligent criteria to decide what they want to consider suitably a "podcast" or "podcast episode".

It strikes me as a good idea to make use of good ideas from the itunes (and podcast) namespace for blogs and other RSS applications.

Starting, perhaps, with itunes:category.

Apple defines itunes:category as a channel-level element that permits multiple entries (you don't have to be just one genre), and nested entries for subcategories. Seems pretty good!

What do you think?