architecture_en.html
This document describes how the MyAnythingList system is built internally. It explains
the startup model, parsing model, rendering model, state model, and deployment model.
It is the technical companion to the behavioral truth defined in requirements_en.html.
The system can be understood as a sequence of transformations:
free-form UTF-8 text → URL discovery → comment / command parsing → tile model construction → thumbnail and QR resolution → grid rendering → interactive control state
The user does not need to learn a rigid playlist syntax first. The architecture exists to extract useful structure from ordinary text.
The top of the main application file follows a standardized architecture.
<meta charset="UTF-8" />
<title>generic fallback title</title>
<!-- Build: ... -->
<!-- Source files: ... -->
window.MyAnythingListConfig = { ... };
const BUILD_FILE = "...";
const ProjectSourceURL = "...";
const PageTitle = "...";
const HeaderText = `...`;
const FooterText = `...`;
window.MyAnythingListConfig contains real startup/runtime values and URL-mirrored values.The runtime state model includes both startup defaults and current UI state.
GRIDQR_X, QR_Y, QR_SIZEShowQR, ShowTypes, ShowURLsShowHeaderText, ShowFooterTextShowControls, ShowGear, AutoHideGearOutput_Resolution, Download_FormatGET variables may mirror supported startup values, but branding/template content should remain outside exported state objects where appropriate.
The parsing system has multiple layers:
#.#_.The architecture is deliberately more flexible than a line-oriented parser. The parser is a text interpreter, not merely a one-line tokenizer.
The scripting surface is a first-class architectural layer. Commands and functions are not optional wrappers around the UI; they are formal interfaces into the canonical state and rendering model. Commands must mutate or query documented state and then rely on the same canonical render pipeline used by live view and export.
The command interpreter is a second semantic layer on top of comment parsing. It must support contextual augmentation of playlist items and, where needed, standalone non-URL panels.
Commands should remain readable in plain text and must not require hidden binary metadata.
A tile is defined by state, not by incidental browser layout timing. Identical input state must produce identical composition structure and materially identical output. Hidden timing dependencies, asynchronous drift, and manual export-only layer reconstruction violate the architecture.
Each discovered item becomes a tile model with content, presentation, and overlay metadata.
The architecture must support true native-resolution output at the selected target size, including UHD 8K, DCI 8K, vertical 8K variants, and other documented targets. Source bitmaps may be source-limited, but generated elements remain crisp because they are re-rendered at target resolution.
The thumbnail resolver determines what image to show for a tile.
command-defined thumbnail → uploaded thumbnail → platform-derived thumbnail → generic fallback
The QR subsystem is an overlay subsystem, not a background-image subsystem. Startup placement, layer order, readiness gating, export inclusion, and parity with the live tile are architectural requirements.
QR generation is an overlay subsystem.
In image-only panel modes, the QR target may still point to the image URL unless the command semantics explicitly suppress link affordances.
The rendering architecture must not diverge into one path for the browser view and another path for downloaded thumbnail reconstruction. One composition model may have multiple output targets, but not competing composition rules.
canonical state -> canonical composition -> native-resolution renderer -> live output or export outputText-only URL art is an architectural first-class mode. URL text art, pill text, labels, and footer text must be rendered as generated high-resolution content rather than enlarged low-resolution screen captures.
The rendering layer transforms tile models into grid panels.
tile model → tile container → thumbnail or image layer → QR overlay → footer overlays → click / info affordances
The control panel and gear are not separate unrelated features. They are part of a single recoverable control-state architecture.
The playlist editor is an in-browser editing environment for the raw text source.
Export must support a master-fidelity path in which fidelity is prioritized over arbitrary file-size reduction. PNG is the canonical default for that path. Compressed JPEG output may exist as a separate, explicit mode but must not silently replace the master path.
Output generation is a secondary pipeline layered on top of tile rendering.
The documentation system itself is part of the architecture. It must accumulate knowledge over time, preserve prior decisions, and make conversations unnecessary as a dependency. The package is append-only in spirit: existing material remains, new material is integrated logically, and loss of detail is treated as a regression.
The documentation tree is part of the project architecture, not an afterthought.
/_docs/
index-docs.html
/en/
index_en.html
requirements_en.html
architecture_en.html
system_en.html
developer_en.html
vision_en.html
The system is intentionally designed to support static or mostly static deployment.
authoring / mastering environment → generated files → static hosting (Apache, S3, CDN) → public consumption
Build and archive practices must allow an open-source programmer to repeat yesterday’s work today. Current beta artifacts, canonical documents, command surfaces, acceptance criteria, and known gaps must all be present in the package so a new contributor can continue development without private briefing.
Dated build archives may exist under daily build folders and are useful for transparency, testing, and human historical review.
The architecture of MyAnythingList is designed to preserve human-readable text, visual usefulness, static deployability, and future maintainability at the same time. Its strength is not just what it renders, but how understandable the whole pipeline remains.
For binding functional truth, read requirements_en.html. For philosophical
purpose, read vision_en.html.
The viewport fitting system now has three logical modes: Fit Width, Fit Height, and Fit Everything. Safe-area profiles modify the usable viewport rectangle before scale is computed. Digital safe areas are intentionally tiny; Tube TV safe areas are intentionally generous. Fit Everything must use a single uniform scale derived from the usable viewport bounds. The immutable tile layer order remains: thumbnail or URL art, QR, type pill, small URL, optional overlays.
Updated: 2026-03-12 v09
Tile composition remains deterministic. Thumbnail imagery or URL art renders as the texture/background thumbnail layer. The QR code renders only on its dedicated QR layer above thumbnail imagery and below the pill and smaller URL text. The QR payload must use the full valid URL including anchor-comment fragments.
Startup QR placement must be computed from final tile geometry. If geometry is not ready, the QR waits for final placement rather than flashing on an incorrect layer or position. This rule exists to prevent regressions where a later build accidentally loses the startup fix from an earlier build.
URL art should occupy as much readable thumbnail area as possible while staying visually larger than the footer URL text. Exports must preserve the same proportions, positioning, and scaling that appear on-screen.
MyAnythingList is a public educational system intended to help ethical, curious, and globally diverse people learn how information can be structured, inspected, rendered, and shared. The project should favor transparency, inspectability, multilingual access, and source-aware communication over black-box presentation.
Updated: 2026-03-12 v14