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 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.
Each discovered item becomes a tile model with content, presentation, and overlay metadata.
The thumbnail resolver determines what image to show for a tile.
command-defined thumbnail → uploaded thumbnail → platform-derived thumbnail → generic fallback
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 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.
Output generation is a secondary pipeline layered on top of tile rendering.
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
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
2026-03-17 Additive Expansion: The original architecture remains authoritative and unchanged above. The following material is appended under a strict preservation rule so future sessions, tools, and contributors never delete or compress previously decided knowledge.
The architecture now explicitly requires a single canonical tile composition model shared by live view, export rendering, scripted rendering, batch rendering, and future headless builds. Export is not permitted to reconstruct the tile using a second interpretation of layout. The same state must yield the same composition order, spacing, geometry, visibility decisions, and final layering regardless of whether the output is on-screen, downloaded, printed, or scripted.
The architecture now forbids screenshot-style export and any "capture what the browser already rasterized" shortcut when that shortcut would lower fidelity. Export must render the canonical model natively at the selected output size. Screen-resolution capture, viewport-bound CSS-pixel export, or flatten-then-upscale workflows are architectural failures because they violate the project's expert-quality expectations for 4K and 8K output.
The system is now explicitly architected for total replicability. Any open-source programmer should be able to repeat yesterday's work today using the documentation package alone. The architecture therefore treats hidden judgment, undocumented heuristics, and one-off author memory as liabilities. Every meaningful behavior must be externalized into the docs.
The documentation system itself is part of the architecture. The package now follows an append-only preservation model: old content remains, and new content is added as additive sections. Rewriting older sections into shorter summaries is a regression because it destroys institutional memory. A future assistant session, contributor, or automated tool is not allowed to "clean up" the docs by compressing them.
The architecture now explicitly recognizes a world-scale educational context. Controls, labels, and user-facing text must be designed for localization from the beginning. Directionality, longer translated strings, and multilingual rendering are not later polish items; they are architectural concerns affecting layout, rendering, scripting keys, acceptance tests, and UI behavior.