Bild Inhaltselement mit Animation und Trigger

[montao]

Hallo,


ich versuche folgendes umzusetzen:

Ein Bild Inhaltselement, das zuerst einen Ausschnitt zeigt, soll seine wahre Größe mit einer Animation nach unten entfalten.
Das ganze sollte aber erst mit einem Klick auf das Bild starten.

Ich wollte hier komplett auf js verzichten.

Die Animation habe ich mittels CSS/Keyframes erstellt, aber ich finde keine Lösung für den Trigger.


Für Eure Hilfe bedanke ich mich jetzt schon.


Grüße


montao

[Samson1964]

onClick? Ach Quatsch, wird ja Javascript...
Von Triggern in HTML5 oder CSS habe ich noch nichts gehört, aber vielleicht kommt das ja mit HTML6.

[tab]

Das einzige, was mir einfällt wäre, die Pseudoklasse target zu benutzen, aber das wird dir dann jedenfalls die Scroll-Position verschieben.

[folkfreund]

@tab: Danke!
Wenn das Bild groß dargestellt werden soll, dann ist es ja vielleicht auch nicht schlimm, wenn es nach oben rutscht.
Eine gute Erklärung zu :target gibt es hier:
https://blog.kulturbanause.de/2013/0...ion-beispiele/

[mlweb]

... aber das wird dir dann jedenfalls die Scroll-Position verschieben.

Wenn das :target auf die ID des Elements selbst gelegt wird muss das nichts zwangsweise ein störende Verschiebung sein.

[tab]

Stimmt. Würde ich auch in jedem Fall akzeptieren, wenn die unbedingte Vermeidung von Javascript bei einem Projekt notwendig wäre. Bleibt ja dann eh nichts anderes übrig. Was mich an der Target-Geschichte am meisten nervt, ist der Browser-Verlauf. Der Besucher kommt mit Klick auf seinen "Zurück"-Button woanders hin, als er gemeinhin erwartet. In einem meiner letzten Projekte habe ich mal ein Menü damit gemacht. Mal sehen, ob es den Kunden irgendwann nervt . Bis jetzt kam diesbezüglich jedenfalls noch keine Klage. Im Zweifel würde ich ihm dann halt eine Javascript/jQuery-Lösung mit dem bisherigen Menü als Fallback einbauen.

[mlweb]

Man kann zum "Triggern" in css aber auch :hover oder :focus einsetzen. Wenn man :hover verwendet hat man aber leider ein Problem mit Touchscreen, welches man dann lösen muss. Bei :focus und :hover wird die Vergrößerung "rückgängig" gemacht, bei :target ist das nicht möglich.
Bei :hover und :focus ist man auch nicht auf einen Link angewiesen. Bei :hover funktioniert das von Haus aus, bei :focus muss man für das Element (z.B. figure) das Attribut contenteditabel oder tabindex setzen.

Nachtrag: Für "getriggerte" css-Animationen benutzt Du dann keine keyframes. Sondern Normalzustand und Zustand der entsprechenden Pseudoklasse und die Animation für den Übergang zwischen beiden Zuständen. Die Animation ordnet man meist dem Normalzustand zu, dann läuft die Animation "vorwärts" bis der Zustand der Pseudoklasse erreicht ist und "rückwärts" bis der Normalzustand erreicht ist. Ordnet man die Animation der Pseudoklasse zu, dann läuft die Animation nur bis der Zustand der Pseudoklasse erreicht ist. Vom Zustand der Pseudoklasse zum Normalzustand gibt es dann einen "harten" Wechsel.

Edit: Ein Problem bei :hover mit Touch sollte in diesem Fall eigentlich gar nicht vorhanden sein. Die Interpretation als Klick sollte hierbei ja keinerlei negative Effekte haben. Bleibt nur die Frage ob bei nicht touchfähigen Geräten das temporäre Vergrößern ausreicht/gewünscht ist.
Ich glaube in dem vom TO beschriebenen Einsatzzweck würde meine Wahl auf :focus fallen.

[mlweb]

Was mich an der Target-Geschichte am meisten nervt, ist der Browser-Verlauf.

Ich habe :target auch schon für die Navigation eingesetzt. Am Anfang war mir die Problematik mit dem Browser-Verlauf gar nicht bewußt. Selbst nutze ich diesen nämlich kaum.
Die entsprechende Website ist jetzt schon 3 oder 4 Jahre online. Beschwert hat sich noch keiner. Die andere reine css-Lösung für Navigationen ist ja der Einsatz von Checkboxen, was aber immer wieder aus Gründen der Semantik als nicht das "Gelbe vom Ei" angesehen wird.

[tab]

Ich hatte mir ja überlegt, ob man den Browserverlauf nicht mittels jQuery irgendwie bereinigen könnte, das kam mir dann aber doch irgendwie vor wie "Thema verfehlt".

[montao]

Vielen Dank für die vielen Antworten.
Leider hatte ich keine Meldung bekommen, so dass ich erst jetzt antworte.
Werde morgen mich mal daran machen und Bescheid geben.

Bis dahin.

[sbeutler]

Ich hätte noch einen Vorschlag anzubieten:

Eine Kombination aus Label und verstecktem radio-Button in Zusammenspiel mit dem "+"-Selektor in CSS und :checked erlaubt das Aktivieren der Bildanimation.
Wenn man anstelle des radio-Elements ein checkbox-Element verwendet, könnte man sogar zwischen den beiden Zuständen wechseln.

Anbei ein Beispiel mit 2 radio-Button-Varianten (transition- und keyframe-gesteuerte Animation) sowie einer checkbox-Variante:
http://jsbin.com/tixotaxajo/1/edit?html,css,output

–––––
Stefan

[mlweb]

Halte ich für deutlich komplizierter als die :focus Lösung und semantisch korrekt ist dann wohl auch nicht.

[Andreas]

Mit :focus hatte ich das auch mal probiert und dann enttäuscht festgestellt, dass man ein FIGURE nicht fokussieren kann, aber der Trick mit dem tabindex ist wirklich gut. Das funktioniert bei mir einwandfrei. Habe auf die FIGUREs tabindex="0" gelegt, dann kann man die sogar mit der Tab-Taste durchgehen. contenteditable hatte bei mir mit dem FIGURE nicht funktioniert, habe die Attribute zum Testen allerdings nur mit JS aufgesetzt anstatt direkt im Template.

Danach kann man mit "figure:focus {..." und transition sehr viele Animationen umsetzen.

[mlweb]

Das funktioniert beides und zu tabben geht auch beides soweit ich das gerade getestet habe.
Gerade mal meine Testseite hochgeladen.

http://test.ml.webseiten.cc/bildanim...sse_focus.html

[Andreas]

ROFL.

Also entweder liegt es daran, dass ich das Attribut contenteditable mit JS aufgesetzt hatte, oder weil ich keine figcaption hatte, also keinen Inhalt, der bearbeitbar wäre. Aus irgendeinem Grund hatte es auf jeden Fall nur mit tabindex funktioniert. Das per JS aufgesetzte Attribut konnte ich in beiden Fällen im DOM sehen.

[mlweb]

... oder weil ich keine figcaption hatte, also keinen Inhalt, der bearbeitbar wäre.

War bei mir vorher auch ohne figcaption. Die habe ich nur für die Online-Demo reingesetzt, damit die zwei Varianten auch optisch zu unterscheiden sind.

[Andreas]

Gerade nochmal mit deiner Seite getestet. Also an meinen beiden Vermutungen liegt es nicht, weil ich konnte das auf deiner Seite auch erfolgreich mit nachträglich aufgesetztem contenteditable und auch ohne figcaption umsetzen. Also bleibt es rätselhaft, warum das bei mir nicht funktioniert hatte.

[mlweb]

... also keinen Inhalt, der bearbeitbar wäre.

Das Bild ist übrigens auch bearbeitbarer Inhalt. Kann man z.B. einfach löschen und/oder per drag and drop ein anders reinschieben.
Ich würde in der Praxis in diesem Fall aber ohnehin den tabindex nutzen.

[mlweb]

Also bleibt es rätselhaft, warum das bei mir nicht funktioniert hatte.

Vielleicht hat einer meiner beliebtesten Fehler bei Dir auch zugeschlagen - ein simpler Tippfehler.

[Andreas]

Mmh, ich hatte soviel ausprobiert, contenteditable = '', true, 'true'. Sogar contentEditable, weil das irgendwo bei mozilla.org so stand. Aber ist ja auch erstmal egal, kann man sich drum kümmern, wenn's nochmal auftreten sollte, ich würde auch tabindex benutzen.