DEV Community: Liangxiao's notes

The last mile of AI slides: a local-first HTML editing workflow

Liangxiao's notes — Sun, 16 Aug 2026 15:16:26 +0000

AI can produce a surprisingly good presentation draft in one prompt. The difficult part usually arrives after the draft is useful: one line wraps badly, a heading needs emphasis, a screenshot is missing, or one slide has too much content.

That final pass should not require another prompt loop or a full rewrite. I built AI HTML Slide Editor around this narrower workflow: take a single-file HTML deck generated by an AI tool, make supported visual corrections in the browser, and export one clean HTML file when the presentation is ready to share.

The problem is not generation

Most slide generators optimize for the first draft. In a real delivery workflow, the first draft is often structurally right but visually unfinished. Re-running a generation can solve one detail while changing several others. Manual source editing is precise, but it also turns a small review task into a hunt through nested HTML and CSS.

The useful middle ground is a visual editor with a deliberately limited scope. It should preserve a one-file deck, identify slide-like sections, and make small corrections easy without pretending that every arbitrary web page can be losslessly converted into a slide system.

What the browser workflow supports

The editor starts with either a local HTML upload or a built-in sample. It then provides a visual canvas for supported edits:

Correct text directly in the canvas.
Adjust supported formatting such as bold, italic, font size, and color.
Insert or replace local images.
Add, duplicate, delete, and reorder pages.
Detect and fix supported overflow cases before delivery.
Copy a selected block as PNG when a small visual asset is needed.
Export the corrected result as a clean single-file HTML deck.

This is intentionally a final-editing workspace, not another AI slide generator and not a native PPTX exporter. It also does not execute arbitrary user JavaScript. Those boundaries make the behavior easier to reason about when a presentation contains local content that should remain in the browser.

Why local-first matters here

Presentation drafts commonly contain internal copy, early positioning, screenshots, or customer context. A local-first pass avoids making an account or cloud upload the default requirement for a small visual correction. The browser sanitizes the imported file, keeps editing in the client, and gives the user a single HTML export to retain or share.

There is a practical product lesson in that constraint. The editor does not need to solve every possible editing problem. It needs to make the final review pass calmer: keep the useful draft, repair the visible issue, check the result, and finish.

If you generate one-file HTML presentations with an AI tool and want that post-generation review step, try AI HTML Slide Editor.

How We Turned One AI Pet Generator Into Four Clear Product Paths

Liangxiao's notes — Wed, 12 Aug 2026 16:31:03 +0000

I started PetMorph with a familiar AI-product problem: the system could create many kinds of pet images, but the interface was asking people to understand the model instead of their own goal.

The better product was not a bigger style selector. It was four plain-language paths inside PetMorph:

Pet Human for the curiosity of seeing a pet reimagined as a person;
Pet Portrait for avatars, keepsakes, and shareable artwork;
Pet ID Photo for a clean, centered passport-style result;
Pet Holiday Card for birthdays, Christmas, Halloween, and New Year.

Each path starts from the same thing — one clear pet photo — but leads to a different job.

The problem with a generic generator

A single prompt box looks flexible, but it moves the hard work to the user.

People have to decide which words to use, which style controls matter, and whether the result is meant for fun, a profile picture, a document-style image, or a celebration. A wall of presets does not remove that uncertainty; it only gives it more buttons.

So the product question became:

What is the user trying to make right now?

That question produced a much clearer information architecture than asking users to choose a model or prompt recipe.

Use cases, not just styles

The four paths are intentionally treated as stable use cases rather than four unrelated generators.

They share the same product foundation, but each route has its own:

promise and examples;
upload guidance;
result framing;
safety or expectation notes;
direct creation entry point.

This lets the homepage explain the whole brand while each product page can focus on one task. It also avoids forcing search visitors into a generic dashboard before they understand what the tool does.

One product framework

The implementation keeps those four use cases in a shared product configuration. Navigation, homepage cards, landing pages, and creation links read from the same source of truth.

That small decision matters more than it sounds. Without it, labels and routes drift: one page says “pet avatar,” another says “portrait,” and a third sends users to a generic create screen with the wrong preset.

The current web stack uses Next.js, React, TypeScript, and Tailwind CSS. The shared framework is deliberately simple: stable IDs, localized text keys, explanation URLs, and creation URLs.

Designing for trust

AI image products often hide important boundaries behind a friendly upload box. PetMorph keeps the most relevant ones close to the task:

use a clear, well-lit photo;
uploads are validated before generation;
images are sent to an AI service to create the result;
generated images may be stored temporarily for downloads and account history;
an ID-style pet image is creative output, not an official document;
usage still depends on the source-photo rights, terms, and applicable law.

The goal is not to make the interface feel legalistic. It is to make the product promise match what the system can actually do.

What changed in the experience

The homepage now answers three questions in order:

What can I make from one pet photo?
Which path fits my goal?
What do I need to know before I upload?

Real before-and-after examples sit beside the four use cases. Free everyday tools — such as pet-name and pet-age helpers — live in a separate layer so they do not compete with the core creative workflow.

New users can try two creations after signing in, and the product uses one-time credit packs instead of requiring a subscription.

What I learned

The hard part of an AI product is often not adding capability. It is reducing interpretation work for the user.

“Generate a pet image” is a system capability. “Make a portrait I can keep,” “show me my pet as a person,” and “create a birthday card” are user goals.

Once those goals became the product structure, the copy, routes, examples, and calls to action became easier to keep consistent.

You can explore the live product at petmorph.app. I would be especially interested in feedback on whether the four paths feel distinct before you upload a photo.

How We Built an Emoji Translator Without AI

Liangxiao's notes — Wed, 12 Aug 2026 14:11:38 +0000

I wanted an emoji translator that was useful without pretending it could read a sender’s mind.

That constraint shaped the first version of Emoji Translator: a bidirectional tool that translates emoji sequences into plain-English reference results and turns English text into emoji variants.

Instead of using an AI model for V1, the product relies on versioned Unicode and CLDR reference data, reviewed editorial combinations, and explicit rules.

Why start without AI?

Emoji meaning is contextual. The same symbol can be playful, sarcastic, affectionate, or literal depending on the conversation.

An AI-generated answer can sound confident even when the evidence is weak. For an early reference tool, that creates the wrong product expectation. I wanted every result to have a clear boundary:

show official names and common usage;
handle reviewed combinations where we have evidence;
preserve the difference between reference meaning and personal intent;
never generate a confidence score that the system cannot justify;
never claim to know what a sender privately meant.

This makes the output less magical, but more predictable.

Two different user tasks

“Emoji to English” and “Text to Emoji” look symmetrical, but they are different workflows.

For emoji-to-English, users want an explanation. The interface needs to surface the reference meaning, possible usage, and important context limits.

For text-to-emoji, users want a usable transformation. The product returns minimal, balanced, and emoji-heavy variants so the user can choose the right level instead of receiving one opaque answer.

Keeping these directions separate improved the page hierarchy, labels, examples, and result states.

Architecture

The application uses:

TanStack Start and TanStack Router;
React and TypeScript;
Tailwind CSS;
Cloudflare Workers;
Vitest and Playwright.

Public tool, meaning, trust, and discovery pages are rendered for search and fast first paint. Translation inputs are not included in route-level analytics.

The V1 data layer is deliberately small: no database, account system, payment system, or message history. Unicode/CLDR data and reviewed combinations stay versioned with the application, so changes can be reviewed and tested.

Designing the interface

The primary tool stays above the fold. Users can choose the translation direction, enter content, see examples, and understand the privacy boundary without first scrolling through an SEO article.

The supporting content then connects the tool to emoji meaning references. That gives the site a useful information architecture instead of turning every keyword into an isolated thin page.

The visual system uses Instrument Sans, a warm neutral background, and a focused blue action color. Desktop and mobile layouts share the same task hierarchy rather than treating mobile as a compressed desktop screenshot.

What I learned

The hardest part was not mapping characters to labels. It was defining what the product should refuse to imply.

A deterministic system can still be helpful when it is honest about its limits. It also creates a stable evaluation baseline. If contextual AI is added later, it can sit behind the same product boundary and be compared against known reference behavior instead of silently replacing it.

You can try the live product at emojitranslator.org.

The public project notes, examples, and contribution guide are available in the Emoji Translator website repository.

How Browsers Detect Double Clicks — And Why Your Mouse Might Be Lying to You

Liangxiao's notes — Mon, 09 Mar 2026 10:26:20 +0000

Have you ever wondered how your browser knows the difference between two single clicks and one double click? Or why your mouse sometimes registers a double click when you only clicked once?

I built a double click testing tool and learned some surprising things about browser event timing, hardware debounce, and why millions of mice develop "phantom" double clicks. Let me walk you through what I found.

The Browser's Click Detection Model

When you press a mouse button, the browser fires events in this exact order:

mousedown → mouseup → click → mousedown → mouseup → click → dblclick

The key question: how does the browser decide when two click events become a dblclick?

The answer is a hidden timer. If two clicks happen within a certain interval, the browser fires dblclick. This interval varies:

OS	Default Double-Click Interval
Windows 11	500ms
macOS	300-500ms (user configurable)
Linux (X11)	400ms

You can test this yourself:

let lastClick = 0;

document.addEventListener('click', (e) => {
  const now = performance.now();
  const interval = now - lastClick;

  if (lastClick > 0) {
    console.log(`Click interval: ${interval.toFixed(1)}ms`);

    if (interval < 500) {
      console.log('→ Browser will fire dblclick');
    }
  }

  lastClick = now;
});

document.addEventListener('dblclick', (e) => {
  console.log('dblclick event fired!');
});

The Hardware Problem: Contact Bounce

Here's where it gets interesting. Inside your mouse, a mechanical microswitch has a tiny metal spring that snaps between two contacts:

Normal Click:
  ┌──── Spring makes contact
  │
  ▼
  ON ─────────────────── OFF

Worn Switch (Contact Bounce):
  ┌──── Spring vibrates on contact
  │
  ▼
  ON ─ OFF ─ ON ─ OFF ─ ON ──── OFF
       ↑
       These micro-bounces can register
       as separate click events

When the metal spring oxidizes or loses tension (typically after 1-2 years of heavy use), it starts bouncing when it makes contact. Each bounce can register as a separate electrical signal.

The mouse firmware has debounce logic to filter these out:

// Simplified debounce logic (similar to what runs in mouse firmware)
const DEBOUNCE_MS = 10; // typical: 5-15ms
let lastSignal = 0;

function onSwitchSignal() {
  const now = Date.now();
  if (now - lastSignal < DEBOUNCE_MS) {
    return; // ignore bounce
  }
  lastSignal = now;
  sendClickEvent();
}

But here's the catch: as the switch wears out, bounce intervals get longer, eventually exceeding the debounce window. When a bounce at 15ms slips past a 10ms debounce filter, your OS sees two separate clicks within ~15ms — well within the 500ms double-click window.

Result: phantom double click.

Detecting Double Click Issues in JavaScript

How do you tell the difference between a real double click and a hardware malfunction? Timing analysis.

A human physically cannot double click faster than ~50ms. Most intentional double clicks happen in the 100-300ms range. So if we see two clicks with an interval under 50ms, it's almost certainly a hardware bounce:

class DoubleClickDetector {
  constructor() {
    this.clicks = [];
    this.issues = [];
  }

  recordClick(timestamp) {
    this.clicks.push(timestamp);

    if (this.clicks.length < 2) return null;

    const interval = timestamp - this.clicks[this.clicks.length - 2];

    // Human minimum double-click speed is ~50ms
    // Anything faster is likely hardware bounce
    if (interval < 50) {
      this.issues.push({
        interval,
        timestamp,
        verdict: 'HARDWARE_BOUNCE'
      });
      return 'HARDWARE_BOUNCE';
    }

    if (interval < 100) {
      return 'SUSPICIOUS';
    }

    return 'NORMAL';
  }

  getReport() {
    const total = this.clicks.length;
    const bounces = this.issues.length;
    return {
      totalClicks: total,
      detectedBounces: bounces,
      bounceRate: ((bounces / total) * 100).toFixed(1) + '%',
      issues: this.issues
    };
  }
}

Why Optical Switches Don't Have This Problem

Newer mice use optical switches instead of mechanical ones:

Mechanical Switch:
  Metal spring → Physical contact → Electrical signal
  Problem: Metal fatigues, oxidizes, bounces

Optical Switch:
  Button press → Blocks/unblocks light beam → Signal
  No metal contact → No bounce → No phantom double clicks

Optical switches can't double click because there's nothing to bounce. The signal is either "light blocked" or "light not blocked" — binary, with no intermediate state.

This is why the Razer Viper series and SteelSeries Prime use optical switches and market them as "double-click proof."

Building a Click Timing Analyzer

Want to build your own diagnostic tool? Here's a minimal implementation:

const results = document.getElementById('results');
const testArea = document.getElementById('test-area');
const clicks = [];

testArea.addEventListener('mousedown', (e) => {
  const now = performance.now();
  clicks.push({ time: now, button: e.button });

  if (clicks.length >= 2) {
    const prev = clicks[clicks.length - 2];
    const interval = now - prev.time;

    const status = interval < 50
      ? '🔴 BOUNCE DETECTED'
      : interval < 100
        ? '🟡 Suspicious'
        : '🟢 Normal';

    results.innerHTML += `
      <div>Click #${clicks.length} |
      Interval: ${interval.toFixed(1)}ms |
      ${status}</div>
    `;
  }
});

<div id="test-area" style="
  width: 300px;
  height: 200px;
  background: #1a1a2e;
  color: white;
  display: flex;
  align-items: center;
  justify-content: center;
  cursor: pointer;
  border-radius: 8px;
  user-select: none;
">
  Click here to test
</div>
<div id="results"></div>

Key Takeaways

Browsers use a time window (300-500ms) to distinguish single clicks from double clicks — this is OS-level, not configurable by web developers.
Mechanical mouse switches degrade over time, and worn switches produce electrical bounces that firmware can't always filter.
Click intervals under 50ms are physically impossible for humans — if you see them, it's a hardware issue.
Optical switches solve the problem at the hardware level by eliminating metal-to-metal contact entirely.
If you suspect your mouse has a double-click issue, you can test it with timing analysis — check the intervals between your clicks and look for anything under 50ms.

I built doubleclicktest.xyz to do exactly this — it analyzes click timing in real-time and tells you if your mouse button is malfunctioning. It's free and works in any browser, no download needed.

Have you dealt with the double-click problem on your mouse? What was your fix? Drop a comment below 👇