nicht angemeldet Robert B.
klawischnigg
Der Martin
klawischnigg
Felix Riesterer
Felix Riesterer
Felix Riesterer
Auge
Felix Riesterer
Gunnar Bittersmann
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.
Zwei Fragen:
Rolf B
Tabellenkalk<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)
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.
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.onloadin 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
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
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.
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>
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.
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
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.
Meine Tests von gestern ware Müll.
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
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)
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 😀
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
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...😉
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 😀)
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
Hallo Felix!
der erste Satz klingt nach
myDlNode.clone(true), der zweite nachmyImgNode.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.
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
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.
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
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.
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
positionlö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
Durch Aufblasen des HTML-Codes könnte man mglw. die Beschriftung der Box mit CSS
positionlö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
Hallo!
„Aufblasen“ war übertrieben (von <object> bin ich eh wieder weggekommen).
Gemeint war, daß man mit <object> fünf Teile zum Preis von einem bekommt (wenn man ein HTML-Attribut und eine CSS-Erklärung mitzählt):
<object>...</object>
<figure style=margin:0>
<img>
<figcaption hidden>...</figcaption>
</figure>
Schönes Wochenende!
j.j.
Moin,
Gemeint war, daß man mit <object> fünf Teile zum Preis von einem bekommt (wenn man ein HTML-Attribut und eine CSS-Erklärung mitzählt):
<object>...</object> <figure style=margin:0> <img> <figcaption hidden>...</figcaption> </figure>
Das ist allerdings semantisch schon ein großer Unterschied. Was nützen Dir 5 Äpfel zum Preis von einen, wenn Du Birnen möchtest?
Viele Grüße
Robert
Liebe(r) j.j.,
Schlechte Homepagebaukästen haben wie schon genug 😀
was für eine Plattitüde! Anstatt dass Du den tatsächlichen Bedarfsfall vollumfänglich beschreibst, damit man wirklich verstehen kann, womit wir es hier tatsächlich zu tun haben, flüchtest Du Dich in diesen Allgemeinplatz, um Deinen Lösungsweg scheinbar zu rechtfertigen. Dabei weißt Du ganz genau, dass Du an einem Provisorium herumschraubst, anstatt es „gleich richtig“ zu machen.
Es ist halt ein sehr individulles Projekt, das so aus einem ersten Entwurf entstanden und geblieben ist, weil es sich bewährt hat.
Das ist die Definition eines Provisoriums! Also das genaue Gegenteil von gut gemacht. Aber das Web ist voll von solchen halbgaren Ideen. In vielen Fällen ist es den Betroffenen weder das Geld noch die Zeit wert, eine belastbare gute Lösung zu erarbeiten. Und ich kann nicht beurteilen, ob da am falschen Ende gespart wird.
Kannst Dir ja mal ansehen, es geht um Peter Hindelang (absichtlich nicht verlinkt).
Ja, genau so, wie ich mir das gedacht habe:
Dir ist eine Karrussell-Animation der Bilder wichtig. Damit das sinnvoll klappt, braucht es in der Tat JavaScript, weil eine reine CSS-Lösung weniger flexibel gestaltet werden kann. Aber dass da jemand kaputtes HTML ins Dokument pfuscht, ist definitiv der falschestmögliche Ansatz, wie eine solche Seite zu pflegen ist!
Zum Thema Homepage-Baukasten: Dein Schützling (Gott bewahre: Kunde?!) sollte überhaupt keinen Code anfassen dürfen. Stattdessen sollte er Daten pflegen können. Den Rest erstellt eine serverseitige Logik, die für diesen Spezialfall zu erstellen wäre - inklusive passendem JavaScript. Ein Homepage-Baukasten ist dagegen etwas völlig anderes. Einen solchen kann Dein Schützling dafür nicht gebrauchen, da es sich ja um ein „sehr individulles Projekt“ handelt.
Liebe Grüße
Felix Riesterer
Hallo!
Deine Antwort enthält nichts konkretes, nur Deine betonierte Privatmeinung, Konjunktive und mehrere Beleidigungen. Es ist Zeitverschwendung.
Liebe(r) j.j.,
Schlechte Homepagebaukästen haben wie schon genug 😀
was für eine Plattitüde!
Die Humorlosigkeit in diesem Forum ist erstaunlich.
Anstatt dass Du den tatsächlichen Bedarfsfall vollumfänglich beschreibst, damit man wirklich verstehen kann, womit wir es hier tatsächlich zu tun haben, flüchtest Du Dich in diesen Allgemeinplatz, um Deinen Lösungsweg scheinbar zu rechtfertigen. Dabei weißt Du ganz genau, dass Du an einem Provisorium herumschraubst, anstatt es „gleich richtig“ zu machen.
Ich will hier garnichts rechtfertigen, oder bist Du Richter am Strafgericht?
(Ich hatte eingangs zwei konkrete Fragen gestellt, die unbeantwortet bliebe - soweit kein Problem. Und jetzt siehst Du mich in der Pflicht, irgendwas „vollumpfänglich“ zu beschreiben? Sehe ich nicht so)
Es ist halt ein sehr individulles Projekt, das so aus einem ersten Entwurf entstanden und geblieben ist, weil es sich bewährt hat.
Das ist die Definition eines Provisoriums!
So what?
Also das genaue Gegenteil von gut gemacht. Aber das Web ist voll von solchen halbgaren Ideen. In vielen Fällen ist es den Betroffenen weder das Geld noch die Zeit wert, eine belastbare gute Lösung zu erarbeiten. Und ich kann nicht beurteilen, ob da am falschen Ende gespart wird.
Was redest Du da? Die Seite funktioniert einwandfrei, auf jedem denkbaren Gerät auf jedem™ Betriebssystem mit jedem denkbaren fünf Jahre alten Browser. Und das ist kein Zufall.
Ja, genau so, wie ich mir das gedacht habe:
- kaputtes HTML
Deiner Privatmeinung wird von offizieller Seite deutlich widersprochen: validator.nu.
Das HTML ist nicht kaputt, es entpricht lediglich nicht Deinen persönlichen Neigungen und Vorlieben.
- konfuses JavaScript (etwa von ChatGPT erstellt?)
Das ist eine Beleidigung (und läßt bei Dir Ahnungslosigkeit vermuten bezüglich LLMs und meinem Code)
- unzugängliche Bedienerführung
Was ist unzugänglich für wen? (spar Dir die Antwort, ich werde sie nicht mehr lesen)
Dir ist eine Karrussell-Animation der Bilder wichtig. Damit das sinnvoll klappt, braucht es in der Tat JavaScript, weil eine reine CSS-Lösung weniger flexibel gestaltet werden kann. Aber dass da jemand kaputtes HTML ins Dokument pfuscht, ist definitiv der falschestmögliche Ansatz, wie eine solche Seite zu pflegen ist!
Aha, Du weißt was mir wichtig ist. Weiß Du auch die Lottozahlen von nächster Woche?
(Das Karusell funktioniert grundsätzlich rein mit CSS. Falls Dir das nicht aufgefallen ist, ein Tip: man kann JS ausschalten ...)
Zum Thema Homepage-Baukasten: Dein Schützling (Gott bewahre: Kunde?!) sollte überhaupt keinen Code anfassen dürfen.
Der Kunde will den Code anfassen. (Du bist allgemein recht meinungsstark bei Sachverhalten, die Du nicht kennst)
Stattdessen sollte er Daten pflegen können. Den Rest erstellt eine serverseitige Logik, die für diesen Spezialfall zu erstellen wäre - inklusive passendem JavaScript. Ein Homepage-Baukasten ist dagegen etwas völlig anderes. Einen solchen kann Dein Schützling dafür nicht gebrauchen, da es sich ja um ein „sehr individulles Projekt“ handelt.
Liebe Grüße
Felix Riesterer
Hochachtungsvoll
j.j.
Hallo j.j.,
Die Humorlosigkeit in diesem Forum ist erstaunlich.
Bitte verallgemeinere nicht. "Es gibt hier Menschen, die ich für humorbefreit halte" wäre eher richtig. Und dass deine Seite nicht bedienbar ist, ist keine Privatmeinung, sondern Fakt.
"Nicht bedienbar" bedeutet hier: Nicht für jeden bedienbar. Lass die Seite mal von jemandem testen, der einen Screenreader verwendet.
(Ich hatte eingangs zwei konkrete Fragen gestellt, die unbeantwortet bliebe
Ja, sorry. Doch, ernsthaft. Leider haben wir keine historischen Browser zur Hand. Ich hätte das sonst gerne näher angeschaut. <object> funktioniert ganz gut für aktive Inhalte, bei SVGs fällt einem das schon auf die Füße, wenn dieses object in einem Link steckt. Dass Du auf <img> gewechselt bist, war wohl eine gute Idee.
kaputtes HTML
Deiner Privatmeinung wird von offizieller Seite deutlich widersprochen: validator.nu.
Jein. Das HTML ist laut Validator okay, aber der merkt längst nicht alles. Dein HTML ist enthält Konstrukte, die unüblich, unpassend oder veraltet sind. Und dass Du noch keine Einwände gegen die Seite zu hören bekommen hast, bedeutet nicht, dass sie einwandfrei funktioniert. Frag mal jemanden, der schlecht sieht und einen Screenreader verwendet.
Navlinks sind üblicherweise eine Liste. Deren Einträge setzt man mit Flexbox nebeneinander. Für den Abstand zwischen den Navitems verwendet man einen Margin auf den li oder - moderner - die gap Eigenschaft. Aber nicht  .
Deine Bildinfo ist semantisch falsch. Das ist keine Description List. Und es ist auch kein Element, das role="alert" verdient: "The ARIA alert role is used to communicate important and usually time-sensitive messages to users. When this role is added to an element, the browser sends out an accessible alert event to assistive technology products, which can then notify the user." Wenn überhaupt, ist das eine aria-live Region.
Die Bedienung, bei der ein Hover über einem Radiobutton schon ausreicht, um ihn zu selektieren, führt teils zu vogelwilder Reaktion der Seite. Hier fehlt auch die semantische Beziehung zwischen Radiobutton und Bild. Wenn ich Button 3 auswähle, weiß ein Screenreader nicht, dass Bild 3 dazu gehört.
Dass Dir (bzw. Herrn Hindelang) ein Karussell wichtig ist, ist wohl offensichtlich. Es dominiert die Seite. Deswegen brauchst Du Felix also nicht anzupflaumen. Das Karussell an sich ist eine nette CSS Konstruktion, in die Du viel Arbeit gesteckt hast. Ich würde Dir ja gerne neuere CSS Funktionen wie abs() ans Herz legen, aber Du möchtest offenbar auch ältere Browser unterstützen und da gibt's die noch nicht. Ich würde Dir aber empfehlen, das Karussell zu beschleunigen. Die Daumenregel ist: Mach es so schnell, wie es Dir als Developer gefällt, und DANN mach es nochmal doppelt so schnell. Visuelle Effekte dürfen die Besucher nicht behindern, und deine Karussellgeschwindigkeit tut das. Insbesodere empfinde ich es als störend, dass es - außer beim Wischen auf dem Handy - gefühlt 2 Sekunden dauert, bis nach einem Bildwechsel die Bildbeschreibung erscheint.
Du setzt einen tabIndex auf die Bilder und ein click-Event auf die Bilder. Das ist falsch - Bilder sind keine interaktiven Elemente. Ich weiß nicht, ob der Nu Validator das anmeckern würde - aber da du dieses Attribut per JS zuordnest, kann er es nicht bemerken. Für Tastaturbedienung genügt eigentlich die Radiobuttonleiste, auf der man die Pfeiltasten benutzt.
Die Radiobuttons würde ich übrigens per JS einfügen und nicht vorab ins HTML schreiben lassen. Das ist eine Fehlerquelle, und ohne JS ergeben die Buttons ohnehin keinen Sinn. Die Bedienung ist hier ohnehin merkwürdig. Ich kann mit der Tab-Taste zu den Radiobuttons gelangen und dann mit Pfeil-Links/Rechts navigieren. Drücke ich nochmal Tab, komme ich auf die vertabindexten Bilder und kann mit Tab von Bild zu Bild wechseln.
Also - einwandfrei? Hm.
Der Kunde will den Code anfassen.
Aber warum? Du schreibst doch selbst: Diesen Weg hab ich gewählt, um den Mann nicht zu überfordern und alles "self-contained" (wie sagt man da auf Deutsch?) zu halten., d.h. Herr Hindelang kennt die Basics von HTML, es darf aber nicht zu komplex werden. Es wäre doch wesentlich bequemer für ihn, wenn Du eine Beschreibungsformat hättest. Das kann in einem <script type="text/plain"> Element stehen. Und Du hättest dann jederzeit die Option, das HTML zu optimieren, ohne ihm erklären zu müssen, wie er dann die Bilder einpflegt.
Aber die Seite ist jetzt so und wenn Herr Hindelang nicht 10 Bilder pro Monat malt, dann lohnt sich eine generelle Umstellung wohl auch nicht mehr.
Rolf
@@Rolf B
Die Radiobuttons würde ich übrigens per JS einfügen und nicht vorab ins HTML schreiben lassen.
Ich nicht. Unnötig aufwendige DOM-Operation.
Einfacher und performanter ist es, die Elemente im HTML-Quelltext mit hidden-Attribut zu notieren und per JS hidden auf false zu setzen.
🖖 Live long and prosper
Hallo Gunnar,
...und mich damit auf N Radiobuttons zu limitieren? Wenn ich sie im HTML habe und die Anzahl kontrollieren muss, dann kann ich sie auch abzählen.
Und wenn ich sie mit JS eh anfassen muss, kann ich sie auch passend zu den Bildern erzeugen. Die Performance ist, da das genau 1x beim Seitenstart passiert, wohl nicht relevant.
Das ist ein Dreizeiler, für einen gewissen Wert von "Drei"…
const anzBilder = document.querySelectorAll("main img").length;
document
.querySelector("#radioList")
.innerHTML = "<input type='radio' name='r'>".repeat(anzBilder);
document.querySelectorAll("#radioList input")[anzBilder/2].checked = true;
Das aria-hidden kann man - nehme ich an - auch auf das #radioList-Element legen, dessen Verwendung ich für eine Liste von Radiobuttons dringend empfehlen würde (da das Ding als PE für non-Screenreader gedacht zu sein scheint, kann man wohl auf eine role verzichten und ein einfaches div draus machen).
Rolf
Hallo Gunnar,
...und mich damit auf N Radiobuttons zu limitieren? Wenn ich sie im HTML habe und die Anzahl kontrollieren muss, dann kann ich sie auch abzählen.
Hallo Ralf,
Dir scheint entgangen zu sein, daß die <input>s im HTML erforderlich sind, weil die Karussell-Basisfuktion rein mit CSS ohne JS arbeitet. Das habe ich schon an Felix und in meiner letzten Antwort an Dich geschrieben, vielleicht liest Du das beim dritten Versuch.
j.j.
Hallo j.j.,
ich hab's schon beim ersten Versuch gelesen. Aber vielleicht ist Dir entgangen, dass ich nicht vorschlug, die Radiobuttons wegzulassen, sondern sie per JS automatisch zu erzeugen, passend zur Zahl der Bilder. Das ist kein Muss. Nur das, was ich machen würde, um eine Fehlerquelle beim Erstellen der Seite auszuschließen.
Karussell-Basisfuktion rein mit CSS arbeitet (...)
Ja, hast Du geschrieben. Dass ein Funktionieren ohne JS für euch unabdingbar ist, hat noch eine andere Qualität und das war mir nicht klar. Aber ohne JS sind sehr viele Funktionen weg, vor allem bekommt der Besucher dann die Bildinfos nicht mehr ordentlich gezeigt. Wenn ihr die "Funktionsfähigkeit ohne JS" ernst meint, dann sollte da noch was passieren. Andernfalls solltet ihr dieses Ziel streichen. Find ich.
Rolf
Hallo Rolf!
"Nicht bedienbar" bedeutet hier: Nicht für jeden bedienbar. Lass die Seite mal von jemandem testen, der einen Screenreader verwendet.
Die Seite ist nicht barrierefrei und war nie so gedacht. Es gibt marginale Ansätze nach dem Motto: besser als nichts.
NVDA kann ich auch selber verwenden. Bei mir funktioniert die Seite. Ja, für Sehbehinderte stehen nur die wenige Informationen aus dem alt zur Verfügung weil der Bildinhalt selbst nicht beschrieben wird.
kaputtes HTML
Deiner Privatmeinung wird von offizieller Seite deutlich widersprochen: validator.nu.
Jein. Das HTML ist laut Validator okay, aber der merkt längst nicht alles.
Sorry, das ist doch nicht der Punkt. Der Validator prüft den Code auf Gültigkeit und leider nicht auf persönliche Formatierungsvorlieben von Felix R.
Dein HTML ist enthält Konstrukte, die unüblich, unpassend oder veraltet sind
- Navlinks sind üblicherweise eine Liste. Deren Einträge setzt man mit Flexbox nebeneinander. Für den Abstand zwischen den Navitems verwendet man einen Margin auf den li oder - moderner - die gap Eigenschaft. Aber nicht  .
ok, lieber ein Flexbox Layout anstatt fünf ? Kannst Du gerne so machen, meine Prioritäten sind anders.
- Deine Bildinfo ist semantisch falsch. Das ist keine Description List.
Veto! Das ist semantisch korrekt, RTFM!
Und es ist auch kein Element, das role="alert" verdient: "The ARIA alert role is used to communicate important and usually time-sensitive messages to users. When this role is added to an element, the browser sends out an accessible alert event to assistive technology products, which can then notify the user." Wenn überhaupt, ist das eine aria-live Region.
Veto! Meine (sehr eingeschränkten) Tests mit NVDA haben ergeben, daß mit diesem Layout nur role=alert ein brauchbares Ergebnis liefert (soweit ich als Sehender das beurteilen kann) role=live kommt erst wenn alle Bilder vorgelesen wurden, nach zwischenzeitlichen Interaktionen oft garnicht.
- Die Bedienung, bei der ein Hover über einem Radiobutton schon ausreicht, um ihn zu selektieren, führt teils zu vogelwilder Reaktion der Seite.
Ja, nicht ganz ungewollt. Das hat sich aus einer anfänglichen Nutzeranalyse ergeben (da waren die Bilder selber noch nicht anklickbar). Die Hälfte der Probanten hat nicht herausgefunden, daß man auf die gelben Knödel klicken muß, um etwas zu bewegen. Durch das hover=click Verfahren gab es eine sehr gute Chance, draufzukommen. Ich hab mehrfach ergebnislos erwogen, das wieder zu ändern. Der Kunde würde auf ein entsprechendes Ansinnen antworten: warum? soll ich ihn an Dich verweisen😀?
Hier fehlt auch die semantische Beziehung zwischen Radiobutton und Bild. Wenn ich Button 3 auswähle, weiß ein Screenreader nicht, dass Bild 3 dazu gehört.
Veto! Damit der Screenreader nicht 12 sinnlose Buttons vorliest, werden diese übersprungen (wg. aria-hidden=true böse-böse-böse), stattdessen wendet sich der Screenreader direkt den fokusierbaren Bildern zu (wg. tabindex=0). wenn man ein bild „klickt“, wird wegen role=alert die Beschriftung gleich vorgelesen. Einfach mal testen, VoiceOver oder NVDA hast auch Du!
- Dass Dir (bzw. Herrn H) ein Karussell wichtig ist, ist wohl offensichtlich.
Ich bin der Dienstleister, mir ist das egal. Und ob Du es glaubtst oder nicht: Ich habe anfangs von einem 3d-Karussell abgeraten aus zwei Gründen:
<img loading=lazy> tut es hier nicht.Es dominiert die Seite. Deswegen brauchst Du Felix also nicht anzupflaumen.
Der Mensch hat mich ungefähr dreimal beleidigt, was erwartest Du? Ich bin nicht Jesus.
Ich würde Dir ja gerne neuere CSS Funktionen wie abs() ans Herz legen, aber Du möchtest offenbar auch ältere Browser unterstützen und da gibt's die noch nicht.
wozu genau braucht man abs()?
--Ort: calc( var(--Nr) - var(--check) );
--Abs: max( var(--Ort), var(--Ort) * -1 );
<Quatsch/> wie es Dir als Developer gefällt, <Quatsch/>
Ich bin Dienstleister
Insbesodere empfinde ich es als störend, dass es - außer beim Wischen auf dem Handy - gefühlt 2 Sekunden dauert, bis nach einem Bildwechsel die Bildbeschreibung erscheint.
Richtig! This was a stupid regression from previous codeland, sorry for that! Probier heute nochmal, evtl. Cache leeren.
- Du setzt einen tabIndex auf die Bilder und ein click-Event auf die Bilder. Das ist falsch - Bilder sind keine interaktiven Elemente.
Naja ... tabindex ist ein Hack wg. <input aria-hidden=true>, damit Screereeder stattdessen die Bilder als interaktive Elemente sehen - siehe oben. Nach meinen Tests verbessert es die Nutzererfahrung. Wenn mich die Kenntnis ereilt, daß dem nicht so ist, werf ich das wieder raus.
- Die Radiobuttons würde ich übrigens per JS einfügen und nicht vorab ins HTML schreiben lassen. Das ist eine Fehlerquelle, und ohne JS ergeben die Buttons ohnehin keinen Sinn.
Veto! Ohne JS funktioniert das Karussell sehr wohl. Die Abstände zwischen den Bildern sind allerdings ungleichmäßig, teiweise überlappend und das Schriftfeld funktioniert nicht. Teste mit einem Browser Deiner Wahl! (bei Palemoon 33.7 (2025) und Vivaldi 1.5 (2019) leider ohne 3d-Effekt, auf Android wird leider ein zweistöckiges „g“ verwendet, außer bei Brave)
Der Kunde will den Code anfassen.
Aber warum?
Ja warum nicht? selfHTML? War da mal was? H ist übrigens Selfhtml-Leser, vielleicht hören wir och was ...
Du schreibst doch selbst: Diesen Weg hab ich gewählt, um den Mann nicht zu überfordern und alles "self-contained" (wie sagt man da auf Deutsch?) zu halten., d.h. Herr H kennt die Basics von HTML, es darf aber nicht zu komplex werden. Es wäre doch wesentlich bequemer für ihn, wenn Du eine Beschreibungsformat hättest. Das kann in einem <script type="text/plain"> Element stehen. Und Du hättest dann jederzeit die Option, das HTML zu optimieren, ohne ihm erklären zu müssen, wie er dann die Bilder einpflegt.
Warum? Du willst ein Problem lösen, das nicht existiert. Es wurde erklärt und ein paar mal überwacht. Seit 2½ funktioniert alles zur vollsten Zufriedenheit der Beteidigten.
Aber die Seite ist jetzt so und wenn Herr H nicht 10 Bilder pro Monat malt, dann lohnt sich eine generelle Umstellung wohl auch nicht mehr.
Die Umstellung hätte sich zu keinem Zeitpunkt gelohnt, es gibt keinen Grund.
Rolf
tschüs
j.j.
Hallo,
Der Mensch hat mich ungefähr dreimal beleidigt
Bitte versuch das Ganze mal mit weniger Emotionen zu betrachten. Felix hat dich nirgendwo beleidigt. Er hat Kritik geübt, sie ist negativ ausgefallen. Er hat nicht dich kritisiert, sondern Dein Werk. Bitte verwechsel nicht Dich und dein Werk.
Gruß
Kalk
Hi,
Einen schönen Tag noch
Martin
Hi,
Einen schönen Tag noch
Martin
Hallo auch! Ich hatte zwei konkrete Fragen gestellt (die unbeantwortet blieben, kein Problem)
Ich habe niemanden gebeten, meinen Code zu beurteilen, das kann ich im Wesentlichern selber. Fundierte Hinweise oder Kritik sehr gerne, dazu vorher aber den Code bitte lesen, und dann lospoltern.
j.j.
Moin,
„Reiß Dich mal zusammen“ möchte man Dir angesichts dieser Zeilen entgegnen:
Deine Antwort enthält nichts konkretes, nur Deine betonierte Privatmeinung, Konjunktive und mehrere Beleidigungen.
Felix hat aus den relevanten, offiziellen Spezifikationen zitiert, das ist
Was sollen die angeblichen „Beleidigungen“ dabei sein?
Es ist Zeitverschwendung.
Das ist Deine „Privatmeinung“.
Die Humorlosigkeit in diesem Forum ist erstaunlich.
Von einer Antwort auf das ganze Forum schließen – kann man machen, halte ich allerdings für sinnlos angesichts der Teilnehmerinnenzahl.
Ich will hier garnichts rechtfertigen, oder bist Du Richter am Strafgericht?
Hat Dich denn überhaupt jemand „angeklagt“?
(Ich hatte eingangs zwei konkrete Fragen gestellt, die unbeantwortet bliebe - soweit kein Problem. Und jetzt siehst Du mich in der Pflicht, irgendwas „vollumpfänglich“ zu beschreiben? Sehe ich nicht so)
Hast Du bewusst oder unabsichtlich die Begründung für den Wunsch nach der „vollumfänglichenen“ Beschreibung unterschlagen? „[D]amit man wirklich verstehen kann, womit wir es hier tatsächlich zu tun haben“. Es ist „leider“ (?) so, dass man Probleme verstehen und nachvollziehen können muss um sie lösen zu können. Oder wärst Du als Pilot mit folgendem (angeblich tatsächlichen Austausch bei Quantas) anschließend zufrieden und sicher?
Pilot schreibt ins Bordbuch: Im Cockpit klappert etwas. Techniker antwortet: Im Cockpit wurde irgend etwas festgeschraubt.
Ist das Problem damit gelöst oder nicht?
Also das genaue Gegenteil von gut gemacht. Aber das Web ist voll von solchen halbgaren Ideen. In vielen Fällen ist es den Betroffenen weder das Geld noch die Zeit wert, eine belastbare gute Lösung zu erarbeiten. Und ich kann nicht beurteilen, ob da am falschen Ende gespart wird.
Was redest Du da? Die Seite funktioniert einwandfrei, auf jedem denkbaren Gerät auf jedem™ Betriebssystem mit jedem denkbaren fünf Jahre alten Browser. Und das ist kein Zufall.
Und das ist aber auch keine inhaltliche Entgegnung, sondern ein Strohmann. Aber das Fass hätte man auch gar nicht aufmachen brauchen, denn „hätte man geschwiegen, wäre man ein Philosoph geblieben.“
Das HTML ist nicht kaputt, es entpricht lediglich nicht Deinen persönlichen Neigungen und Vorlieben.
Kaputt ≠ ungültig. Ich könnte eine Seite komplett nur aus div und span erstellen, das wäre gültiges HTML, aber semantisch ein Totalschaden.
Kaputt - und technisch gültig – ist z.B. auch der Missbrauch des header á la
<header>
<h1 id=h1>Name …</h1>
<h2 id=h2>Vorstellung …</h2>
</header>
In h2 steckt hier keine Überschrift 2. Ordnung, sondern ein Untertitel. Zum Glück hat SELFHTML eine Dokumentation zur richtigen Verwendung von
headerh1 („Das h1-Element sollte die Seitenüberschrift sein, nicht die Website-Kennung.“)
- konfuses JavaScript (etwa von ChatGPT erstellt?)
Das ist eine Beleidigung (und läßt bei Dir Ahnungslosigkeit vermuten bezüglich LLMs und meinem Code)
Wo soll das denn eine „Beleidigung“ sein?
- unzugängliche Bedienerführung
Was ist unzugänglich für wen? (spar Dir die Antwort, ich werde sie nicht mehr lesen)
Stimmt, Du hast sie nicht gelesen, weil sie gegeben worden ist.
Aha, Du weißt was mir wichtig ist. Weiß Du auch die Lottozahlen von nächster Woche?
Ist Dir das Karussell doch nicht wichtig? Ich dachte, dass es Teil der Ausgangsfrage ist.
Es hat jedenfalls nichts mit Zufallsereignissen wie Lottozahlen zu tun, so viel Statistik muss an dieser Stelle schon ein.
Viele Grüße
Robert
@@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
And the winner is:
img.
Circumstances Alter Cases