Matt FantinelModify

2026-09-11 15:18:30

by Matt Birchler

This is a nicely crafted website in which you can play a different trio of nonograms every day! I had no idea what nonograms are before, but once I took a few minutes to learn, it became very fun and one of the best parts of my morning ritual. They’re most similar to minesweeper, I guess, but with the numbers on the columns and rows instead of on the squares themselves.

2026-09-10 20:00:00

The Great Gatsby
1925, F. Scott Fitzgerald

My rating: Decent

This is definitely not my type of book, but I’ve watched the Broadway musical in 2024 and wanted to see what the original material was like. The musical was incredible, the book… not so much. I think the only enjoyment I got out of it was remembering the scenes of the musical as I read it.

2026-09-07 20:00:00

The Invite
2026, Olivia Wilde

My rating: Loved it!

This movie is such a fun time! It’s like a train-wreck that you can’t look away from. My wife and I laughed out loudly so many times, and there’s a lot to dig into if you peek at the details.

2026-09-07 19:28:58

Consonno was a Lombard village for over a thousand years until, in the 1960s, a wealthy businessman bought the land, bulldozed villagers’ homes (some still occupied), and began building the “Las Vegas of Lombardy” — leveling the natural landscape for better mountain views.

The resort never took off, and construction stalled. The environmental damage caught up with it: landslides in the 1970s cut off access, closing the resort for good. It briefly became a home for the elderly before being abandoned entirely.

Photos taken on Sunday, 06 Sep 2026

2026-09-06 08:00:00

Ok, this is maybe something that is widely known (it sure feels like it should be), but it was a gap in my knowledge at least, due to being self-taught: HTML <form> controls don’t have to be inside the <form> tag!

All my web dev life, I always thought that any fields of a form necessarily had to be inside the <form> it belongs to, otherwise it’d rely on JavaScript to work, which is gross. Which is how I ended up with structures similar to the one below, from a blog archive page:

<form action="/">
	<section class="hero">
		<!-- Search input and category filters -->
	</section>
	
	<!-- Other blocks like featured posts -->
	
	<section class="posts-feed">
		<!-- blog posts, pagination, extra filters, etc -->
	</section>
</form>

The content in between the hero and posts-feed is flexible and controlled from the CMS, which means it can contain any other components in it. To account for that, I wrapped the entire content of the page in a <form>, so that the controls on both the hero and the feed submitted the same data to the server.

This was working perfectly fine, until a client added a newsletter CTA in that flexible section. This means that one of those blocks had its own <form>.

The thing is, nested <form>s aren’t a thing in HTML. Submitting the newsletter form was actually submitting the posts filtering instead, and a quick look at the DOM structure revealed that the newsletter form was actually being rendered as a <div> instead.

My brain immediately saw this as a big challenge: how can I keep both the hero and posts-feed inputs in sync but still support inner forms? Would I have to resort to some ugly JavaScript for that?

I’m glad I did some research first.

The form attribute

Proving once again that HTML is awesome and JavaScript is rarely necessary, I found out that elements such as <input> , <select>, <textarea> and <button> can all be associated with a form by using the form attribute (MDN page).

It’s incredibly simple, really. Give any <form> an id, and you can then assign any form control to that form by pointing it to that id, even if they’re not physically inside the form!

In other words, this:

<form id="example">
    <input name="email">
</form>

Can, for most practical purposes, be replaced by this:

<form id="example"></form>

<input name="email" form="example">

The second version gives us considerably more freedom over where the control appears on the page.

Fixing the blog archive example

So for the blog archive example above, we could do something like this:

<form id="posts-form" action="/"></form>

<section class="hero">
	<input name="search" form="posts-form">

	<button type="submit" form="posts-form">
		Search
	</button>
</section>

<!-- Other blocks, even ones with forms -->

<section class="posts-feed">
	<select name="sorting" form="posts-form">
		<!-- options -->
	</select>
</section>

Browser support

The form attribute will work on any browser newer than Internet Explorer 11. Yep. It’s a really old thing. If you’re still supporting IE11 in this day and age, I am so sorry. But you probably have bigger problems than this.

Using it with JavaScript

If you rely on JavaScript for enhancing your form, good news: controls with the form attribute behave just as if they were inside the form! Which means you can use form.elements to get them.

Given this markup:

<form id="posts-form"></form>

<input
    name="s"
    value="CSS"
    form="posts-form"
>

<input
    name="paged"
    value="2"
    form="posts-form"
>

We can access both fields through the form:

const form = document.querySelector('#posts-form');

console.log(form.elements);
// Includes both inputs

They are also included when creating FormData:

const formData = new FormData(form);

console.log(formData.get('s'));     // "CSS"
console.log(formData.get('paged')); // "2"

This made it especially useful for my archive, which submits its filters using AJAX. I could continue treating everything as one form without relying on a common parent element:

const form = document.querySelector('#posts-form');

form.addEventListener('submit', event => {
    event.preventDefault();

    const data = new FormData(form);

    // Fetch the filtered posts...
});

The HTML association remains the source of truth. JavaScript doesn’t need to know where each field happens to be rendered. This is why using what the platform provides always pays off!

One important detail

The form attribute is not inherited.

Setting it on a wrapper does not automatically associate every control inside that wrapper:

<!-- This does not associate the input -->
<div form="posts-form">
    <input name="s">
</div>

It needs to be placed on each form-associated control:

<div>
    <input
        name="s"
        form="posts-form"
    >

    <button
        type="submit"
        form="posts-form"
    >
	    Search
    </button>
</div>

The same applies to a <fieldset>. Although <fieldset> itself supports the form attribute, that value is not inherited by its descendant inputs.

This can require passing the form ID through a few component layers, but I still prefer that explicit relationship over wrapping several unrelated page sections in one form.

Wrapping up

Learning new things about HTML and CSS is not at all uncommon (both languages, especially CSS, are improving a ton lately), even with over 12 years of experience in web dev. But learning old things is a welcome thing, too! It means we don’t have to wait for browser support to catch up 😅

Thanks for reading!

2026-08-31 17:07:17

This incredible religious complex dedicated to St. Michael began being built in the 10th century and sits on top of a mountain overlooking the valleys near the city of Turin, in northern Italy.

I was unable to capture the views of it from further below, but it’s even more majestic.

Photos taken on Sunday, 23 Aug 2026