Markers sichtbar — der eigentliche Shadow-DOM-Fix
Nach mehreren Iterationen ist die echte Ursache identifiziert und behoben. Plus: kleinerer, schmuckerer grüner Pulse-Marker.
Was der Bug war
MapLibre liefert sein Stylesheet mit der zentralen Regel:
.maplibregl-marker { position: absolute; top: 0; left: 0; }Damit transform: translate(x, y) zum Positionieren funktioniert, muss das Marker-Element position: absolute haben. Diese Regel liegt in MapLibres CSS-Datei, die in den <head> geladen wird.
Home Assistant wickelt jede Lovelace-Karte in einen Shadow-DOM-Root. CSS-Regeln aus <head> durchstoßen Shadow-DOM-Grenzen nicht. Die Klasse maplibregl-marker wird zwar auf das Marker-Element gesetzt, aber die zugehörige Regel ist im Shadow-Tree unsichtbar. Alle Marker fielen auf den Default position: static zurück.
Bei static greift transform: translate(x, y) nicht als "Verschiebung vom Container-Ursprung", sondern als "Verschiebung von der DOM-Flow-Position". Folge: alle drei Marker landeten weit unten im DOM-Flow stapelartig übereinander, viewport y ≈ 1322-1345, also unter dem sichtbaren Bereich.
Der grüne Marker hatte das gleiche Problem wie orange und rot, sah aber wegen seiner Größe nie auch nur kurz im Bild auf. Orange und rot blitzten manchmal kurz auf, wenn der jeweilige Transform-Wert sie zufällig in den sichtbaren Bereich verschob, daher die "wild auftauchenden" Punkte.
Der Fix
Auf jedem Marker-Element explizit position: absolute; top: 0; left: 0; setzen. Diese Styles leben entweder im Card-internen <style>-Block (für die CSS-Klasse) oder direkt als Inline-Style — beides ist Teil des Shadow-Trees und greift unabhängig vom umliegenden CSS.
Angewendet auf:
- Die CSS-Klasse
.ebike-3d-markerfür den grünen pulsierenden Marker - Das Inline-Style-Fallback des grünen Markers
- Das Inline-Style der orange-/roten Punkt-Marker in
_addPointMarker
Bonus: kompakterer Pulse-Marker
Auf User-Wunsch:
- Marker-Durchmesser: 36 → 18 px
- Pulse-Ring Inset: −14 → −8 px
- Weißer Rand: 5 px (unverändert)
- Pulse-Ring Rand: 5 px (unverändert)
- Halo-Shadow Spread: 4 → 6 px (etwas größer)
- Drop-Shadow Blur: 14 → 18 px (etwas größer)
- Drop-Shadow Opacity: 0.6 → 0.65
Net: kompakter Kern-Dot mit prominentem grünem Halo plus warmer Schlagschatten. Bike bleibt gut sichtbar, ohne die Karte zu dominieren.
Sorry für die Iterationen
v1.15.0 bis v1.15.9 haben den Bug zwischen Closure-Race-Conditions, fitBounds-Timing, Look-Ahead-Geometrie und Browser-Caching gesucht. Mehrere dieser Fixes waren auch real wertvoll (myMap-Closure-Capture, JSON-Stringify-Dedup gegen Doppel-Init, Shadow-Workaround beim Video-Export für Safari). Die eigentliche Marker-Ursache war aber eine triviale CSS-Eigenschaft, die im Shadow-DOM nicht ankam.
Dein letztes Konsolen-Output mit der Zeile pos=static für alle drei Marker war der Schlüssel. Sobald pos= nicht absolute ist, kann MapLibres Transform-Pattern nicht funktionieren.
Nach dem Update
HACS-Update auf 1.15.10, HA-Neustart, Browser-Hard-Reload. Tour öffnen.
Erwartet:
- Grüner pulsierender Marker sichtbar an der Bike-Position, im unteren Drittel des Karten-Canvas (oder zentriert bei
chase_lookahead: 0) - Oranger Start-Marker am Tour-Anfang (~14 px)
- Roter Ziel-Marker am Tour-Ende
- Beim Slider-Bewegen: grüner Marker wandert mit dem Bike mit
- Bei Play-Wiedergabe: alle drei verhalten sich wie erwartet, kein "wildes Aufblitzen" mehr