Jim Nielsen’s Blog

You found my experimental HTML feed (there are also other ways to subscribe).

I HTML

Recent posts

Don’t Forget These Tags to Make HTML Work Like You Expect

View

I was watching Alex Petros’ talk and he has a slide in there titled “Incantations that make HTML work correctly”.

This got me thinking about the basic snippets of HTML I’ve learned to always include in order for my website to work as I expect in the browser — like “Hey I just made a .html file on disk and am going to open it in the browser. What should be in there?”

This is what comes to mind:

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">

Why each?

doctype

<!doctype html>

Without <!doctype html>, browsers may switch to quirks mode, emulating legacy, pre-standards behavior. This will change how calculations work around layout, sizing, and alignment.

<!doctype html> is what you want for consistent rendering. Or <!DOCTYPE HTML> if you prefer writing markup like it’s 1998. Or even <!doCTypE HTml> if you eschew all societal norms. It’s case-insensitive so they’ll all work.

html lang

<html lang="en">

Declare the document’s language. Browsers, search engines, assistive technologies, etc. can leverage it to:

  • Get pronunciation and voice right for screen readers
  • Improve indexing and translation accuracy
  • Apply locale-specific tools (e.g. spell-checking)
  • And more…

Omit it and things will look ok, but lots of basic web-adjacent tools might get things wrong. Specifying it makes everything around the HTML work better and more accurately, so I always try to remember to include it.

meta utf-8

This piece of info can come back from the server as a header, e.g.

return new Response(
    "<!doctype html><h1>Hello world</h1>",
    {
        status: 200,
        headers: { "Content-Type": "text/html; charset=utf-8" },
    }
);

But I like to set it in my HTML, especially when I’m making files on disk I open manually in the browser.

<meta charset="utf-8">

This tells the browser how to interpret text, ensuring characters like é, ü, and others display correctly.

So many times I’ve opened a document without this tag and things just don’t look right — like my smart quotes.

For example: copy this snippet, stick it in an HTML file, and open it on your computer:

<!doctype html>
<h1>Without meta utf-8</h1>
<dl>
  <dt>Smart quotes</dt>
  <dd>“” and ‘’</dd>
  <dt>Symbols</dt>
  <dd>©, ™, ®, etc.</dd>
  <dt>Ellipsis</dt>
  <dd></dd>
  <dt>Emojis</dt>
  <dd>👍</dd>
  <dt>Non-latin characters</dt>
  <dd>é, ñ, etc.</dd>
</dl>

Things might look a bit wonky. But stick a <meta charset="utf-8"> tag in there and you’ll find some relief.

Meta viewport

<meta name="viewport" content="width=device-width,initial-scale=1.0">

Sometimes I’ll quickly prototype a little HTML and think, “Great it’s working as I expect!” Then I go open it on mobile and everything looks tiny — “[Facepalm] you forgot the meta viewport tag!”

Take a look at this screenshot, where I forgot the meta viewport tag on the left but included it on the right:

Two screenshots of a basic HTML with an h1 tag that says “Hello world” that are side-by-side. The one on the left looks like it’s zoomed way out becuase it’s missing the meta viewport tag. The one on the right looks like you expect.

That ever happen to you? No, just me? Well anyway, it’s a good ‘un to include to make HTML work the way you expect.

Last But Not Least…

I know what you’re thinking, I forgot the most important snippet of them all for writing HTML:

<div id="root"></div>
<script src="bundle.js"></script>

Lol.


Reply via: Email · Mastodon · Bluesky

Everything Is Broken

View

Chris Coyier wrote about it.

Now it’s my turn.

Last week I’m flying home.

My flight gets delayed in air, then lands late so I miss my connecting flight…

[Skip over all the stuff about airline customer support, getting rebooked, etc.]

It’s ~10pm and I’m stranded overnight. I need a last-minute hotel room.

I figure I’ll try HotelTonight because that’s their shtick, right? “Incredible last-minute hotel deals” says their homepage hero banner.

I find the closest hotel, click “Purchase” it takes me to checkout, I do the whole Apple Pay thing, then it says “failed to book” because there are no more rooms left.

Ok? Would’ve been nice to know that before going through all the checkout stuff, but ok. I’ll find another.

Two more hotels, same deal. Click through, checkout, blah blah blah, payment won’t go through. It says there are no more rooms left.

No I’m getting frustrated. I’ll try one more time…

Same flow. Finally! Payment goes through. Confirmation number and all — I’m good to go!

I leave the airport and get a rideshare to the hotel.

Go up to the desk. “Yes, I’m checking in please.” They ask for my name. I give it.

They can’t find me.

“Oh, no…” I think.

“Do you have a reservation number?”

Hell yes I do! Right here in the email HotelTonight sent me.

I give it to them.

It’s not in their system.

“Ok well, can you get me a room?”

Nope, they are completely full for the night.

Knowing that I booked through a third-party system, and it’s not in the first-party system, I know there’s no chance I’m getting a room.

So now it’s 10:30pm. I’m in the lobby of the hotel for which I have a bogus confirmation and I begin my search for the next-closest hotel.

I know at this point I’m not using anything internet-based to make a reservation. Over-the-phone only!

I call a bunch of nearby hotels. Every one is giving me their automated phone system — “If you want to book a reservation, press 1. If you want to…”

I sit through the first couple calls and eventually connect to a human: “Do you have any rooms available tonight?”

“Yes sir, can you confirm which location you are calling for?” They don’t know because this isn’t someone at the hotel. This is a call center somewhere.

I quickly realize this ain’t gonna work.

New rule: if the number online is a centralized number that gives me your automated phone system, I’m out. Next hotel.

I just need to connect to a human at a front desk.

I call maybe 12 hotels. About two give me humans at the front desk. Both of those are booked solid for the night.

But you know what? Props to those hotels for having direct lines to a human. YUGE props.

A direct line to a human feels like the ultimate luxury at this point.

“Hey you got any rooms tonight? No? That’s ok. I appreciate you being there to answer my call, friend. You have a good night.”

Eventually I find a hotel 20 minutes down the road where somebody at the front desk answers and says they have a room. “It’s twice the cost since it’s our last room.” I don’t care, I book it. This is a phone call with a person at the front desk, I know I’m getting a room.

Postscript: I also spent several days going back and forth with a rep at HotelTonight to get a refund. I guess it’s hard to prove that their system sold me a room that did not exist.


Reply via: Email · Mastodon · Bluesky

AI Browsers: Living on the Frontier of Security

View

OpenAI released their new “browser” and Simon Willison has the deets on its security, going point-by-point through the statement from OpenAI’s Chief Information Security Officer. His post is great if you want to dive on the details. Here’s my high-level takeaway:

Everything OpenAI says they are doing to mitigate the security concerns of an LLM paired with a browser sounds reasonable in theory. However, as their CISO says, “prompt injection remains a frontier, unsolved security problem”. So unless you want to be part of what is essentially a global experiment on the frontier of security on the internet, you might want to wait before you consider any of their promises “meaningful mitigation”.

(Aside: Let’s put people on the “frontier” of security for their daily tasks, that seems totally fine right? Meanwhile, Tom MacWright has rationally argued that putting an AI chatbot between users and the internet is an obvious disaster we’ll all recognize as such one day.)

What really strikes me after reading Simon’s article is the intersection of these two topics which have garnered a lot of attention as of late:

  1. npm supply chain attacks
  2. AI browsers

This intersection seems primed for exploitation, especially if you consider combining different techniques we’ve seen as of late like weaponizing LLM agents and shipping malicious code that only runs in end-users’ browsers.

Imagine, for a second, something like the following:

You’re an attacker and you stick malicious instructions — not code, mind you, just plain-text English language prose — in your otherwise helpful lib and let people install it.

No malicious code is run on the installing computer.

Bundlers then combine third-party dependencies with first-party code in order to spit it out application code which gets shipped to end users.

At this point, there is still zero malicious code that has executed on anyone’s computer.

Then, end users w/AI browsers end up consuming these plain-text instructions that are part of your application bundle and boom, you’ve been exploited.

At no point was any “malicious code” written by a bad actor “executed” by the browser engine itself. Rather, it’s the bolted on AI agent running alongside the browser engine that ingests these instructions and does something it obviously shouldn’t.

In other words: it doesn’t have to be code to be an exploit. Plain-text human language is now a weaponizable exploit, which means the surface for attacks just got way bigger.

But probably don’t listen to me. I’m not a security expert. However, every day that voice in the back of my head to pivot to security gets louder and louder, as it’s seemingly the only part of computer science that gets worse every year.


Reply via: Email · Mastodon · Bluesky

Write Code That Runs in the Browser, or Write Code the Browser Runs

View

I’ve been thinking about a note from Alex Russell where he says:

any time you're running JS on the main thread, you're at risk of being left behind by progress.

The zen of web development is to spend a little time in your own code, and instead to glue the big C++/Rust subsystems together, then get out of the bloody way.

In his thread on Bluesky, Alex continues:

How do we do this? Using the declarative systems that connect to those big piles of C++/Rust: CSS for the compositor (including scrolling & animations), HTML parser to build DOM, and for various media, dishing off to the high-level systems in ways that don't call back into your JS.

I keep thinking about this difference:

  • I need to write code that does X.
  • I need to write code that calls a browser API to do X.

There’s a big difference between A) making suggestions for the browser, and B) being its micromanager.

Hence the title: you can write code that will run in the browser, or you can write code that calls the browser to run.

A Few Examples

So what are the browser ‘subsystems’ I can glue together? What are some examples of things I can ask the browser to do rather than doing them myself?

A examples come to mind:

  • View transitions API (instead of JS DOM diffing and manual animation).
  • CSS transitions or @keyframes (GPU-accelerated) vs. manual JS with setInterval updates.
  • scroll-behavior: smooth in CSS vs. JS scroll logic.
  • CSS grid or flexbox vs. JS layout engines (e.g., Masonry clones).
  • <video> and <audio> elements with native decoding and hardware acceleration vs. JS media players.
  • <picture> or <img> with srcset for responsive images vs. manual image swapping logic in JS.
  • Built-in form state (formData) and validation (required, pattern, etc.) vs. JS-based state, tracking, and validation logic.
  • Native elements like <details>, <dialog>, <select>, etc., which provide built-in keyboard and accessibility behavior vs. custom ARIA-heavy components.

Going Galaxy Brain

Galaxy brain meme from top to bottom: setTimeout -> requestAnimationFrame -> document.startViewTransition -> @view-transition

The trick is to let go of your need for control. Say to yourself, “If I don’t micromanage the browser on this task and am willing to let go of control, in return it will choose how to do this itself with lower-level APIs that are more performant than anything I can write.”

For example, here are some approaches to animating transitions on the web where each step moves more responsibility from your JavaScript code on the main thread to the browser’s rendering engine:

  • setTimeout
    • JS timers, DOM manipulation, browser repaints when it can. Dropped frames.
  • requestAnimationFrame
    • Syncs to browser repaint cycle. Smooth, but you gotta handle a lot yourself (diffing, cleanup, etc.)
  • View Transitions in JS
    • JS triggers, browser snapshots and animates. Native performance, but requires custom choreography on your part.
  • View Transitions in CSS
    • Declare what you expect broadly, then let the browser take over.

It’s a scale from:

I want the most control, and in exchange I’ll worry about performance.

To:

I don’t need control, and in exchange you’ll worry about performance.

I don’t know about you, but I’d much rather hand over performance, accessibility, localization, and a whole host of issues to the experts who build browsers.

It’s Trade-offs All the Way Down

Building on the web is a set of choices:

  • Do it yourself.
  • Let the browser do it.
  • Somewhere in between.

Anytime you choose to do something yourself, you’re choosing to make a trade-off. Often that increase in control comes at the cost of a degradation in performance.

Why do it yourself? Often it’s because you want a specific amount of control over the experience you’re creating. That may be perfectly ok! But it should be a deliberate choice, not because you didn’t consider (or know) the browser offers you an alternative. Maybe it does!

So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”

Building this way will likely improve your performance dramatically — not to mention decrease your maintenance burden dramatically!


Reply via: Email · Mastodon · Bluesky

Research Alt

View

Jeremy imagines a scenario where you’re trying to understand how someone cut themselves with a blade. It’d be hard to know how they cut themselves just by looking at the wound.

But if you talk to the person, not only will you find out the reason, you’ll also understand their pain.

But what if, hear me out here, instead we manufactured tiny microchips with sensors and embedded them in all blades?

Then we program them such that if they break human flesh, we send data — time, location, puncture depth, current blade sharpness, etc. — back to our servers for processing with AI.

This data will help us understand — without bias, because humans can’t be trusted — how people cut themselves.

Thus our research scales much more dramatically than talking to individual humans, widening our impact on humanity whilst simultaneously improving our product (and bottom line)!

I am accepting venture funds for this research. You can send funds to this bitcoin address: 17HzyHWNrdS7GpMArshSBLpJpcvrre93P6.


Reply via: Email · Mastodon · Bluesky

Social Share Imagery via a Data Attribute

View

I’ve done something few on the internet do. I’ve changed my mind.

Double take meme of girl with a disgusted face on one side then the same girl with a face of changed opinion. Both faces have the text “og:image” superimposed.

A few posts on my blog have started to unfurl social share imagery.

Screenshot of a post from @jimniels@mastodon.social showing a link to blog.jim-nielsen.com and an accompanying og:image preview.

You might be wondering, “Wait Jim I thought you hated those things?”

It’s not that I hate social share imagery. I just think…well, I’ve shared my thoughts before (even made a game) so I won’t get on my soapbox.

But I think these “previews” have their place and, when used as a preview — i.e. an opportunity to graphically depict a brief portion of the actual, underlying content — these function well in service of readers.

For example, I often write posts that have zero images in them. They’re pure text. I don’t burden myself with the obligation to generate a graphical preview of the ideas contained in those posts.

But, sometimes, I create posts that have lots of imagery in them, or even just a good meme-like photo and it feels like a shame to not surface that imagery in some way.

So, in service of that pursuit, I set out to resolve how I could do og:images in my posts.

It’s not as easy as “just stick it your front-matter” because my markdown files don’t use front-matter. And I didn’t want to “just add front-matter”. I have my own idiosyncratic way of writing markdown for my blog, which means I need my own idiosyncratic way of denoting “this post has an og:image and here’s the URL”.

After giving it some thought, I realized that all my images are expressed in markdown as HTML (this lets me easily add attributes like alt, width, and height) so if I wanted to mark one of my images as the “preview” image for a post, I could just add a special data attribute like so:

You guys, I made the funniest image to depict this:

<img data-og-image src="" width="" height="" alt="">

Isn’t that hilarious?

Then my markdown processor can extract that piece of meta information and surface it to each post template, essentially like this:

<html>
  <title>{post.title}</title>
  {post.ogimage &&
    <meta property="og:image" content={post.ogimage}>}
  <body>
    <h1>{post.title}</h1>
    {post.content}

I love this because it allows me to leverage existing mechanisms in both the authoring and development processes (data attributes in HTML that become metadata on the post object), without needing to introduce an entirely new method of expression (e.g. front-matter).

It also feels good because:

  1. It’s good for me. It doesn’t require any additional work on my part. I don’t have to create additional images for my posts. I’m merely marking images I’ve already created — which were done in service of a post’s content — as “previews” for the post.
  2. It’s good for users. Readers of my site get image previews that are actually, well, previews — e.g. a graphical representation that will contextually reappear in the post, (as opposed to an image template whose contents do nothing to provide an advanced graphical preview of what’s to follow in the post itself).

It’s technology in service of content, rather than content in service of technology.

Or at least that’s what I like to tell myself :)


Reply via: Email · Mastodon · Bluesky

Doing It Manually

View

I have a standing desk that goes up and down via a manual crank.

I’ve had it for probably ten years.

Every time I raise or lower that thing, it gets my blood pumping.

I often think: “I should upgrade to one of those standing desks that goes up and down with the push of a button.”

Then there’s the other voice in my head: “Really? Are you so lazy you can’t put your snacks down, get out of your comfy chair, in your air conditioned room, and raise or lower your desk using a little elbow grease? That desk is just fine.”

While writing this, I get out of my chair, star the timer, and raise my desk to standing position. 35 seconds.

That’s the cost: 35 seconds, and an elevated heart rate.

As I have many times over the last ten years, I recommit to keeping it — mostly as a reminder that it’s ok to do some things manually. Not everything in my life needs to be available to me at the push of a button.


Reply via: Email · Mastodon · Bluesky

Running Software on Software You’ve Never Run

View

I love a good look at modern practices around semantic versioning and dependency management (Rick Hickey’s talk “Spec-ulation” is the canonical one I think of).

Niki recently wrote a good ‘un at tonsky.me called “We shouldn’t have needed lockfiles”.

What struck me was this point about how package manifests allow version ranges like ^1.2.3 which essentially declare support for future versions of software that haven’t yet been written:

Instead of saying “libpupa 1.2.3 depends on liblupa 0.7.8”, [version ranges] are saying “libpupa 1.2.3 depends on whatever the latest liblupa version is at the time of the build.”

Notice that this is determined not at the time of publishing, but at the time of the build! If the author of libpupa has published 1.2.3 a year ago and I’m pulling it now, I might be using a liblupa version that didn’t even exist at the time of publishing!

The funny thing is, we use version ranges only to go freeze them with lock files:

version ranges end up not being used anyway. You lock your dependencies once in a lockfile and they stay there, unchanged

In other words: we avoid locking ourselves to specific versions in package.json by using version ranges, only to then go lock ourselves to specific versions in package-lock.json — lol!

I mean, that’s funny when you think about it.

But to go back to Niki’s earlier point: version ranges let us declare to ourselves that some code that exists today is compatible with some other future code that has yet to be written.

This idea allows us to create automated build systems that resolve to an artifact whose dependencies have never existed before in that given combination — let alone tested and executed together in that combination.

Now I get it, semantic versioning is an idea not a guarantee. But it’s also pretty wild when you think about it — when you encounter the reality of how semantic versioning plays out in the day-to-day world of building software.

I guess that’s a way of acknowledging out loud that we have normalized shipping production systems on top of the assumption that untested, unwritten combinations of software will behave well together — if not better, since patch updates fix bugs right?

And that’s not even getting into the security side of the equation. Future versions of packages have no guarantee to be as safe as previous ones, as we’ve seen with some of the npm supply chain attacks which rely on version ranges for their exploits. (Funny, isn’t it? Upgrading to the latest version of a package can get you into trouble. The solution? Upgrading to the latest version of a package.)

Anyhow, this all gets me thinking that version ranges and dependency management were the gateway drug to the non-determinism of LLMs.


Reply via: Email · Mastodon · Bluesky

The Risks of NPM

View

There was a time when I could ask, “Did you see the latest NPM attack?” And your answer would be either “Yes” or “No”.

But now if I ask, “Did you see the latest NPM attack?” You’ll probably answer with a question of your own: “Which one?”

In this post, I’m talking about the Qix incident:

  • Prolific maintainer Qix was phished.
  • Qix is a co-maintainer on many packages with Sindre Sorhus, the most popular maintainer on NPM (by download count).
  • Attackers pushed malicious code to packages that are indirectly depended by a huge portion of the ecosystem (hundreds of millions of downloads a week).

When I first heard about it, I thought “Oh boy, better not npm i on the old personal machine for a little while.”

But as details began to emerge, I realized the exploit wasn’t targeting my computer. It was targeting the computers of people downstream from me: end users.

The malicious code didn’t do anything when running npm install. Instead, it laid there dormant, waiting to be bundled up alongside a website’s otherwise normal code and served to unsuspecting end users.

Maybe we should rename “bundlers” to “trojan horses”, lol.

Graphic depicting many source assets on the left, like .js files, passing through a trojan horse in the middle and coming out as singular files on the right.

That’s all to say: you didn’t have to run npm install to be affected by this attack. You just had to visit a website whose code was sourced via npm install. (You needed a bitcoin wallet too, as that was the target of the exploit.)

It’s wild because browsers work really hard to make it safe to visit any webpage in the world — to do a GET to any URL. But attacks like this chip away at those efforts.

So while it’s easy to think NPM can be unsafe for your computer because running npm install allows running arbitrary code, that’s not the whole story. npm install can be unsafe for:

  • Your computer (install time execution)
    • Lifecycle scripts (preinstall, install, postinstall) allow running arbitrary code which can read/write files locally, steal keys and tokens, install malware, and otherwise exfiltrate data.
  • Your dev/CI computer(s) (build time execution)
    • Compilers, bundlers, transpilers, plugins, etc., can all execute arbitrary code and leak secrets, corrupt build artifacts, add hidden payloads, etc.
  • Your application server (server runtime execution)
    • Any dependency runs top-level in production and exposes risk to data exfiltration, unsafe privilege escalation, remote command execution, etc.
  • Your users’ computers (client runtime execution)
    • Bundled dependencies ship with your website, exposing your users to malicious code that runs in their browser and can exfiltrate data, insert hidden trackers/miners, etc.

Reply via: Email · Mastodon · Bluesky

Related posts linking here: (2025) Social Share Imagery via a Data Attribute · (2025) AI Browsers: Living on the Frontier of Security

Anti-*: The Things We Do But Not All The Way

View

I was reading Chase McCoy’s article “Antibuildings” where he cites Wikipedia’s entry on the term “Antilibrary” which points to another entry about the Japanese concept of Tsundoku, all of which deal with this idea of things we do with intention but that never make it to fruition.

Antilibraries are the books we buy but never read.

Antibuildings the architect’s version of sketches and plans drafted but buildings never made.

It got me thinking about the stuff I’ve started with intention but never brought to fruition — my own anti-*’s.

To name a few:

  • Antidomains: the domains I bought and had big plans for, but they never progressed beyond being parked at my registrar. (Zach Leatherman recently made a list kinda like this, if you haven’t seen it.)
  • Antiwebsites: the sites I was gonna make, but never shipped.
  • Antilayers: the Photoshop, Sketch, or Figma designs I painstakingly crafted to the level of “completeness”, but then never began building with code.
  • Anticode: the changes I made that functioned to the level of being usable and shippable, but then I never could pull the trigger on ‘em.
  • Antiposts: (also known as “drafts”, lol) all those blog posts I poured time and energy into researching, writing, and editing, but never could take all the way to “published”.
  • Antitweets: all the Tweets/Toots/Skeets I meticulously crafted as witty comebacks or sarcastic quips, but then never posted (honestly, probably for the better).

And last, but certainly not least — in fact, probably grandest of them all:

  • Antitabs: all the browser tabs of articles, videos, recipes, and other good things I collected and was going to read, watch, bake, etc. but never did.

Photo of a bookshelf on top with lots of books, below that a screenshot of a bunch of tabs where all you can see is favicons


Reply via: Email · Mastodon · Bluesky

Related posts linking here: (2025) Social Share Imagery via a Data Attribute