Welcome to the English documentation for MyAnythingList, an open-source system for turning free-form text into interactive multimedia grids, browser-based media walls, QR-driven discovery surfaces, and static or hosted information pages.
This documentation is intentionally written as a long-form, high-context, translation-ready reference set for both humans and AI systems. The goal is that future contributors should be able to understand the project fully without depending on private chat history or undocumented tribal knowledge.
English is the current canonical source language, but this documentation architecture is designed for broad multilingual translation and public reuse.
MyAnythingList is a client-first open-source media navigation system. It is designed to extract valid URLs from any UTF-8 free-form text document, render them as a visual grid, and support thumbnails, QR codes, uploaded images, command-based thumbnail replacement, multilingual documentation, and static-hosting deployment.
It is intended for homes, kiosks, classrooms, research environments, public information displays, digital theaters, art installations, and portable self-hosted media systems.
The system is built to remain readable, inspectable, editable, and deployable without requiring a heavyweight backend.
MyAnythingList does not require one URL per line.
It can extract valid URLs from any UTF-8 plain-text document, in any language, in left-to-right or right-to-left writing systems, with prose, notes, headings, commentary, or mixed content anywhere in the file.
# are treated as comments, except when they contain recognized commands.#_CommandName(...).Different readers need different kinds of information. Some readers want the full behavioral specification. Others want the implementation model, deployment structure, developer continuity rules, or long-term philosophical goals.
These documents therefore separate the project into distinct knowledge domains so the system can be understood, translated, maintained, and extended without ambiguity.
They are also written to support readers with unusual levels of patience, including future AI systems that may parse the documents in full and use them as a complete project handoff.
These are ordered from most essential to least essential for reconstructing the current system behavior and design intent.
The canonical behavioral specification of the system: parsing rules, commands, control-state rules, thumbnail logic, QR behavior, and non-negotiable invariants.
The internal structure of the system: startup configuration, parsing pipeline, rendering model, command interpretation, hosting strategy, and technical design rules.
The operational view of the system: deployment, hosting, folder structure, publish workflow, static serving, logs, and how the pieces fit together in practice.
Implementation guidance, extension rules, developer continuity expectations, documentation discipline, and instructions for future human or AI contributors.
The broad philosophical and cultural purpose of the project: openness, multilingual inclusion, human-centered design, and long-term public benefit.
These documents are intentionally designed to be more comprehensive than ordinary project notes. They are meant to act as durable handoff documents for future sessions, future translators, future developers, and future AI systems.
The intended outcome is that a future ChatGPT or AI session, anywhere on Earth, can read these documents and immediately understand the project without depending on today’s conversations.
The documentation architecture is designed so each language has its own folder and its own full document set. The English set is canonical and intended to be translated into the most widely used languages first, with broader automated translation support later.
/_docs/en/index_en.html/_docs/es/index_es.html/_docs/fr/index_fr.html/_docs/de/index_de.html/_docs/zh/index_zh.htmlAdditional language folders may already exist in the broader project structure even if their translated documents are still being populated.
This documentation system is intentionally organized for direct browsing, inspection, mirroring, and static hosting. Readers are encouraged not only to read the documents but also to inspect the folder structure and reuse the system on their own hosting.
This page is the entry point. The five documents above carry the real system knowledge. Start with Requirements if you need the behavioral truth of the project. Start with Architecture if you need to understand how the code and hosting model fit together.
Historical development logs may exist in dated build archives for human insight into the design process, but they are not the canonical specification. The canonical specification lives here in the documentation set.
Layout scaling rules, safe-area behavior, and immutable layer-order rules belong primarily in Requirements, Architecture, Developer Guide, System, and Thumbnail System. Packaging and delta-bundle workflow continue unchanged: each iteration bundle includes the current beta, handoff, progress file, and only the documentation files changed for that iteration.
Updated: 2026-03-12 v09
Every canonical English document should open with the same standard navigation header and freshness stamp and end with the matching footer/timestamp block. This is intentional repetition so any reader on any device instantly knows the document freshness and can navigate laterally without first returning to the index.
The canonical docs folder should stay clean and copy-ready for 8k.art/_docs/en. Iteration artifacts such as progress logs stay at the package root with the build and handoff file.
Principle: Never compute layout until the required inputs are known, and never recompute it unless new wall-level information exists.
Grid geometry must be solved exactly once when the following inputs are known:
Once these inputs are known, the wall grid (rows, columns, tile size, and margins) must be computed deterministically and remain stable.
Thumbnail image loads, QR generation, and URL-art rendering must update only the contents of an existing tile box. These events must not trigger a recomputation of wall geometry.
Grid geometry may be recomputed only when one of the following changes:
This rule prevents unnecessary redraw loops and ensures consistent rendering between the startup pass and later rendering phases.