Architecture Decision Record · 0038

Card-Frame als rechteckiges Geschwister-SDC zu bubble-card-frame

TL;DR — Das Figma-Set Card/Desktop/Frame wird als eigenständige SDC card-frame implementiert, parallel zu bubble-card-frame (kein Refactor). Vier Border-Varianten × vier Hintergrund-Varianten × optionaler Button-Notch, gerendert über ein einzelnes SVG-Path (Stroke + Fill konditional), Image-Hintergrund über HTML-<img> mit clip-path referenziert auf SVG-<clipPath>.

Kontext

Figma File CHHDfbpX8Ys2LBiGs5HVK0 definiert das Component-Set Card/Desktop/Frame (Node-IDs 61176:47682 ff.) als rechteckige Card mit vier Border-Varianten und unabhängig davon vier Hintergrund-Varianten. Anders als die SOLCOM-Profile-Card (Figma 4.3, profile-2-2, gemodellt von ADR-0005):

Die bubble-card-frame-SDC aus ADR-0005 deckt nur die Profile-Form ab (profile-2-2, 544×581-Geometrie mit fixem 36-px-Outer-Radius und fest 60-px-Step-Down-Notch). Sie ist nicht parametrisierbar auf die Frame-Topologie, weil:

Entscheidung

Neue SDC web/themes/custom/byte_theme/components/card-frame/ mit eigener JS-Library byte_theme/card-frame-notch, parallel zu bubble-card-frame und bubble-card-notch. Kein Refactor.

SDC-Topologie

SVG-Path-Geometrie

Ein einzelnes SVG mit ViewBox 0 0 W H (1:1 zur Article-Box, kein Stretch für Peak/Tail) und preserveAspectRatio="none". ViewBox wird im JS auf die echte Card-Width/Height aktualisiert, Path-d zur Layout-Time per buildPath() neu gebaut (analog ADR-0005). Speaker-Tails bei y = -32 bzw. y = h + 32 rendern via CSS overflow: visible außerhalb der SVG-Display-Box.

VariantePath-Konstruktion
default + buttonRounded-Rect + Notch unten-rechts. Notch-Left-Seite = zwei tangential verbundene Quarter-Arcs (K=0.5523 Cubic-Bezier-Approximation) → „Rundung-an-Rundung"-Optik wie in der Figma-Vorlage.
speaker-topPath startet bei M tx 0 (NICHT M br 0); Top-Left-Corner entfällt. Left-Edge fährt am Pfad-Ende straight durch (0, 0) bis Peak (0, -th); Z schließt die Hypotenuse zurück zur M-Position.
speaker-bottomBottom-Edge endet bei (tx, h), Diagonale zum Peak (0, h+th), dann straight up. Bottom-Left-Corner entfällt.
noneStroke transparent. Path-Geometrie wird trotzdem berechnet — wird vom Hintergrund-Fill als Card-Shape-Container genutzt.

Background-Rendering

JS-Behavior — card-frame-notch.js

Drupal.behaviors.solcomCardFrameNotch.attach registriert pro .card-frame-Instanz zwei ResizeObserver (Card + Pille) plus einen window.resize-Listener. Bei jedem Fire: card.getBoundingClientRect() liefert echte Card-Width/Height (Border-Box, padding-inklusive), buildPath() erzeugt neuen Path-d, svg.querySelectorAll('path') updated alle Path-Elemente (Single-Path-Fall none/glass, Double-Path-Fall farbe, Clip-Path-Fall bild via <clipPath>><path>) mit dem identischen d-String. Geometrie-Konstanten (BR=20, TX=32, TH=32, SD=60, K=0.5523, PILLE_*-Paddings) hardcoded.

Canvas-Component-Config-Wiring

Drupal-Canvas auto-discovered die SDC und schreibt config/sync/canvas.component.sdc.byte_theme.card-frame.yml aus dem Schema. variant und background werden als list_string-Fields gemapped, background_image als entity_reference auf Media-Bundles image + svg_image mit dem media_library_widget. Schema-Hash-Änderung (z. B. neue Prop, Required-Flag) treibt einen neuen active_version-Hash — bestehende Placements bleiben an der alten Version gepinnt, bis sie explizit gebumpt werden.

Rejected alternatives

Consequences