ArtCraft is a useful example. Its upstream README describes an IDE for interactive AI image and video creation, including 2D composition, 3D scene staging and a catalog of model providers. Its source is available under MIT or Apache-2.0, with separate notices for third-party material.

Separate the software license from the generation service

The app's code license tells you how you may use and redistribute that code. It does not establish the price, availability or output rights of every model the app can access.

The current upstream README lists providers including Grok, Midjourney, Sora and World Labs. It also marks some catalog entries as disabled or restricted. Treat that catalog as a changing integration list, not a promise that every model runs on your GPU.

Separate the studio from the other Crafting Apps

The official site also has a Crafting Apps section describing native open-source editors for images, vectors, CAD and other work. Those apps have their own development status and downloads.

A local editor working on your files and an AI generation service are not interchangeable. Before calling a workflow offline, check the specific app, operation, model and version. The existence of a local image editor does not establish that an image-generation request stays local.

A checklist before publishing a setup guide

1. Link to the upstream release and identify the app you mean.

2. Record the version and date for platform and feature claims.

3. Distinguish editing on the device from model inference.

4. Check model-provider pricing and terms separately from the app license.

5. Do not turn a minimum hardware suggestion into a measured speed claim.

6. Label affiliate recommendations as affiliate recommendations, not required dependencies.

A guide can still be useful without a claim like "everything is free forever." Clear boundaries save readers from installing a tool for a workflow it does not provide.

I run ArtCraft Guide, an independent guide site, not the upstream project. This distinction between software, models and services is the standard a third-party guide needs to meet.

Sources, checked October 21, 2026:

• github.com/storytold/artcraft

• getartcraft.com

• getartcraft.com/apps

Disclosure: I operate the linked guide site. It contains affiliate and referral links. I do not develop ArtCraft, and this article is a source-based explanation, not a claim of hands-on benchmarking.

This is a code-level look at martinfightinggame.net, a site I run. The game is Martin: No Filter Fighters, created by TDHampton Productions and published by Trey2k23 on itch.io. I run the independent play page and guide, not the game studio. These notes describe the page code, not a cross-browser test report.

Same-origin is a tradeoff

The game iframe points at /game-proxy/index.html on the same domain. Same-origin framing allows parent and child DOM access, subject to sandbox restrictions. A separate origin provides isolation that this setup does not.

An iframe URL is not evidence of a license. A free-to-play release does not establish permission to redistribute a game and its assets.

Read the permissions, but do not overpromise

The iframe declares allow="autoplay; fullscreen; gamepad; focus-without-user-activation *" and allowfullscreen="true".

That list is configuration, not proof every feature works. MDN documents the gamepad policy's default allowlist as *, so omitting an explicit gamepad token does not always disable controllers. Browser support and the parent page's Permissions-Policy still matter.

An autoplay declaration does not override browser audio restrictions. A real play action is a better point to start audio. The presence of a focus-related token should not replace testing clicks and keyboard input.

Make the handoff to the game visible

The iframe has tabindex="0". The start action dismisses the loading overlay and attempts to call contentWindow.focus(); the reload action also attempts to focus the game.

A useful test sequence is to start, click outside, return to the game, and try the controls again. Include keyboard-only navigation. The page also prevents arrow-key and space scrolling when the iframe is active or the page is in fullscreen. Keep that condition narrow so normal page navigation still works outside play.

Reserve space, then measure it

The wrapper combines a 16/9 aspect-ratio class with minimum heights of 420px and 540px at different breakpoints. The iframe fills that wrapper and uses loading="eager".

A minimum height can override the height suggested by an aspect ratio. A class named 16/9 does not guarantee a 16:9 box at every width. Inspect the rendered dimensions on narrow screens and check whether the game scales, crops or letterboxes.

Fullscreen needs a deliberate action

The cabinet button requests fullscreen on the game wrapper. A separate global control requests it on the document. The mobile landscape action attempts fullscreen and then an orientation lock, catching failures.

MDN documents requestFullscreen() as requiring transient user activation. Its promise can reject, so keep a usable non-fullscreen layout. A visible button is easier to discover than a keyboard shortcut alone.

Loading feedback should say what it measures

The loading bar advances on a timer, with random increments until 88%, then reaches 100% in the iframe load handler. That is simulated progress, not measured download progress or proof the game has finished initializing.

A child-to-parent ready signal would give a clearer readiness boundary. If measured progress is unavailable, an indeterminate message is more honest than a precise-looking percentage.

Give the surrounding page a job

Controls and character guides should help someone play and find the creator, rather than repeat a title around an iframe.

The example page is martinfightinggame.net. The creator's original release is on itch.io.

References: MDN iframe, requestFullscreen, and gamepad policy.

Disclosure: I operate martinfightinggame.net. This article promotes my site while crediting the game's creator. It does not claim that I developed the game or hold rights to its characters or assets.

The problem

Ask a general-purpose LLM for a perfume recommendation and you'll get confident, plausible answers - with notes that don't exist, dupes it can't prove, and "facts" assembled from marketing copy. Fragrance is unusually vulnerable to this because most of us can't verify a note pyramid by memory.

The approach

ScentAI grounds everything in a catalog: accords, top/heart/base notes, and concentration for each fragrance. The AI finder takes a plain-language request ("something green and quiet for the office") and resolves it against real catalog entries - the output is ranked matches with the reasons shown, and every reason points back to a catalog field. If a detail isn't in the catalog, the UI says so instead of papering over it.

The similarity engine

Starting from a perfume you own, ScentAI computes accord and note overlap and shows the percentage on every comparison. Two formulas can be compared side by side. This is my answer to the internet's favorite fragrance question - "what's a dupe for X?" - without claiming clones I can't prove.

Anonymous votes

Like / own / want / tried votes need no account and feed the trending lists. Accounts are the default growth lever for products like this; I wanted to see how far I could get without one.

What I learned

Constraining the AI to a catalog costs coverage (the catalog is always smaller than the world) but buys trust. Users forgive "I don't know" far more readily than a confident wrong answer.

Disclosure: I built ScentAI and this post describes my own product. The site contains affiliate links - I may earn a commission if you buy through them.

Try it: https://getscentai.com - curious what this community thinks of the catalog-constrained approach.

So I built a random color generator with the accessibility check built in: randomcolorgenerator.app - every color it generates instantly shows its WCAG 2.1 contrast ratio against white (#FFFFFF) and dark (#0F172A), with AA/AAA badges.

How the contrast ratio works

WCAG 2.1 defines contrast ratio as (L1 + 0.05) / (L2 + 0.05), where L1 and L2 are the relative luminances of the lighter and darker colors. Relative luminance comes from the sRGB channels:

1. Convert each channel to the 0-1 range.

2. Linearize: if c <= 0.03928 then c / 12.92, otherwise ((c + 0.055) / 1.055) ^ 2.4

3. L = 0.2126 * R + 0.7152 * G + 0.0722 * B

In JavaScript:

function luminance(r, g, b) {
  const f = (c) => {
    c /= 255;
    return c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4);
  };
  return 0.2126 * f(r) + 0.7152 * f(g) + 0.0722 * f(b);
}

function contrastRatio(l1, l2) {
  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);
  return (lighter + 0.05) / (darker + 0.05);
}

The thresholds to remember: 4.5:1 for AA normal text, 3:1 for AA large text (18pt+, or 14pt bold), and 7:1 for AAA normal text.

Two things I learned building it

• Mid-luminance colors are the danger zone. A hue that looks "clearly different" from your background can still sit under 3:1.

• Checking against both a white and a dark surface matters - a color that passes on one often fails on the other.

The site also has one-click HEX/RGB/HSL copy, a palette generator, shareable color URLs, and a guess-the-HEX game. Free, no signup, commercial use fine. Feedback very welcome - what would make this more useful in your workflow?