HTML

Tracing with Omoikane how a URL fragment becomes the CSS :target

Sun, 27 Sep 2026 22:31:00 +0900

Links that jump to headings on the page look simple.

<a href="#details">Go to details</a>
<section id="details">...</section>

When you click this link, the URL’s end changes to #details, and the corresponding element becomes the destination within the page. By using :target in CSS, you can highlight only that element.

:target {
 outline: 2px solid red;
}

Usually, understanding that “the part of the URL after # matches id” is sufficient. However, when trying to incorporate :target into my own browser, Omoikane, that wasn’t enough. The URL‑parsing logic, the HTML rules for selecting the target, the document’s internal state, CSS selector matching, and the updates after changing location.hash are all handled in separate places.

I advanced browser compatibility for cookies and scrolling in Omoikane.

Wed, 23 Sep 2026 21:39:00 +0900

In my custom browser Omoikane , I made several changes related to Web API and CSS compatibility.

Looking at these changes, many of them went beyond simply adding APIs visible to JavaScript. It was necessary to convey the page’s state to the host, reflect JavaScript actions in HTTP communication, and preserve the scroll position set by CSS until the input processing is finished.

Cookies were handled separately for JavaScript and HTTP

The first thing we fixed was how cookies are managed.

I'm fixing subtle web‑compatibility differences in Omoikane.

Tue, 22 Sep 2026 07:09:00 +0900

When I’m tinkering with my own browser, Omoikane , I’ve found that the tiny differences that are taken for granted in existing browsers can be more troublesome than implementing a single large web API.

The changes I added this time are the default margin for body, declarative Shadow DOM, and the orientation of characters in vertical text. Each of these looks like a small visual tweak, but each relies on assumptions in the CSS cascade, HTML parsing, and text rendering, respectively.

Implemented Pointer Lock and form‑related custom elements in Omoikane.

Sun, 20 Sep 2026 11:25:48 +0900

I added Pointer Lock support and custom form‑related elements to my self‑made browser ( Omoikane ).

In the previous post I wrote about Fullscreen API and character‑encoding conversion streams. This time I’m covering the pathway for delivering mouse input to the page and the logic for integrating my custom input components into HTML forms.

Neither of these is a huge undertaking if you only consider the entry‑point APIs. However, when we actually hooked everything up, we ran into issues such as mouse input being delivered twice on X11, iframe callbacks executing in a different runtime environment, and even pages that don’t use forms becoming sluggish. In the end, the macOS tests caused the entire process to crash.

Implemented the Fullscreen API and character‑encoding conversion streams in Omoikane.

Sat, 19 Sep 2026 20:46:07 +0900

I added the Fullscreen API and TextEncoderStream/TextDecoderStream to my custom browser, Omoikane .

Previously, I implemented the Popover API and a top layer (see /blog/2026-09-14/). This time, I connected that rendering pipeline to the Fullscreen API and, as a separate task, made character‑encoding conversion usable via the Streams API. (source)

Fullscreen display and character‑encoding conversion are fairly unrelated features. However, neither could be completed simply by adding a JavaScript method.

Implemented the Popover API and top layer in the custom browser Omoikane.

Mon, 14 Sep 2026 16:34:41 +0900

I have implemented the HTML Popover API in my custom browser, Omoikane (source).

With the Popover API, you can open and close popovers using only HTML, without needing to manage their visibility state with JavaScript.

<button popovertarget="menu">Open menu</button>

<div id="menu" popover>
 <button>Item 1</button>
 <button>Item 2</button>
</div>

At first glance, it seems all you’d need to do is add an API to toggle the element’s display state.

In reality, popovers are rendered on a top layer that lies outside the normal stacking order. There are considerations such as light dismissal when clicking outside, closing with the Escape key, focus movement and restoration, ::backdrop, and the ordering relationship with dialogs.

I made significant progress on the HTML and CSS implementation of my custom browser, Omoikane.

Sat, 12 Sep 2026 19:51:40 +0900

These past few days, I’ve been working on advancing the implementation of HTML and CSS in my custom browser, Omoikane (source).

At first, I displayed the same HTML as Firefox and investigated where any rendering discrepancies remained.

When I began the comparison, I discovered not only simple color differences but also fundamental shortcomings, such as inline elements not having their bounding boxes correctly calculated, web fonts not being manageable from JavaScript, and HTML fragments not being parsed according to the context.