DogFatherGitandClaude Opus 5
8e4e525861
`pruef-browser` stand seit dem 28.09. rot, und zwar NUR in WebKit
(Safari): „element is not stable" beim Klick auf den Anmeldeknopf, 53
Versuche ueber 30 Sekunden. Chromium und Firefox waren gruen.
Nachgemessen wanderte sein Kasten pro Bild um ein Fuenftel Pixel:
746.12,575.12 -> 745.10,575.60 (sechs Bilder)
Zwei Bewegungen liefen dabei -- `.buehne__bild` und `.knopf__laden`.
Beide sind echte Befunde.
=====================================================================
1. DER KREISEL DREHT SICH FUER IMMER, UNSICHTBAR
=====================================================================
.knopf__laden { opacity: 0; animation: dreh .8s linear infinite; }
.knopf[disabled] .knopf__laden { opacity: 1; }
Nur die Deckkraft schaltete um. Die Drehung lief ab dem Laden der
Seite, auf JEDEM Knopf, fuer immer -- nicht zu sehen und trotzdem
jedes Bild neu gerechnet. Auf einer Seite, auf der man einen Code
eintippt, ist das reine Verschwendung.
Und sie kannte die Hausregel nicht: Wer weniger Bewegung eingestellt
hat, bekam sie trotzdem. Jetzt dreht sie nur, wenn der Knopf
wirklich arbeitet -- und bei `prefers-reduced-motion` steht der Ring
still, statt zu verschwinden: Ein unsichtbarer Kreisel sagt gar
nichts, ein stehender sagt „ich arbeite noch".
=====================================================================
2. DIE KARTE BEWEGTE SICH, WENN MAN NACH IHR GRIFF
=====================================================================
Die Parallaxe folgte dem Zeiger AUCH ueber der Anmeldekarte. Wer die
Maus zum Codefeld fuehrt, bewegte damit das Feld. Bei zehn Pixeln
keine Katastrophe -- aber genau verkehrt herum: Was man bedienen
will, soll stillstehen.
Und es war der Grund fuer den Wettlauf: Der Zeiger bewegte das Ziel,
das er treffen wollte. Ein Wettlauf zwischen Maus und Karte ist auch
fuer einen Menschen keiner, den er gewinnen soll.
Ueber der Karte wird das Ziel nicht mehr nachgefuehrt. Die
Annaeherung laeuft aus und haelt an; verlaesst man die Karte, geht es
weiter. Das Bild lebt, die Bedienung steht.
=====================================================================
WARUM ES NUR WEBKIT GEZEIGT HAT
=====================================================================
Chromium liefert fuer eine zusammengesetzte Verwandlung oft den
Layout-Kasten OHNE die laufende Bewegung -- dort sah der Knopf ruhig
aus, obwohl er es nicht war. WebKit sagt die Wahrheit. Eine Maschine,
die frueher „gruen" meldet, hat nicht recht; sie sieht nur weniger.
Nachher: pruef-browser 17/0 (war 14/1), alle vier Maschinen.
Dazu gruen: crew-adresse 169/0, crew-wand-bild 45/0, kachelfarben
31/0, css-klassen 37/0, struktur 44/0, tippziele 13/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
70 lines
3.0 KiB
HTML
70 lines
3.0 KiB
HTML
<!doctype html>
|
||
<html lang="de">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
<title>Bühne – das laufende Video</title>
|
||
<!-- ======================================================================
|
||
DAS LAUFENDE VIDEO ALS BROWSER-QUELLE (28.09.2026)
|
||
|
||
Zeigt das Video, das gerade in der Reaction läuft — auf dieselbe
|
||
Sekunde wie bei allen anderen. Sonst nichts: kein Chat, keine
|
||
Kameras, keine Bedienung, kein Rand.
|
||
|
||
WARUM DIE EIGENE KAMERA HIER NICHT DRIN IST: Sie ist in OBS
|
||
direkt als Gerät verfügbar, in besserer Qualität und frei in
|
||
Größe und Lage. Den Umweg über den Browser zu nehmen hieße,
|
||
Qualität gegen nichts einzutauschen — und die Größe wäre dann
|
||
festgelegt statt frei.
|
||
|
||
Sind GÄSTE im Bild, kommen deren Kameras über eine
|
||
Direktverbindung an, und die braucht eine angemeldete Seite.
|
||
Dafür gibt es den Bühnenmodus der Reaction-Seite
|
||
(`reaktion.html?nur=buehne`), der als Fenster aufgenommen wird.
|
||
|
||
In OBS: Quelle → Browser → diese Adresse, 1920 × 1080,
|
||
„Steuerung anzeigen" aus.
|
||
====================================================================== -->
|
||
<style>
|
||
html, body {
|
||
margin: 0; padding: 0;
|
||
background: #000;
|
||
height: 100%; overflow: hidden;
|
||
font-family: "Segoe UI", system-ui, -apple-system, sans-serif;
|
||
}
|
||
#platz { position: fixed; inset: 0; }
|
||
#platz iframe { width: 100%; height: 100%; border: 0; display: block; }
|
||
|
||
/* ==== BEI „NUR KAMERA" GEHT DAS BILD AUS ========================
|
||
Sonst läge im Stream ein stehengebliebenes YouTube-Bild unter
|
||
den Kameras — und Filipe sähe es nicht, weil er in OBS auf
|
||
seine Szene schaut und nicht auf die Quelle.
|
||
|
||
`visibility` UND NICHT `display`. Ein Spieler, den man aus dem
|
||
Seitenaufbau nimmt, hört auf zu dekodieren; beim Zurückschalten
|
||
müsste er erst wieder an die richtige Stelle springen, und das
|
||
sehen dann alle. So läuft er weiter, nur eben unsichtbar, und
|
||
ist in derselben Sekunde wieder da. */
|
||
body[data-bild="aus"] #platz { visibility: hidden; }
|
||
|
||
/* Was zu sehen ist, wenn gerade nichts läuft. Schwarz und still --
|
||
eine Beschriftung stünde im Stream. Nur bei einem falschen
|
||
Schlüssel gibt es einen Hinweis, denn den sieht man sonst nie. */
|
||
.obs-fehler {
|
||
position: fixed; left: 16px; top: 16px;
|
||
padding: 10px 14px; border-radius: 10px;
|
||
background: rgba(140, 20, 30, .9); color: #fff; font-size: 14px;
|
||
}
|
||
</style>
|
||
<!-- DIE WERBEEINBLENDUNG. Dieselbe Datei wie in der Reaction-Seite:
|
||
Zwei Fassungen altern unterschiedlich, und dann sieht der Stream
|
||
anders aus als das, worueber geredet wird. -->
|
||
<link rel="stylesheet" href="assets/css/werbung.css?v=202609301127" />
|
||
</head>
|
||
<body class="obs-buehne">
|
||
<div id="platz"></div>
|
||
<script src="assets/js/werbung.js?v=202609301127" defer></script>
|
||
<script src="assets/js/buehne.js?v=202609301127" defer></script>
|
||
</body>
|
||
</html>
|