DEV Community: Witold Wozniak

Resolving MissingMethodException in Newtonsoft.Json

Witold Wozniak — Wed, 17 Jun 2026 10:30:49 +0000

A test passed in CI and failed on my machine. Same commit, same code, two different outcomes, and the difference turned out to live in the Global Assembly Cache rather than anywhere in the repository. This is a write-up of how a strong-named assembly in the GAC can shadow the copy your application ships, why MissingMethodException is the symptom, and the one-line change that resolves it.

The problem

A unit test failed locally with:

System.MissingMethodException: Method not found:
'System.String Newtonsoft.Json.Linq.JToken.ToString(Newtonsoft.Json.Formatting)'

The same test passed in Jenkins and GitHub Actions. The code was compiled against a recent Newtonsoft.Json, and the build output folder contained a Newtonsoft.Json.dll that does expose JToken.ToString(Formatting). The method existed in the assembly sitting next to the application. The runtime was not loading that assembly.

A gap that appears on developer workstations but never in CI points away from the code and toward the environment. The environment, in this case, was the GAC.

The explanation

On .NET Framework, the runtime resolves a strong-named assembly by its identity: name, public key token, culture, and assembly version. When an assembly with a matching identity is present in the GAC, the GAC copy is preferred over a copy in the application's own directory.

Newtonsoft.Json keeps the same strong-name identity across the entire 13.x line:

AssemblyVersion is 13.0.0.0 for every 13.0.x release
the public key token is identical across them

Two different builds — say 13.0.1 and a later 13.0.x — are therefore indistinguishable to the runtime's binding logic. They present the same identity. A binding redirect cannot tell them apart, because there is nothing to redirect between. So if any 13.0.x is registered in the GAC, it satisfies the reference, and the runtime loads it in preference to the version you shipped.

Because all 13.x releases share one identity, an application cannot enforce that it runs against the build it was compiled and tested against. An older release with a known vulnerability, present in the GAC, will be loaded ahead of the patched copy in the application folder, and there is no binding-redirect mechanism to prevent it. The upstream issues linked below raise exactly this point.

The two assemblies are not byte-identical. Method signatures shifted across 13.x patch releases, including on JToken.ToString and JToken.WriteTo. The set of overloads present in 13.0.1 is not exactly the set present in a later 13.0.x.

That produces the failure. The compiler binds the call against the overload set in the version you reference. At runtime the GAC copy is loaded, its overload set is different, the specific overload the call was compiled against is not there, and you get MissingMethodException: a method present at compile time and absent at run time, with no code change between the two.

Continuous integration never reproduces it because the build agents have no such GAC entry. They load the assembly from the application folder, which is the one the build referenced. Green every time.

The older Newtonsoft.Json in the GAC was not put there by the application, and on a managed corporate machine it cannot simply be removed. It is registered and held open by background agents — endpoint security, device management, and update services — that run for the life of the session and keep file handles on the assembly the whole time.

Searching the GAC path in Resource Monitor shows the holders directly. On a typical managed Windows laptop they are the usual fleet-management software:

Associated Handles                              Search: Newtonsoft.Json.dll
─────────────────────────────────────────────────────────────────────────────
Image                                PID    Type   Handle Name
─────────────────────────────────────────────────────────────────────────────
OktaVerify.exe                       2137   File   C:\Windows\Microsoft.NET\
Dell.Update.SubAgent.exe             15288  File     assembly\GAC_MSIL\
WorkspaceONEHubHealthMonitoring.exe  7696   File     Newtonsoft.Json\
TaskScheduler.exe                    8372   File     v4.0_13.0.0.0__
ServiceShell.exe                     26004  File     30ad4fe6b2a6aeed\
(and others)                                         Newtonsoft.Json.dll
─────────────────────────────────────────────────────────────────────────────

The copy is effectively immutable: you do not control the processes pinning it, and you cannot unregister an assembly the operating system reports as in use. Any fix has to assume the GAC copy stays exactly where it is.

The fix

Since the GAC copy cannot be moved, the call has to bind to an overload that exists in both versions. Both ToString and WriteTo have a params JsonConverter[] overload that has been present across the 13.x line. The single-argument overloads are the ones whose presence varies between patch releases. Passing the converter argument explicitly forces binding to the stable overload.

For ToString:

// before — binds to ToString(Formatting), absent from the older GAC copy
jToken.ToString(Formatting.None)

// after — binds to ToString(Formatting, params JsonConverter[])
jToken.ToString(Formatting.None, [])

// in older C# versions
jToken.ToString(Formatting.None, Array.Empty<JsonConverter>())

For WriteTo:

// before — binds to WriteTo(JsonWriter)
jToken.WriteTo(writer)

// after — binds to WriteTo(JsonWriter, params JsonConverter[])
jToken.WriteTo(writer, Array.Empty<JsonConverter>())

The empty converter array means no converters are applied, so the output is byte-for-byte identical to the original call. Nothing about serialization behavior changes. The only thing that changes is which overload the compiler selects, and the selected overload is one the older GAC assembly also has. The maintainer recommends this same workaround on the upstream issue.

It is a targeted mitigation, not a cure. It resolves the specific calls that break, and it leaves the underlying resolution behavior untouched — any other call site reaching for a newer-only overload will fail the same way until it gets the same treatment.

There is a second option that avoids the unstable type entirely. Instead of asking the token to render itself, hand it to the static serializer:

// before — JToken instance method, overload set varies across the GAC copy
jToken.ToString(Formatting.None)

// after — static method, signature stable across 13.x
JsonConvert.SerializeObject(jToken, Formatting.None)

JsonConvert.SerializeObject(object, Formatting) is the relevant difference. It is a static method whose signature has held across the 13.x line, and it is a different member from the one breaking, so the varying JToken.ToString overloads in the GAC copy never enter resolution. The token is serialized through the normal JsonSerializer path and the result is the JSON you expect.

The tradeoff is that this routes through default JsonSerializerSettings rather than the token's own write path. For a plain JToken the output matches ToString(Formatting.None), but if the application configures global default settings, output is no longer guaranteed byte-identical. Where that matters, prefer the explicit-overload fix, which changes only overload selection and leaves serialization behavior alone.

Both options are local mitigations. The root cause is the shared assembly version, and that is being addressed upstream. 13.0.5-beta1 is out as of December 30, 2025 and is intended to resolve the binding problem permanently; the maintainer has asked people hitting this to try it and report back. Until a stable release lands and reaches the machines registering the GAC copy, the changes above are the reliable way to keep working.

The narrowing that got me here was mechanical, with help from a senior colleague:

Confirmed the failure was in the JToken.ToString(Formatting.None) path.
Checked the build output folder: a newer Newtonsoft.Json.dll was present and did contain the member.
Checked the GAC: an older copy was present.
Compared against CI, where the test passes, which left local assembly resolution as the only difference between the two environments.
Matched the behavior against the upstream issues describing the same strong-name and GAC collision.

When a build succeeds everywhere except one class of machine, the difference is usually not in the code. On a managed Windows workstation the GAC is shared, writable by other software, and authoritative for strong-named assemblies, which means a dependency you never installed can quietly take precedence over the one you shipped.

References

JamesNK/Newtonsoft.Json#3084 — JObject.ToString MissingMethodException when an app built against a newer 13.0.x loads an older one from the GAC, with the maintainer's overload workaround.
JamesNK/Newtonsoft.Json#3095 — the same failure on JToken.WriteTo, framed around the shared assembly version and the binding-redirect and security implications.
Newtonsoft.Json 13.0.5-beta1 on NuGet (published 2025-12-30).
Global Assembly Cache article on Microsoft Learn.

Can Copilot be your AI pair programmer?

Witold Wozniak — Thu, 11 Jun 2026 18:10:21 +0000

My dear teammate decided to ruin my evening yesterday by asking an intriguing question: could you set up Copilot as a real pair programmer? Not the chat box you take turns with, but something that watches your code as you write it and reacts in the moment, the way a person at the next desk would. The short answer is no, not with anything you can install today.

What pairing means

GitHub launched Copilot in 2021 as "your AI pair programmer," and the same announcement described it adapting to you as you type. The thing was named for pairing and built for autocomplete, so it is fair to ask whether it can do the thing on the label. None of what follows is news, but I am spelling it out because the rest of the piece holds the product to these exact terms.

Pair programming is a core practice of Extreme Programming, with a definition that predates Copilot by two decades. The usual articulation gives it two roles. The driver types; the navigator reviews each line as it appears, watches for the mistake before it lands, and thinks a step ahead about design. The navigator works while the driver is mid-line, not after a turn is handed over. The two swap roles every few minutes, and both stay engaged the whole time; a navigator who checks out is not pairing.

The navigator produces without touching the keyboard. The reviewing, the watching, the thinking ahead: that is the work. The canon is explicit about it — the oldest objection to pairing, that it doubles cost by paying two people for one person's typing, is a named misconception, precisely because programming is not typing. So the navigator, who writes almost nothing, is the harder half to automate: the job is continuous real-time oversight, catching the wrong thing the instant it appears and saying so before it costs anything.

Hold the product against that definition. A tool that completes your line as you type is doing the driver's job, faster — filling the keyboard, the part the canon just told us was never the point. It is not in the loop with you. It never reacts to its own last suggestion, it never waits for yours, and it never takes the navigator's seat: it cannot watch you work and speak up, only wait to be asked.

Why not

From the outside, the model is a function. You hand it the whole context, it returns a complete answer. The only stream is the output, and it is read-only: you watch tokens arrive, but there is no second pipe to push new tokens into the call while it runs. To react to something new, you stop and make another call with the new context folded in. Every reaction is a fresh, full-context request. There is no "while you were typing" — there is only the next turn. (Stateful APIs that "remember" the conversation do not change this. They store the context so you do not have to resend it; the model still consumes it whole, one turn at a time.)

Voice is the proof of how solid that wall is. OpenAI's Realtime API and Google's Gemini Live feel like the real thing: they run over a live two-way connection, they talk while listening, they stop the instant you cut in. But underneath, they are still turn-based. Interruption is not the model hearing you mid-sentence and adjusting: it is the server detecting your speech, cancelling the response in flight, discarding the audio you had not heard yet, appending what you said, and starting a fresh turn. Often it happens fast enough that you do feel heard. [1] The industry spent real money building the full-duplex pipe for voice, and what it bought was an excellent imitation of mid-stream reaction, not the thing itself. A kind of "optimistic UI AI", if you will.

The architecture that genuinely does the thing exists. It is called full duplex, and the clearest example is a research speech model called Moshi, which runs your audio and its own as two parallel streams and conditions on your input every fraction of a second, with no stop and no restart. [2] And because a full-duplex model never stops generating, getting it to shut up when you interrupt is apparently harder, not easier, which is probably why Moshi has not made it into a code editor since its heroic escape from a French AI laboratory.

It seems that nobody has built full duplex for text because text does not need it. Speech is a continuous signal with no natural end, so the system has to guess when you are done. Text comes with a turn boundary built in. You press Enter, and the turn is over. No guessing which moment counts as done, because you explicitly say "I am done, your turn." This is the same reason I have to say "over" after asking my mom on my walkie-talkie to bring me another bag of Cheetos — an open channel gives you no way to hear that someone has finished, so the boundary has to be a word. The entire problem full duplex solves does not exist when the input already arrives pre-segmented, which is why nowadays I tend to text my mom on Signal.

How close you can get

Autocomplete is not pairing. It reacts as you type, but you cannot steer it, and it does not answer to your intent. It completes whatever you are writing regardless of what you meant, which makes it a fast stream of guesses with no interaction and no loop.

Agent mode is the real near-miss. It reasons about your work and responds to it, which is the engagement autocomplete lacks. But you have to hand it the turn: you write a prompt, send it, and wait for the burst of work to come back. The trigger does not have to be a prompt you type, though. OpenCode lets you wire it to an external event instead, like a file save or a failing test, through a plugin that injects a turn on its own, so the agent reacts to your activity without being explicitly asked.

Whether a harness can do that comes down to mechanism, not brand. Pretty much every decent harness has hooks, but hooks fire only on the session's own internal lifecycle. Reaching outside the session needs a plugin or extension layer on top, one that can inject a turn. OpenCode has it through plugins, and Copilot CLI through a separate extension system. Claude Code is the exception. It has hooks, but its plugin layer can't inject a turn, so the only external trigger is the SDK, which starts a fresh session instead of continuing the current one.

Either way it is still bursts, not full-auto. This can look like the AI taking the driver's seat while you navigate, but handing off a task and reviewing what comes back is a swap across a turn boundary, not the fluid trading of seats a shared loop needs.

Is it worth it

Suppose you hacked the agent loop tighter and fired it on every pause instead of every save. You would pay full context on every trigger, eat the latency of a fresh call each time, and drown in suggestions you never asked for. You would approximate continuity badly and noisily, and it would still be bursts. Firing more often does not turn a sequence of turns into a continuous stream. The gap between the near-miss and real pairing is not the cadence of the trigger, so no setting closes it.

When real pairing does reach a code editor, it will not be a Copilot setting. It will be a different kind of model. Until then, the honest answer is that he is stuck with me as his pairing partner.

Notes

[1] That interruption is cancel-and-restart, rather than the model editing a generation already in flight, is an inference from how transformer inference works, not a confirmed internal detail. OpenAI and Google document the protocol — voice activity detection, response cancellation, transcript truncation — but not the decode loop itself, so "abort and re-run" is a reasoned conclusion, not a stated one.

[2] Moshi. Défossez et al., Kyutai, 2024. The model processes the user stream and its own stream jointly as two autoregressive token streams at a 12.5 Hz frame rate (one 80 ms frame per step), discarding its prediction of the user stream and substituting the real incoming audio, which carries into context for the next step. That is genuine mid-decode conditioning. Measured latency around 200 ms, which is inside the range of a normal human conversational gap. The HuggingFace reference implementation is simplified and not real-time; the live full-duplex behavior is in Kyutai's own implementation. It is an open research model.

Sources

Pair programming, definition and the driver/navigator roles: the Agile Alliance glossary and Williams and Kessler, "Pair Programming Illuminated" (2002). The "doubles cost" objection is recorded there as a misconception that equates programming with typing; the driver/navigator framing postdates XP's original practice and is not universally accepted.
OpenAI, Realtime API documentation (voice activity detection, response cancellation, conversation.item.truncate, WebSocket/WebRTC/SIP transports).
Google, Gemini Live API documentation, ai.google.dev/api/live (BidiGenerateContent, interruption and turn handling).
OpenAI, streaming responses documentation (single HTTP request, server-sent events as one-directional output).
Défossez et al., "Moshi: a speech-text foundation model for real-time dialogue," 2024, arXiv:2410.00037.
GitHub Copilot CLI hooks reference and extensions documentation, docs.github.com (lifecycle hook events; the separate extension system over JSON-RPC).
Anthropic, Claude Code hooks documentation (internal lifecycle events) and Agent SDK.

JavaScript-less Mobile Menu with Tailwind

Witold Wozniak — Mon, 26 May 2025 13:36:17 +0000

JavaScript-less Mobile Menu with Tailwind

I've recently been working on a simple static website. One of the goals of the project was to challenge myself to improve my knowledge of CSS and Tailwind. I wanted to see how much I can do without a line of JavaScript. I explored different JavaScript-less options for mobile navigation menus, and the checkbox hack caught my attention.

It's simple, and it can teach you a thing or two about how to think outside of the box when it comes to your stylesheets. It can be made accessible with careful attention to ARIA attributes and focus management, though some advanced accessibility features (which are typically JavaScript-reliant) have limitations as discussed later. And here's a fun fact: you can use this pattern to toggle the visibility of anything on your page!

So here we are. Here's a JavaScript-less expandable / collapsible mobile navigation menu implemented with Tailwind. For those of you who may not be familiar with Tailwind CSS, it is a utility-first CSS framework that allows developers to rapidly build custom user interfaces directly in their markup by composing pre-defined classes. Instead of writing custom CSS for every element, you apply small, single-purpose utility classes like flex, pt-4, or text-center directly to your HTML. This approach promotes consistency, reduces the need for context switching between HTML and CSS files, and results in highly optimized stylesheets as only the used utilities are bundled.

Keep in mind the code here is minimal – no fancy styling, no accessibility – you'll likely want to handle those aspects yourself anyway. This is just to show you how to toggle visibility of an element.

If you're here just for the snippet, I'll save you some time — here's the basic code:

<nav>
    <div id="mobile-menu-container" class="md:hidden relative">
        <input
        id="mobile-menu-toggle"
        type="checkbox"
        class="peer absolute z-10 opacity-0"
        />
        <span id="kebab"
        class="relative z-0 block peer-checked:hidden"
        >⁝</span>
        <span
        id="x-mark"
        class="relative z-0 hidden peer-checked:block"
        >✕</span>
        <ul
        id="mobile-menu"
        class="hidden peer-checked:block"
        >
            <li><a href="ikea.com">Home</a></li>
            <li><a href="buymeacoffee.com/vitcosoft">Charity</a></li>
            <li><a href="medium.com/@vitcosoft">Reading</a></li>
        </ul>
    </div>
</nav>

But if you're curious, keep on reading for step-by-step instructions with some extras along the way. The pretty version of the menu is revealed along the way!

The Checkbox Hack Overview

The whole trick is based on three simple steps:

Place an invisible checkbox above your menu icon;
Place the menu outside the view;
Toggle menu visibility using the subsequent-sibling combinator based on the checkbox's state.

And that is it! Add some criminally smooth animations, AI-powered icons, and you've got yourself a fully functional, JavaScript-less mobile menu. Congratulations! Easier than centering a div, eh?

Implementation with Tailwind

Let me walk you through the implementation steps, so you can fully grasp the process.

Step 1: Markup

Let's set up some basic HTML, so we can start applying the Tailwind magic. We'll add a <div> to act as the mobile-menu-container:

<nav>
    <div id="mobile-menu-container">
    </div>
</nav>

Next, we need to pick the façade (usually a hamburger or kebab icon) that will fool the user by pretending to toggle the menu. For simplicity, let's use some Unicode chars depicting three dots and an x-mark. We also need to introduce the main protagonist of our little trick — the checkbox:

<nav>
    <div id="mobile-menu-container">
        <input id="mobile-menu-toggle" type="checkbox"/>
        <span id="kebab">⁝</span>
        <span id="x-mark">✕</span>
    </div>
</nav>

Finally, add the unordered list that will act as our navigation menu:

<nav>
    <div id="mobile-menu-container">
        <input id="mobile-menu-toggle" type="checkbox"/>
        <span id="kebab">⁝</span>
        <span id="x-mark">✕</span>
        <ul id="mobile-menu">
            <li><a href="ikea.com">Home</a></li>
            <li><a href="buymeacoffee.com/vitcosoft">Charity</a></li>
            <li><a href="medium.com/@vitcosoft">Reading</a></li>
        </ul>
    </div>
</nav>

The key consideration here is that the checkbox, the icons, and the list are all sibling elements, marked as peers in Tailwind.

Step 2: Tailwind styles

Now that we have our markup in place, we can start the styling.
Let's begin by making our container hidden on larger screens and setting its position to relative:

<nav>
    <div id="mobile-menu-container" class="md:hidden relative">
        <input id="mobile-menu-toggle" type="checkbox"/>
        <span id="kebab">⁝</span>
        <span id="x-mark">✕</span>
        <ul id="mobile-menu">
            <li><a href="ikea.com">Home</a></li>
            <li><a href="buymeacoffee.com/vitcosoft">Charity</a></li>
            <li><a href="medium.com/@vitcosoft">Reading</a></li>
        </ul>
    </div>
</nav>

Why do we want it relative? Since this trick is dependent on the z-index property, we want to keep things clean and create a "local" stacking context within our container. Also, z-index only works with elements positioned otherwise than static. Let's now add utility classes to the checkbox:

<nav>
    <div id="mobile-menu-container" class="md:hidden relative">
        <input
        id="mobile-menu-toggle"
        type="checkbox"
        class="peer absolute z-10 opacity-0"
        />
        <span id="kebab">⁝</span>
        <span id="x-mark">✕</span>
        <ul id="mobile-menu">
            <li><a href="ikea.com">Home</a></li>
            <li><a href="buymeacoffee.com/vitcosoft">Charity</a></li>
            <li><a href="medium.com/@vitcosoft">Reading</a></li>
        </ul>
    </div>
</nav>

Here's a breakdown of what happened:

opacity-0 will make the checkbox invisible to eyes, while keeping its position and interactivity intact;
z-10 places the checkbox one level above siblings within mobile-menu-container;
absolute places the input element outside the normal flow of the document, so it no longer occupies space where it would normally be placed, which allows us to place it above its siblings;
peer is a utility class that allows us to style sibling elements based on the properties and state of this particular element.

This is the minimal setup for our checkbox. Let's now shift our attention to the icons. The reason we have two icons is simple: they will switch places depending on the state of the checkbox:

<nav>
    <div id="mobile-menu-container" class="md:hidden relative">
        <input
        id="mobile-menu-toggle"
        type="checkbox"
        class="peer absolute z-10 opacity-0"
        />
        <span id="kebab"
        class="relative z-0 block peer-checked:hidden"
        >⁝</span>
        <span
        id="x-mark"
        class="relative z-0 hidden peer-checked:block"
        >✕</span>
        <ul id="mobile-menu">
            <li><a href="ikea.com">Home</a></li>
            <li><a href="buymeacoffee.com/vitcosoft">Charity</a></li>
            <li><a href="medium.com/@vitcosoft">Reading</a></li>
        </ul>
    </div>
</nav>

Let's break this down a bit:

relative, again, allows elements to use z-index, but does not move them from their normal document flow;
z-0 — technically, we do not need to set z-index here (the input will have already been placed above the icons), but we want to be explicit about our intent, which is placing these particular elements below the checkbox;
block and hidden set initial states of the icons — the kebab as visible, and x-mark as initially hidden;
peer-checked:hidden and peer-checked:block hides the kebab and reveals the x-mark when the peer checkbox has state of checked.

Strictly speaking, the trick is complete. We manipulate visibility of these elements based on the state of the checkbox. But the title promised you a mobile menu, so let's apply the same logic to the unordered list:

<nav>
    <div id="mobile-menu-container" class="md:hidden relative">
        <input
        id="mobile-menu-toggle"
        type="checkbox"
        class="peer absolute z-10 opacity-0"
        />
        <span id="kebab"
        class="relative z-0 block peer-checked:hidden"
        >⁝</span>
        <span
        id="x-mark"
        class="relative z-0 hidden peer-checked:block"
        >✕</span>
        <ul
        id="mobile-menu"
        class="hidden peer-checked:block"
        >
            <li><a href="ikea.com">Home</a></li>
            <li><a href="buymeacoffee.com/vitcosoft">Charity</a></li>
            <li><a href="medium.com/@vitcosoft">Reading</a></li>
        </ul>
    </div>
</nav>

And that is basically it! We can now toggle the menu visibility without any JavaScript! This one's for all of the JavaScript haters out there.

(bonus) Step 3: Let's make it pretty!

If you made it till the end — below lies the prettier version of this menu. And more accessible, because accessibility is beautiful by definition. For instance, this enhanced version (seen in the linked example and the snippet you're reviewing) bolsters accessibility through several specific improvements:

Clearer Control Description: The underlying checkbox is often made visually hidden (e.g., using an sr-only class) but remains accessible to assistive technologies. It's given a descriptive aria-label like "Open or close navigation menu" to clearly state its purpose.
Programmatic Linking: The aria-controls attribute is added to the checkbox to create a programmatic link with the menu panel (e.g., id="mobile-menu-panel") that it shows and hides. This helps assistive technologies understand the relationship between the control and the content it affects.
Focusable Visual Toggle: The visible part that users click or tap (often a <label> associated with the checkbox) is made explicitly keyboard focusable (e.g., using tabindex="0" if it's not an inherently focusable element acting as the label) and receives clear visual focus indicators (like focus:ring-2 focus:ring-white).
Semantic Menu Region: The menu panel itself is given a role="region" and an aria-label (e.g., "Mobile navigation") to define it as a distinct landmark region, making it easier for screen reader users to navigate and understand the page structure.
Enhanced Focus Visibility: All interactive elements within the open menu, such as navigation links and any explicit "Close menu" buttons (which might also be a <label> for the same checkbox), are designed with clear and visible focus styles.

Hopefully, these examples will inspire you to make something even better!

Check the code out here ==> play.tailwindcss.com

Note: In programming, every decision is a tradeoff

One feature of computer programming that makes us feel powerful and powerless all at the same time is the fact that everything can be done in a myriad of ways — which makes every decision a tradeoff. Here are some notable considerations regarding the advantages and drawbacks of this implementation of a mobile navigation menu:

Strengths:

JavaScript-Free Operation: Works reliably without client-side scripting, enhancing robustness and broad compatibility.
CSS-Powered Interactivity: Leverages performant, native CSS for smooth animations and state management, avoiding JavaScript overhead.
Core Accessibility Can Be Achieved: The checkbox itself provides basic keyboard navigation. With additions such as ARIA attributes and custom focus indicators (as demonstrated in the linked example), good core accessibility is possible.
Lightweight Implementation: Avoids JavaScript file weight and execution, potentially leading to faster component rendering.

Weaknesses:

Advanced Accessibility Gaps: Lacks JavaScript-dependent features like true focus trapping within the open menu or dynamic aria-expanded on a semantic button.
Semantic Compromise: Employs a checkbox for UI toggling, which is a functional workaround rather than the element's primary semantic role.
Limited UX Patterns: Cannot implement common user experience enhancements like "click outside to close" or "Escape key" closure.
Structural Rigidity: Requires a specific HTML element order and sibling relationships for the CSS selectors to function, reducing layout flexibility.

It's a cool hack, but a hack nonetheless. Thanks for reading!

DEV Community: Witold Wozniak

Resolving MissingMethodException in Newtonsoft.Json

The problem

The explanation

The fix

References

Can Copilot be your AI pair programmer?

What pairing means

Why not

How close you can get

Is it worth it

Notes

Sources

Further reading

JavaScript-less Mobile Menu with Tailwind

JavaScript-less Mobile Menu with Tailwind

The Checkbox Hack Overview

Implementation with Tailwind

Step 1: Markup

Step 2: Tailwind styles

(bonus) Step 3: Let's make it pretty!

Note: In programming, every decision is a tradeoff

Strengths:

Further reading