rawk; :after clickable!; Markdown Monster

It was a glorious day on Monhegan Island! Trust me, I have receipts. And, while the day has cast an early slumber on $SPOUSE, I’m still winding down, so I get to sneak in a Friday Drop to try to do the same. Hey, it’s better than counting sheep!

As such, it’s a random grab bag from the past few weeks, but they’re each cool in their own way.

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop using SmolLM3-3B-8bit via MLX and a custom prompt.)

• rawk is a modern AWK compiler/preprocessor that adds JavaScript-style arrow functions and higher-order functions, works with any AWK implementation, and includes batteries-included utilities like testing, type checking, and validation. https://eli.li/make-awk-rawk
• The ::after CSS pseudo-element creates an invisible buffer zone around buttons, improving click targets and accessibility by extending the clickable area without altering the button’s visual appearance. https://codepen.io/una/pen/gbaWdmy
• Markdown Monster is a document that identifies the Markdown parser used by testing edge cases like dash handling and HTML tag processing, using a decision tree approach to determine the exact parser. https://git.sr.ht/~xigoi/markdown-monster/blob/master/monster.md

rawk

AWK is still front-and-center in many of our hearts and noggins for its simplicity and effectiveness at text processing, but — even with a recent-ish update — it hasn’t evolved much since its creation in the 1970s. While other languages have added modern conveniences, AWK has remained largely static. Rawk (sr.ht) addresses this by adding contemporary programming patterns without breaking AWK’s core strengths.

Under the hood, rawk essentially is a compiler/preprocessor written entirely in POSIX AWK (!!) that transforms enhanced AWK code into standard AWK. This means it works with any AWK implementation (awk, gawk, mawk, nawk), has no dependencies, and is backward compatible with its progenitor.

Instead of AWK’s traditional function syntax, you get JavaScript-style arrow functions:

RAWK {
    $greet = (name) -> {
        return "Hello, " name "!";
    };
}

Rawk includes higher-order functions that AWK lacks:

# Transform arrays
count = map("double", numbers, doubled);

# Filter elements  
count = filter("is_positive", numbers, positive);

# Reduce to single value
sum = reduce("add", numbers);

And, it even brings Rust-style error handling to AWK:

RAWK {
    $divide = (a, b) -> {
        if (b == 0) {
            return Err("Division by zero");
        }
        return Ok(a / b);
    };
}

{
    result = divide(10, 2);
    if (is_ok(result)) {
        print "Result:", unwrap(result);
    } else {
        print "Error:", unwrap_err(result);
    }
}

Rawk includes batteries-included functionality:

• Testing framework: expect_equal(), expect_true()
• Type checking: is_number(), is_string()
• Validation: is_email(), is_url()
• Functional utilities: map, filter, reduce

I’m looking forward to putting rawk through some paces after our short holiday is over.

:after clickable!

I don’t know about you, but I’m growing increasingly weary of bad UX/UI, especially when it comes to “clickable”/“selectable” areas. I remember (ages ago) reading the printed Apple Developer user interface guideline manuals that stressed how important it was to make interactive elements accessible, especially in forms. The number of times I have not been able to select/check/tap some control on the first try in the past six 7 months of 2025 is nigh innumerable.

So, I was pretty excited to see references to this CodePen which demonstrates a surprisingly simple method for seamlessly increasing the target control area without impacting layouts using the ::after pseudo-element.

The technique works by creating an invisible ::after pseudo-element that extends beyond the original button boundaries. The CSS uses content: '' to create an empty pseudo-element, position: absolute to position it relative to the parent button which has position: relative, and inset: -0.5rem to extend the pseudo-element half a rem beyond all four edges of the original button. This creates a larger invisible area that responds to clicks while the button itself looks exactly the same.

There’s an actual term for why this matters: Fitts’s Law, which states that larger targets are easier and faster to interact with (I mean, “duh,” right?). When you have small icon buttons like a delete icon, folks often struggle to click them precisely, leading to frustration and missed clicks. This is SO STUPID TRUE on mobile devices where touch targets should be at least 44 pixels for proper accessibility, but designers often want smaller visual elements for aesthetic reasons.

This ::after approach helps maintain the intended visual design while dramatically improving usability. We don’t need to be pixel-perfect when clicking/tapping because there’s a generous invisible buffer zone around the actual button. This is much cleaner than alternatives like adding invisible padding or margins, which could disrupt the layout and spacing of other elements.

This technique is invaluable for creating more accessible and user-friendly interfaces, especially when working with compact designs that need to balance visual appeal with practical usability; and, I am going to do my best to ensure I use it in any HTML context moving forward.

Markdown Monster

Markdown Monster is a document that can identify which of 24 different Markdown parsers is being used to render a document. The concept builds on the “YAML Monster”, which showed how the same YAML file could be parsed differently by different YAML parsers, but takes the idea much further by exploiting Markdown’s hidden complexity.

Despite Markdown’s reputation for simplicity, it turns out to be quite complex with many edge cases and ambiguities in its specification. Different Markdown implementations handle these edge cases differently, creating opportunities for fingerprinting. The variations show up in how parsers handle nested list indentation, HTML tag processing, links within links, emphasis marker interactions, and horizontal rule interpretation.

The author created a sophisticated decision tree that systematically tests these edge cases. The process works by having you render the document with your Markdown parser, then examining specific test cases like how dashes are displayed between “START” and “END” markers. Based on what you observe, you follow a decision tree through different sections until you arrive at the exact parser identification.

The document is fairly self-explanatory so I save the blathering and let you read it, then run it through a few Markdown grinders to see if it does what it says on the tin.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️