Search

I like to use my notes page for lists, especially shopping lists, but the markdown library I'm using (Parsedown) doesn't support checkboxes.

A quick function later and I had support. This takes the raw markdown prior to display and does a simple replace:

function parseMarkdownCheckboxes($text) {
    $text = preg_replace('/[ ]/', '<input type="checkbox" class="checkbox">', $text);
    $text = preg_replace('/[x]/', '<input type="checkbox" checked class="checkbox">', $text);
    return $text;
}

Great. But that only converts the markup for viewing. What if I could check/uncheck boxes and have them automatically update the note in real time?

I broke it down into sections then started asking ChatGPT for some code examples. As usual, it couldn't give me exactly what I wanted but was a great place to start.

Now, when I click a checkbox the following things happen:

• some JavaScript makes an array of all the checkboxes in a note (within the containing div)
• it gets the raw markdown text from a hidden textarea and splits it into an array of lines
• it reduces that further into lines that contain a checkbox
• using the index of the item clicked it update the relevant line from the markdown, joins them back together and replaces the textarea value
• it then makes an AJAX call to another file which updates the note content in the database in the background

To make things even better, a quick bit of CSS fades the checked items:

li:has(input[type="checkbox"]:checked) {
    opacity: 25%;
}

Update After wrangling with ChatGPT some more (and by wrangling I mean pointing out where it got things wrong) I've now also got it moving checked items to the bottom of the list and unchecking an item will move it to the top.

Now that I am no longer using the Garden I wanted to repurpose the 'wiki style' double square bracket markup I was using to link between its pages.

I had previously added markup to turn any text into a search link but haven't really used it. I think part of the problem is that the search takes you away from the post you're reading.

Dave Winer mentioned his tagging feature a couple of days ago and this seemed like a perfect fit. So I blatantly copied it. 😆

Now, if I include text within double square brackets it becomes clickable and opens a dialog listing all posts [[tagged]] with that text.

I already detect if the call to the content filters is coming from the files that build the RSS feeds so can ignore tags there to avoid any issues.

I'm not sure how this will sit alongside the existing 'post labels' but will see how it develops and how I use it. The advantage is that it's more flexible and I don't need to clog up other areas (like 'Start Here') with lots of labels. Tags aren't stored in the database like labels, they are checked when showing the dialog.

Note I have also removed tags on the homepage.

Looking back at posts from a couple of years ago, I was worried about feature creep on the site.

My goal with (b)log-In was to have a simple posting experience and my concern was that all the bells and whistles would detract from that simplicity.

I still want a simple experience (and I still have a simple posting experience) but things have changed in the past two and a half years. Yes, it's been that long!

The site is no longer just a blog, it is now my 'X' – my site for almost everything. Blog, notes, journal, feed reader, it's all in one place, all under my control. That has, obviously, necessitated an amount of expansion.

I'll admit, there are some more frivolous features (like custom markup, the file editor, and Markdown preview for custom pages) but they don't get in the way if I choose not to use them. The base experience is still as simple as it always was: tap a little '+' icon, type, and hit 'Post'. Nothing more complicated than that and no backend to navigate.

I suppose that's the beauty of building your own tools: you can make them work exactly how you want. And what I want (and have) is something that quickly and easily lets me put words on the web.

I've been typing so many backslashes over the past couple of days – escaping characters in seemingly endless regex queries.

It got to the point that I had a brain fart last night expecting italicised text to be slanting to the left.

Hmmm.

What if you could do exactly that?

A quick search found the same question on Stack Overflow with an ingenious solution.

I've modified it slightly so that I can apply it to i tags (with a class) such that they will be slanting to the left on the site but remain normal italicised text when viewed elsewhere (e.g. via the RSS feed).

This is a test of 'left slanting' text.

This is normal italicised text for a comparison.

Pretty cool.

Update I've added the custom markup _$..$_ to indicate left slanting italics.

Bix wrote about the idea of universally followable /now pages. This notion is a replacement for / addendum to an idea he previously had about a site or service that would show you when people have made updates to their info rather than what those updates actually were.

The key is that it would let the individual explore those updates in their own time. They are given the minimum information required rather than be overloaded.

He says:

"So that's my pitch to the /now page community: develop tools that publish these pages not just to a webpage but to RSS and/or ActivityPub, as well as tools to markup, perhaps using some kind of microformats, the underlying HTML in ways that would allow for a crawler to parse them even absent an RSS or ActivityPub feed."

Microformats2 certainly could work. There are already indieweb tools that parse pages based on markup, like monocle but RSS is far more familiar with much wider adoption. Even if people persist in saying social killed RSS or that it died with Google Reader.

Using rssCloud to push updates (I wish more feeds supported it) would be a nice addition.

This got me thinking about feed readers. They became popular because of their killer feature: convenience. They bring everything together in one place allowing the consumer to easily scan updates from multiple sources without having to navigate halfway across the web.

Feed readers also homogenise content, displaying it according to local preferences. Links will always be the same colour and other elements, like blockquotes, will always look the same. It reduces the cognitive load when consuming posts from multiple and varied sources.

But is this always a good thing?

I've written before about trying to shift away from posts just being "social units" in a timeline – that is one of the big disadvantages with certain social networks: all content is rendered the same. Also mentioned in passing before.

It makes me wonder if we're 'doing it wrong' with feed readers.

The homogenisation of post content means we lose the personality behind the words. As I have previously quoted Robin Sloan: "presentation is a form of content" – abstracting the content from how it was meant to look can do it a disservice.

I have been intrigued by the idea of having "less of an emphasis on the actual consumption itself within the reader – more of a notification system" and Bix's post brings me back to this.

The menu tray for /reader is just a list of blogs with an indication of unread posts. What if this was all it did? Just told you someone had updated their site and it was up to you, the reader, to go off and find out what.

I wondered if this approach might cause me to read less due to the loss of convenience. Conversely, it might make me interact more, leave more comments, as I would already be on the host site.

I posited an alternative view for /reader 7 months ago (wow, was it really that long) but nothing ever came of it. Now, however, I think the time is right to return to it and see what I can come up with.