Seltsamer Firefox-Bug

[Gunnar Bittersmann]

Ich habe mehrere details-Elemente, deren summarys^[1] inline nebeneinander stehen sollen, deren Inhalte (iframes mit Videos in dem Fall) sich aber an derselben Stelle öffnen sollen.

(Dabei sorgt JavaScript dafür, dass sich beim Öffnen eines details-Elements dessen Geschwister schließen. Aber das tut hier nichts zur Sache, denke ich.)

Funktioniert: Ancestors & ghosts.^[2] Edit: Wie Rolf anmerkte, funktioniert schon dieses Beispiel nicht im Firefox – selbes Problem.

Nun habe ich das aber mit etwas Listen-Markup. Funktioniert auch – in Safari und Chromia.

In Firefox sitzen die iframes der ersten Gruppe (“Long Time Coming”) noch richtig; die der zweiten Gruppe (“Born in the U.S.A.”) werden aber zu hoch platziert.

Manche Versuche (wie bspw. content: '.') wirken temporär; nach Seitenreload aber nicht mehr.

Findet vielleicht jemand einen Workaround?

Kwakoni Yiquan

PS: Die Videos sind ansehenswert.

Die Unterhaltung mit seinem Vater hatte ich aus der Autobiografie auch vorige Woche in meinem Programm „Zum Wegrennen geboren“.

---

1. Mir ist bewusst, dass sich summaries mit ie schreibt. ↩︎

2. “We are ghosts or we are ancestors in our children’s lives.” – Bruce Springsteen, intro to “Long Time Coming” (Springsteen on Broadway) ↩︎

[Robert B.]

Moin Gunnar,

[…] summarys¹ […]

¹ Mir ist bewusst, dass sich summaries mit ie schreibt.

sobald Summary wie ein Hobby zur deutschen Sprache gehört, kannst du mehrere Summarys als Hobbys haben 😜

Ein schönes Wochenende
Robert

[Gunnar Bittersmann]

@@Robert B.

[…] summarys¹ […]

¹ Mir ist bewusst, dass sich summaries mit ie schreibt.

sobald Summary wie ein Hobby zur deutschen Sprache gehört, kannst du mehrere Summarys als Hobbys haben 😜

Das sollten wir auf etlichen Partys gehörig abfeiern.

Kwakoni Yiquan

[MudGuard]

Hi,

¹ Mir ist bewusst, dass sich summaries mit ie schreibt.

sobald Summary wie ein Hobby zur deutschen Sprache gehört, kannst du mehrere Summarys als Hobbys haben 😜

Das sollten wir auf etlichen Partys gehörig abfeiern.

aber nur, wenn keine Babys dabei sind …

cu,
Andreas a/k/a MudGuard

[Tabellenkalk]

Hallo,

¹ Mir ist bewusst, dass sich summaries mit ie schreibt.

sobald Summary wie ein Hobby zur deutschen Sprache gehört, kannst du mehrere Summarys als Hobbys haben 😜

Das sollten wir auf etlichen Partys gehörig abfeiern.

aber nur, wenn keine Babys dabei sind …

Dann sind Derbys wohl eher was für dich…

Gruß
Kalk

[MudGuard]

Hi,

Dann sind Derbys wohl eher was für dich…

ne, Whiskeys 😉 (nein, nicht Whiskys, ich bevorzuge Irish …)

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

¹ Mir ist bewusst, dass sich summaries mit ie schreibt.

sobald Summary wie ein Hobby zur deutschen Sprache gehört, kannst du mehrere Summarys als Hobbys haben 😜

Das sollten wir auf etlichen Partys gehörig abfeiern.

aber nur, wenn keine Babys dabei sind …

Hauptsache, es sind Diskjockeys dabei.

Oh, schlechtes Beispiel.

Kwakoni Yiquan

[MudGuard]

Hi,

Hauptsache, es sind Diskjockeys dabei.

Oh, schlechtes Beispiel.

ey, da war ich 2 Minuten schneller …

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Gunnar Bittersmann

In Firefox sitzen die iframes der ersten Gruppe (“Long Time Coming”) noch richtig; die der zweiten Gruppe (“Born in the U.S.A.”) werden aber zu hoch platziert.

Und das hat nichts mit CodePen zu tun; der Fehler tritt auch auf dieser Testseite auf.

---

PS: Die Videos sind ansehenswert.

Auf Netflix gibt’s Springsteen on Broadway auch mit Bild – und mit Untertiteln.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar Bittersmann,

in meinem Firefox sind die iframes der zweiten Gruppe auch im NWmWNoJ Pen zu hoch. Und zwar nur nach dem ersten Laden. Wenn ich eine kleine, funktionslose Änderung im CSS mache und Codepen die Seite refreshed hat, ist der Fehler weg. Hast Du das Beispiel mal ohne Codepen probiert? Ist es vielleicht ein iframe in iframe Issue?

Der Fox spinnt hier definitiv rum, denn sobald man die Entwicklerwerkzeuge aktiviert, ist der Fehler weg.

Ah, Update: Entwicklerwerkzeuge vor dem Öffnen der details starten, dann kommt der Fehler auch mit ihnen.

Update: Wenn der Fehler auftritt, wird das ::after Element nicht erzeugt. Ist das eine unheilige Kollision von & und :has()?

Update: Nein, ist es nicht.

Rolf

[Rolf B]

Update: es passiert nur im zweiten .has-multiple-details. Wenn ich dessen Klasse auf "has-multiple-details2" umbenenne, die Regel mit :has(details[open]) doppele und darin die Klasse anpasse, dann funktioniert es.

FF kriegt es nicht hin, diese :has Regel auf beide Listen anzuwenden. Sehr merkwürdig.

Deine details sollten übrigens ein name Attribut bekommen, und das JS sollte prüfen, ob das details-Element das name Property kennt. Wenn nicht, kann es als Polyfill für den fehlenden name-Support von FF den toggle-Handler aktivieren. Und dann kannst Du den toggle-Handler auf dem .has-multiple-details Element registrieren und das toggle-Event zu Dir bubbeln lassen. In event.target steht dann das details-Element und in event.currentTarget das Container-Element, das Du derzeit mit .parentNode.parentNode herbeiholst (wobei .closest(".has-multiple-details") sicherlich robuster wäre)

Wenn der FF tatsächlich so strunzdumm ist, das CSS nicht richtig zu interpretieren, könntest Du in diesem Toggle-Handler auch eine Klasse setzen, die bei offenen Details eine Klasse setzt, die das ::after erzeugt. Ich probier's mal aus.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Wenn der FF tatsächlich so strunzdumm ist, das CSS nicht richtig zu interpretieren, könntest Du in diesem Toggle-Handler auch eine Klasse setzen, die bei offenen Details eine Klasse setzt, die das ::after erzeugt. Ich probier's mal aus.

Ja, der Workaround geht.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar Bittersmann,

nicht wirklich. Öffne Intro 1, klicke auf Intro 2 -> Autsch

Toggle ist ein Scheißevent - es feuert auch dann, wenn man den open-Zustand per JS ändert 😟

Rolf

[Rolf B]

Hallo Gunnar,

boah ey, ist der Firefox hier kaputt. Ich wollte das Ganze als Polyfill schreiben, der nur aktiv ist, wenn das name-Attribut nicht wirkt (was natürlich ein Risiko ist, denn man weiß ja nicht, ob der FF diesen ::after-Bug fixt bevor sie das name-Attribut implementieren).

Also habe ich die details-Elemente mit names versehen (natürlich unterschiedliche für die beiden Songs) und dieses Script gesetzt:

    (function polyfillNameDetails() {
      const namedDetails = document.querySelectorAll('details[name]');
      if (namedDetails.length > 0 && namedDetails[0].name) return;

      function toggleNamedDetails(event) {
        let isOpen = event.newState == 'open';
        let selectName = `[name='${CSS.escape(event.target.getAttribute("name"))}']`;
        let detailsContainer = event.target.closest(".has-multiple-details");
        if (isOpen) {
          detailsContainer.classList.add("has-open-details");
          for (let sibling of document.body.querySelectorAll(`details${selectName}`)) {
            if (sibling != event.target) {
              sibling.open = false;
            }
          };
        }
        else if (!document.body.querySelector(`details${selectName}[open]`)) {
          detailsContainer.classList.remove("has-open-details");
        }
      }
      
      for (let detail of namedDetails) {
        detail.addEventListener("toggle", toggleNamedDetails);
      }
    })();

Damit verschwindet die has-open-details Klasse korrekt wieder. Und damit es auch ohne Polyfill geht, habe ich den Selektor für das ::after Element so gebaut:

  &:is(:has(details[open]), .has-open-details)::after {
    ...
  }

Aber nada, das versteht der Fuchs nicht. Chrome schon. Der Fuchs braucht es so:

  &:has(details[open])::after,
  &.has-open-details::after {
    ...
  }

Damit geht es dann bei mir.

Rolf

[Gunnar Bittersmann]

@@Rolf B

boah ey, ist der Firefox hier kaputt. […] Damit geht es dann bei mir.

Ich hatte lange nicht die Muße, mich weiter damit zu beschäftigen. Heute hat mich die Muse geküsst – und:

Manche Dinge kann man auch einfach aussitzen. Ich hab nur das getan, was ich am besten kann: nichts. Und den Firefox neu gestartet, damit das Update installiert wird. Und schon hat sich das Problem von selbst gelöst. 😊

Gleich eingebaut, zu sehen bspw. bei Strange New Worlds.

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Dabei sorgt JavaScript dafür, dass sich beim Öffnen eines details-Elements dessen Geschwister schließen.

Chromia und Safari können das auch schon ohne JavaScript – mit name-Attribut. Anzusehen auf den unteren Decks.

Kwakoni Yiquan

[Matthias Scharwies]

Servus!

@@Gunnar Bittersmann

Dabei sorgt JavaScript dafür, dass sich beim Öffnen eines details-Elements dessen Geschwister schließen.

Chromia und Safari können das auch schon ohne JavaScript – mit name-Attribut. Anzusehen auf den unteren Decks.

Ja, siehe SELF-Blog Silvester-Knaller: Exklusive Akkordeons ohne JavaScript! vom 31.12.2023

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Ja, siehe SELF-Blog Silvester-Knaller: Exklusive Akkordeons ohne JavaScript! vom 31.12.2023

Der Abschnitt „Registerkarten“ ist aber kein Knaller, sondern ein Blindgänger. Die Spec sagt ausdrücklich: “it is not conforming to use the details element when attempting to represent another type of control. For example, tab widgets and menu widgets are not disclosure widgets, so abusing the details element to implement these patterns is incorrect.”

Ich hab das im Blog auch vermerkt.

Kwakoni Yiquan