6.0 KiB
6.0 KiB
BAUSTEIN CARD STYLE (HTML+CSS, viewable in a browser)
PURPOSE
- Single building block ("Baustein") as a compact card
- Quick lookup of individual concepts
- The card is part of a larger collection of building blocks
- Not for learning, but for recognition
- Exactly 1 building block per card
FORMAT
- HTML with embedded CSS
- Viewable in a browser (no PDF output)
- Card centered on a light gray background
- Max-width 1000px, padding 28px 36px
- Border-radius 12px, subtle shadow
- Page background #f0f0f5
STRUCTURE — STRICTLY ONLY THESE 4 ELEMENTS
1. Title (h1, bold, no label, no logo)
2. Description (one concise sentence)
3. Purpose (italic, gray, one concise sentence)
4. Code example (the single most relevant one, with a mini label on top)
NO logo, NO "Baustein" label, NO language tag, NO section headings
("Beschreibung", "Zweck", "Relevante Beispiele"), NO info blocks,
NO warn/tip/note boxes, NO meta information, NO divider lines between
sections.
TYPOGRAPHY
- Body: -apple-system, "Segoe UI", sans-serif, 14px, line-height 1.5
- Title h1: 28px, font-weight 800, letter-spacing -0.5px, line-height 1.1
- Description: 14px, line-height 1.55
- Purpose: 14px, italic, color #5a6470
- Code: "SF Mono", Consolas, monospace, 12px, line-height 1.5
- Code label: 10px, letter-spacing 1px
COLORS
- Card background: #ffffff
- Page background: #f0f0f5
- Text: #1a1a1a
- Muted (purpose): #5a6470
- Code background: #1e2a3a
- Code text: #e6e6e6
- Syntax highlighting:
- Keywords (.k): #ff79c6 (pink)
- Variables (.v): #ffb86c (orange)
- Strings (.s): #f1c40f (yellow)
- Functions (.f): #50fa7b (green)
- Types (.t): #8be9fd (cyan)
- Comments (.c): #6b8aae italic
- Label color in code: #8be9fd (cyan)
CONTENT PRINCIPLES
- Title: the MOST COMMON short term, max 1-2 words, no prefix, no variant
- Good: "Header", "Variable", "Klasse", "for-Schleife"
- Bad: "Überschriften h1–h6", "Variablen-Deklaration mit Typ"
- Description: WHAT does it do mechanically? 1 sentence, max 5 words,
abstract/technical
- Good: "Definiert eine Überschrift.", "Wiederholt einen Code-Block."
- Bad: "Sechs Ebenen von der wichtigsten bis zur untergeordneten Überschrift."
- Purpose: WHEN do I need this? 1 sentence, max 5 words,
situational/problem trigger
- Good: "Strukturiert die Seiteninhalte.", "Liste oder Bereich durchgehen."
- Bad: "Gliedert Inhalt in Hierarchie für Leser, SEO und Screenreader-Navigation."
- IMPORTANT: description and purpose must NOT overlap in content
- Bad (tautological): description "Wiederholt Code." / purpose "Etwas mehrfach tun."
- Good (distinct): description "Wiederholt einen Code-Block." / purpose "Liste oder Bereich durchgehen."
- Both sentences: cut every superfluous word, no enumerations, no comma lists
- Exactly ONE code example: the most relevant / most common / most typical
- The example shows the standard use case, not edge cases
- Label above the example: max 2-3 words, simple, descriptive
- Good: "Alle Header", "Zuweisung", "Grund-Regel"
- Bad: "Alle Ebenen h1–h6", "Variable mit Typ-Hint deklarieren"
LAYOUT DETAILS
- Header and body are not separate sections, everything in one card
- Title first, directly below it the description, below that the purpose
(with margin-bottom)
- Margin-bottom title: 14px
- Margin-bottom description: 6px (close to the purpose)
- Margin-bottom purpose: 22px (distance to the code)
- Code block padding: 14px 16px, border-radius 8px
CODE EXAMPLE
- EXACTLY ONE example per card
- The most relevant, most typical, most common one — not edge cases
- Very short: ideally 3-6 lines, max 8 lines
- With a short label on top (2-4 words)
- Syntax highlighting via span classes (.k, .v, .s, etc.)
HTML ENTITIES IN CODE (MANDATORY for HTML/XML/JSX/Vue/JSX-like code)
- If the code example ITSELF shows HTML, XML, JSX, or similar tag syntax,
angle brackets MUST be written as HTML entities:
- `<` → `<`
- `>` → `>`
- `&` → `&`
- Reason: the code is rendered via v-html in the browser. Raw `<h1>` would
otherwise be interpreted as a real DOM element and disappear.
- Good: `<span class="t"><h1></span>Text<span class="t"></h1></span>`
- Bad: `<span class="t"><h1></span>Text<span class="t"></h1></span>`
- Bad: `<h1>Text</h1>` (entirely without spans and without entities)
- This rule applies ONLY to the contents of the code example, NOT to the
`<span class="...">` wrappers themselves
CONCRETE EXAMPLE — building block "Header" (HTML)
```json
{
"title": "Header",
"description": "Definiert eine Überschrift.",
"purpose": "Strukturiert die Seiteninhalte.",
"examples": [
{
"label": "Alle Header",
"code": "<span class=\"t\"><h1></span>Hauptüberschrift<span class=\"t\"></h1></span>\n<span class=\"t\"><h2></span>Kapitel<span class=\"t\"></h2></span>\n<span class=\"t\"><h3></span>Unterabschnitt<span class=\"t\"></h3></span>"
}
]
}
AVOID
- Long explanatory texts
- Multiple sentences for description or purpose
- Performance tips, trade-offs, edge cases
- Related building blocks, variants, anti-patterns
- Tables, lists, enumerations
- Icons, emojis, symbols
- Complex code examples (over 8 lines)
- Multiple examples (variants, alternatives)
TOPIC-SPECIFIC ADJUSTMENTS
- For other languages: adapt syntax highlighting classes
- Title size and spacing stay the same
- Card layout stays the same
- Content (description, purpose, example) is language-specific
GENERATION WITH FEEDBACK LOOP
- Write the HTML
- View in a browser (Playwright screenshot or directly)
- Check:
- Really only 4 elements (title, description, purpose, example)?
- Description and purpose each max 5 words?
- Title max 1-2 words, common short term?
- Label max 2-3 words, simple?
- Code example under 8 lines?
- Label above the code block short and to the point?
- Card compact, no empty space?
- Is the chosen example really the most typical one?
- For HTML/XML/JSX code: all
<and>written as<and>?
- If something is too much: remove it, don't add
- On every iteration check: can anything else be removed?