component
TuxQACollection
TuxAccordion kind="faq" which is collapsible for scanning. Use this for explainers, methodology sections, and "frequently considered questions" where the answer is the reason to render the item. canonical
Default · technical Q&A
How does the agent watcher detect file moves vs. delete-and-create?
On POSIX it uses inode tracking — a `move` event preserves the inode and the watcher correlates the rename atomically. On Windows, where ReadDirectoryChangesW doesn't surface inodes, the watcher computes a fast SHA-256 hash on rename to correlate. Both paths emit a single `move` event upstream rather than a delete+create pair.
Why was the squarified treemap implemented natively instead of using ECharts?
ECharts would have been a 1.5MB dependency for one chart. The squarified algorithm (Bruls, Huijsen, van Wijk · 1999) is ~80 lines of self-contained code — same visual quality, zero new dependencies. We do reach for ECharts when the chart needs are richer (sankey, sunburst, geographic), but for size-keyed treemaps the lift wasn't justified.
See alsoTuxTreemap source
Are container queries safe to use given the consumer base?
Yes. Tux's three downstream consumers (Landscape, tti-ai-studio, marcom WordPress) all target current Chrome / Edge / Firefox / Safari. Container queries shipped in Chrome 105 (2022-09), Safari 16 (2022-09), Firefox 110 (2023-02) — all evergreen. We have no user agents predating that.
See alsoADR 0007
<TuxQACollection :items="items" />style variants
Per-variant Q. marker + question face
Default = Oswald Q. + Work Sans question. Bold = Work Sans bold-italic Q. Elegant = Georgia italic both — for research publications and policy explainers where the rest of the page is also Georgia.
How does the agent watcher detect file moves vs. delete-and-create?
On POSIX it uses inode tracking — a `move` event preserves the inode and the watcher correlates the rename atomically. On Windows, where ReadDirectoryChangesW doesn't surface inodes, the watcher computes a fast SHA-256 hash on rename to correlate. Both paths emit a single `move` event upstream rather than a delete+create pair.
Why was the squarified treemap implemented natively instead of using ECharts?
ECharts would have been a 1.5MB dependency for one chart. The squarified algorithm (Bruls, Huijsen, van Wijk · 1999) is ~80 lines of self-contained code — same visual quality, zero new dependencies. We do reach for ECharts when the chart needs are richer (sankey, sunburst, geographic), but for size-keyed treemaps the lift wasn't justified.
See alsoTuxTreemap source
slot composition
Rich answer content
Each item exposes an #answer-{idx} slot for richer content than a plain string — lists, code, embedded components.
What does the four-family typography rule actually enforce?
Four font families, one job each:
--font-body— Open Sans for body, eyebrows, H4+--font-display— Oswald for default-style H1–H3 only--font-bold— Work Sans for bold-style H1–H3 + all buttons + inputs--font-elegant— Georgia for elegant-style H1–H3 only
Plus
--font-mono(JetBrains Mono) for paths and code. The rigidity is the point — using a face outside its lane is the signal that the surface is off-system.
props
Props + item shape
items— array of{ question, answer?, seeAlso? }. Required.seeAlso— array of{ label, to?, href? }rendered as a "See also" line under the answer.variant—"default" | "bold" | "elegant". Affects Q. marker and question face.#answer-{idx}slot — replace plainanswerstring with rich content.