<object onclick> und Firefox

[j.j.]

Hallo!

Weil <object data=bild.jpg> eigentlich das bessere <img src=bild.jpg> ist (seit die Screenreader ihre Probleme damit behoben haben), habe ich eine Seite reibungslos umgestellt.

... bis ich festgestellt habe, daß HTMLObjectElement.onload in noch nicht so alten Firefoxen nichts tut.

• Funktioniert im aktuellen Fx 139
• Funktioniert nicht mindestens in Fx 127

Zwei Fragen:

1. Weiß jemand seit welcher Version oder hat jemand eine aktuellen Link zum Thema?
2. Gibt es eine Feature-Detektion für <object data=bild.jpg onclick=foo>? (die Stackoverflow-Frage von 2021 ist ohne Nährwert)

Einen blutigen Hack hätte ich dann schon für „ältere“ Firefox ... (immerhin gibts ja noch Sicherheitsupdates für Fx 115)

[j.j.]

Touch-Events sind auch betroffen, und auch Chromium bis 118(?) spielt nicht mit.

Safari (zumindest 13-15) nicht. Also brauch ich Feature-Detektion, nach Browserversion selektieren wird nix.

[Robert B.]

Moin,

Weil <object data=bild.jpg> eigentlich das bessere <img src=bild.jpg> ist (seit die Screenreader ihre Probleme damit behoben haben), habe ich eine Seite reibungslos umgestellt.

Und warum soll das so sein?

... bis ich festgestellt habe, daß HTMLObjectElement.onload in noch nicht so alten Firefoxen nichts tut.

• Funktioniert im aktuellen Fx 139
• Funktioniert nicht mindestens in Fx 127

Funktioniert auch nicht das Hinzufügen eines Eventlisteners?

Viele Grüße
Robert

[Rolf B]

Hallo Robert,

Und warum soll das so sein?

Da bin ich mir auch nicht ganz so klar - object hat Vorteile beim Einbinden von SVGs in Safari, weil dann der Darkmode im SVG erkennbar ist. Aber man fängt sich auch eine Menge Ärger ein, z.B. kann ich bei einem img width und height angeben, im CSS die Breite ändern und er skaliert das Bild entsprechend. Bei einem object ändert sich nur die Breite, die Höhe wird nicht geändert. Und die SVGs müssen beide color-schemes unterstützen, andernfalls erzeugt der Browser einen schwarzen oder weißen "Schutzhintergrund" für das object, um die Erkennbarkeit sicherzustellen.

Im Gegensatz zum img Element hat ein object auch keine loaded-Eigensc

Hinzufügen eines Eventlisteners?

Ob onload oder addEventListener - wenn load gefeuert wird, sollten es beide mitbekommen. addEventListener könnte aus Timinggründen zu spät kommen, um das load-Event zu bedienen. Ist das Bild geladen, bevor addEventListener ausgeführt wird, erhält man das load-Event nicht.

Das ist wieder ein Nachteil von object. Das img Element hat eine complete Eigenschaft. Wenn ich den load-Handler mit addEventListener registrieren will, kann ich bei img vorher abfragen, ob es überhaupt noch ein load Event geben wird. Bei object geht das nicht; wenn die Gefahr besteht, dass ein addEventListener Event zu spät registriert wird, bin ich eigentlich gezwungen, im HTML onload zu markieren. Besteht die Gefahr? Ich denke schon - wenn ich ein großes HTML Dokument habe und das Bild im Cache ist, kann ich mir vorstellen, dass es bereits während des DOM-Aufbaus verfügbar ist. Oder gibt's eine Spec, die besagt, dass load-Events nicht vor DOMContentLoaded gefeuert werden dürfen?

Rolf

[j.j.]

Oder gibt's eine Spec, die besagt, dass load-Events nicht vor DOMContentLoaded gefeuert werden dürfen?

Rolf

Hallo! Es hat sicher nichts mit DOMContentLoaded zu tun, selbst die kleinste Testseite scheitert.

Nachdem ich festgestellt habe, daß sowohl Firefox als auch Chromium ihr Verhalten relativ zeitnah mit den Screenreadern verändert haben, vermute ich eher ein kollektives Aufraffen, die Spec zu befolgen oder eine Änderung Derselben.

[j.j.]

Moin,

Weil <object data=bild.jpg> eigentlich das bessere <img src=bild.jpg> ist (seit die Screenreader ihre Probleme damit behoben haben), habe ich eine Seite reibungslos umgestellt.

Und warum soll das so sein?

Was von Beidem? Zu Ersterm, vergleiche:

<object width=708 height=500 data=bild.jpg>
  <dl>
    <dt><cite>Winterliche Pegnitz bei Schwaig</cite>
    <dd>Bleistiftzeichnung
    <dd>14,8 × 21 cm (mit Rahmen 24 × 30 cm)
  </dl>
</object>

mit

<img width=708 height=500 src=bild.jpg
  alt="Winterliche Pegnitz bei Schwaig - Bleistiftzeichnung - 14,8 × 21 cm (mit Rahmen 24 × 30 cm)"
  title="Winterliche Pegnitz bei Schwaig">

Die Screenreader sind nur ein Nebenaspekt, da bin ich maximal halbwissend. Die üblichen Verdächtigen (JAWS, NVDA, VoiceOver) haben wohl ab ca. 2023 begonnen, den alterativen Inhalt von <object> vorzulesen (vorher ignoriert).

EDIT: Insofern ist <object> auch der bessere <iframe>

[j.j.]

Funktioniert auch nicht das Hinzufügen eines Eventlisteners?

Hallo Robert,

nein, auch nicht.

Was interessanterweise funktioniert, ist ein generierter Klick wie object.click();, aber kein Mausklick.

[Rolf B]

Hallo j.j.,

Was interessanterweise funktioniert, ist ein generierter Klick wie object.click();, aber kein Mausklick.

Was unter anderem daran liegt, dass Bilder keine interaktiven Elemente sind und daher nie auf click reagieren sollten. Wenn interaktiv, dann <button> oder <a> drumherum. Oder meinetwegen auch <summary>…

Aber bei Object funktioniert das nicht. Das object-Element kann Bilder enthalten, aber auch "navigierbaren Inhalt", wie z.B. ein PDF. Es ist dann Sache des navigierbaren Inhalts, auf Mausklicks zu reagieren. Deshalb schickt das object-Element den Klick - mutmaße ich - an das Shadow DOM seines Inhalts, wo er dann verbleibt.

Das ist dann wohl der Todesstoß für unsere Idee, die SVGs im Wiki mittels object einzubinden. Die meisten Bilder sind Links, entweder zur Datei-Seite oder es sind Icons (Card-Logos). Ich müsste also ein a-Element über das Bild stapeln, statt das Bild als Inhalt des a-Elements zu nutzen, um noch Links damit realisieren zu können. Das ist nun wirklich von hinten durch die Brust ins Auge… 😠

Rolf

[j.j.]

Aber bei Object funktioniert das nicht. Das object-Element kann Bilder

Hallo Rolf,

mit meinen Grafiken funktioniert object.onclick heute in allen Browsern. Hast Du das mit SVG kürzlich mal getested? Vielleicht hat sich auch das geändert.

Meine Fragen beziehen sich auf etwas ältere Firefox.

Übrigens, es funktioniert mit Chrome 109!

Meine Tests von gestern ware Müll.

[Rolf B]

Hallo j.j.,

ja gut, bei einem PNG funktionieren onclick und addEventListener("click") beide. Aber ein SVG ist ein navigable document mit eigenem DOM, und deshalb landet das click-Event in einem Script innerhalb des SVG und ist außerhalb nicht verfügbar.

Im Gegensatz zu img wird ein Script in einem SVG nämlich ausgeführt, wenn man es mit object einbindet.

Alles Gründe, sowas im Wiki nicht zu tun. Und Gründe, warum es für img und object eine Existenzberechtigung gibt.

Rolf

[klawischnigg]

Hi there,

Weil <object data=bild.jpg> eigentlich das bessere <img src=bild.jpg> ist (seit die Screenreader ihre Probleme damit behoben haben),[...]

Hm, warum sollte das Einbinden eines Objektes, in dem Fall eines Bildes, ausgerechnet nicht mit dem für es eigentlich konzipierten Element gemacht werden?

[...]habe ich eine Seite reibungslos umgestellt.

ich hoffe für Dich, daß Du dafür immerhin angemessen bezahlt wurdest...(damit das wenigstens irgendeinen Sinn ergibt)

[j.j.]

Hi there,

Weil <object data=bild.jpg> eigentlich das bessere <img src=bild.jpg> ist (seit die Screenreader ihre Probleme damit behoben haben),[...]

Hm, warum sollte das Einbinden eines Objektes, in dem Fall eines Bildes, ausgerechnet nicht mit dem für es eigentlich konzipierten Element gemacht werden?

Hallo, viele Wege führen nach Rom - Weil es im vorliegenden Fall das Script verinfacht, der alterative Inhalt wird per DOM-Manipulation recycled.

Die neue Seite ist noch nicht live. Mglw. endet es mit figure - figcaption - img (dann wärest Du sicher zufriedener 😀

[Der Martin]

Hallo,

Mglw. endet es mit figure - figcaption - img (dann wärest Du sicher zufriedener 😀

zumindest würdest du dann Elemente ihrem eigentlichen Zweck entsprechend verwenden. Kein schlechtes Ziel!

Einen schönen Tag noch
 Martin

[klawischnigg]

Hi there,

Weil <object data=bild.jpg> eigentlich das bessere <img src=bild.jpg> ist (seit die Screenreader ihre Probleme damit behoben haben),[...]

Hm, warum sollte das Einbinden eines Objektes, in dem Fall eines Bildes, ausgerechnet nicht mit dem für es eigentlich konzipierten Element gemacht werden?

Hallo, viele Wege führen nach Rom - Weil es im vorliegenden Fall das Script verinfacht, der alterative Inhalt wird per DOM-Manipulation recycled.

Ok, ich hoff, jetzt geh' ich Dir nicht auf die Nerven, wenn ich frage, was man am object-Element besser oder anders manipulieren kann als am img-Element.

Die neue Seite ist noch nicht live. Mglw. endet es mit figure - figcaption - img (dann wärest Du sicher zufriedener 😀

Meine Zufriedenheit muß Dich nicht kümmern, mich interessieren einfach Deine Beweggründe. Vielleicht gibts ja einen Grund, von dem ich auch profitieren könnte...😉

[j.j.]

Ok, ich hoff, jetzt geh' ich Dir nicht auf die Nerven, wenn ich frage, was man am object-Element besser oder anders manipulieren kann als am img-Element.

Lies mal meine erste Antwort an Rolf B. <dl> samt Inhalt kann ich unverändert klonen und weiterverarbeiten. Anderenfalls muß ich den String aus <img alt> mit RegExp verwursten, was derzeit der Fall ist und mir persönlich nicht gefällt (und meine Zufriedenheit muß mich dann schon kümmern 😀)

[Felix Riesterer]

Liebe(r) j.j.,

<dl> samt Inhalt kann ich unverändert klonen und weiterverarbeiten. Anderenfalls muß ich den String aus <img alt> mit RegExp verwursten,

der erste Satz klingt nach myDlNode.clone(true), der zweite nach myImgNode.alt.replace(/was/, "warum"). Ist das so gemeint?

was derzeit der Fall ist und mir persönlich nicht gefällt

Was ist denn der Use-Case? Was genau versuchst Du zu erreichen, wofür Du diese Wege gewählt hast? Vielleicht gibt es da einen besseren Weg?

Liebe Grüße

Felix Riesterer

[j.j.]

Hallo Felix!

der erste Satz klingt nach myDlNode.clone(true), der zweite nach myImgNode.alt.replace(/was/, "warum"). Ist das so gemeint?

ja, wobei ich erstmal undogmatischerweise myObject.innerHTML verwendet habe.

Was genau versuchst Du zu erreichen, wofür Du diese Wege gewählt hast? Vielleicht gibt es da einen besseren Weg?

Auf der Seite werden Bilder dargestellt, die bestimmte Eigenschaften haben (Titel, Technik, Größe). Wenn der Besucher ein Bild ausgewählt hat (z.B. darauf klickt), werden diese Eigenschaften in einer Box angezeigt.

Das Ganze ist so gestaltet, daß der Seiteninhaber ein Bild dadurch hinzufügen kann, indem er selber den HTML-Code ändert und ein <img> (bzw. <object>) reinschreibt, welches auch gleich alle Eigenschaften des Bildes enthält. Diesen Weg hab ich gewählt, um den Mann nicht zu überfordern und alles "self-contained" (wie sagt man da auf Deutsch?) zu halten.

(ursprünglich sollte das mit CSS position :absolute; oder so gelöst werden, kommt vielleicht noch)

j.j.

[Felix Riesterer]

Liebe(r) j.j.,

Wenn der Besucher ein Bild ausgewählt hat (z.B. darauf klickt), werden diese Eigenschaften in einer Box angezeigt.

Das klingt für mich nach einem klaren Fall von besser mit nativem HTML als JavaScript. Es bietet sich das <details>-Element an.

Das Ganze ist so gestaltet, daß der Seiteninhaber ein Bild dadurch hinzufügen kann, indem er selber den HTML-Code ändert und ein <img> (bzw. <object>) reinschreibt, welches auch gleich alle Eigenschaften des Bildes enthält. Diesen Weg hab ich gewählt, um den Mann nicht zu überfordern und alles "self-contained" (wie sagt man da auf Deutsch?) zu halten.

Das klingt ziemlich hemdsärmelig. Hantiert er da mit FTP? Gut erscheint mir das nicht zu sein...

Liebe Grüße

Felix Riesterer

[j.j.]

Das klingt ziemlich hemdsärmelig. Hantiert er da mit FTP? Gut erscheint mir das nicht zu sein...

Liebe Grüße

Felix Riesterer

Hallo,

das funktioniert seit über zwei Jahren problemfrei mit FTP (der Mensch ist Mediengestalter und generiert auch die Bilddateien selber).

j.j.

[Felix Riesterer]

Liebe(r) j.j.,

im Idealfall hat Dein User eine Login-Maske und dahinter eine Art Bilderverwaltung. Dort kann er dann Bilddateien hochladen und dazu weitere Angaben speichern, die dann von einem Script entsprechend verwaltet werden.

Auf der Besucherseite braucht es dann auch kein JavaScript mehr.

Liebe Grüße

Felix Riesterer

[j.j.]

Hallo Felix!

im Idealfall hat Dein User eine Login-Maske und dahinter eine Art Bilderverwaltung.

Schlechte Homepagebaukästen haben wie schon genug 😀 Es ist halt ein sehr individulles Projekt, das so aus einem ersten Entwurf entstanden und geblieben ist, weil es sich bewährt hat.

Auf der Besucherseite braucht es dann auch kein JavaScript mehr.

Ich weiß nicht, ob ich das richtig verstanden habe, JS braucht es aus vielen Gründen. Kannst Dir ja mal ansehen, es geht um Peter Hindelang (absichtlich nicht verlinkt).

Durch Aufblasen des HTML-Codes könnte man mglw. die Beschriftung der Box mit CSS position lösen:

<figure style=margin:0>
   <figcaption hidden><dl>...</dl></figcaption>
   <img>
 </figure>

Wenns mir mal langweilig wird ...

j.j.

[Auge]

Hallo

Auf der Besucherseite braucht es dann auch kein JavaScript mehr.

Ich weiß nicht, ob ich das richtig verstanden habe, JS braucht es aus vielen Gründen.

Ja, natürlich. Aber vermutlich nicht dafür.

Durch Aufblasen des HTML-Codes könnte man mglw. die Beschriftung der Box mit CSS position lösen:

     <figure style=margin:0>
       <figcaption hidden><dl>...</dl></figcaption>
       <img>
     </figure>

Naja, ob du nun die Beschreibung im HTML-Quelltext unterbringst oder im per <object> eingebundenen SVG-Dokument, irgendetwas „blähst“ du auf. Ich würde eine Lösung mit <figure>, wie du sie oben skizziert hast, präferieren.

Tschö, Auge

[Gunnar Bittersmann]

@@klawischnigg

Ok, ich hoff, jetzt geh' ich Dir nicht auf die Nerven, wenn ich frage, was man am object-Element besser oder anders manipulieren kann als am img-Element.

Bei object besser: Alternativtext im Elementinhalt, nicht als Attributwert. D.h. object-Alternativtext kann auch Mark-up enthalten.

Bei img besser: mit srcset kann man Bilder in verschiedenen Auflösungen anbieten. Je nach gerendererter Größe wird das passende geladen. Mit picture außenrum sind auch verschiedene Bildausschnitte und Seitenverhältnisse machbar.

And the winner is: img.

🖖 Live long and prosper

[j.j.]

And the winner is: img.

Circumstances Alter Cases