52 Reaktionen zu “Responsive Image Rendering in TYPO3 6.2”

Kommentare abonnieren (RSS) oder TrackBack URL

Kleiner Fehler: „styles.content.imgtext.responsive = 1„ gibt es (im master) nicht mehr und ist auch nicht nötig.
Die Konstante hat keinen Effekt, sondern die Einstellung wurde durch das Setzen von einem anderen Wert als „default“ getätigt.

Ansonsten danke für den tollen Artikel.

Philipp Gampe am 22. Oktober 2013 um 09:12

Danke für den Hinweis Philipp. Fällt damit auch die Konstante weg?

Sven Wolfermann am 22. Oktober 2013 um 09:17

Grundsätzlich halte ich Responsive Image Rendering für einen Schritt in die richtige Richtung. Aber eigentlich sollte man den Responsive-Gedanken universeller denken.

Wenn man je nach Bildschirmgröße unterschiedliche Bilder ausgibt, warum gilt das nicht auch für Texte, Tabellen, Videos usw. Das macht auch in Bezug auf Barrierefreiheit Sinn.

Aber wie geschrieben ist es erst einmal schön, dass TYPO3 dieses Feature unterstützt.

Bertram Simon am 22. Oktober 2013 um 10:34

Wir freuen uns dass Dir das Feature gefällt und dass wir Dir helfen konnten die Responsive Images auszuprobieren.

Mobile-first geht übrigens u.a. so:
tt_content.image.20.maxW = 200

Vielen Dank auch von mir an alle die das Feature möglich gemacht haben, insbesondere an dir Firmen @work, jweiland und Marketing Factory die die Arbeitszeit von den beteiligten Entwicklern gesponsort haben!

Ingo Schmitt am 22. Oktober 2013 um 11:12

Ja die erste Konstante kann entfernt werden. Sie wird auch in Beta2 nicht mehr vorhanden sein.

Philipp Gampe am 22. Oktober 2013 um 15:00

Fein, da haben die sonst so behäbigen Entwickler von TYPO3 mal etwas sehr zeitnah umgesetzt.

be2just am 23. Oktober 2013 um 22:23

Super, vielen Dank für die Picturefill-Anleitung. Funktioniert wunderbar!

Aaaber: nicht im IE7+8. Zumindest in meinem aktuellen Projekt werden hier keine Bilder angezeigt. Die Lösung wäre, wohl folgenden Conditional Comment einzubauen:

<!–[if (lt IE 9) & (!IEMobile)]>–>

Quelle: https://github.com/scottjehl/picturefill

Nur: wie kann man das per TS abbilden? Weiß das jemand?

Christian Clemens am 04. Dezember 2013 um 17:15

Und gleich noch eine Frage: irgendwie gehen die Alt-Attibute der Bilder verloren. Bei mir zumindest haben die Bilder alt=“null“.

Das liegt daran, dass im äußeren Span das „data-alt“ fehlt.
Gibt es einen Marker den man verwenden kann, mit dem man in der SourceCollection etwas wie das hier bauen kann?

Christian Clemens am 04. Dezember 2013 um 17:27

Hi Christian!
Danke fürs Feedback!

Das IE-Problem bekommst du mit


…
###SOURCECOLLECTION###
<!--[if (lt IE 9) & (!IEMobile)]>
  <span data-src="###SRC###"></span>
  <![endif]-->
<noscript>
…

in den Griff.

Das alt-Thema geht in der Beta-Version nicht, da ###ALTPARAMS### mit Leerzeichen aus TYPO3 raus geparst wird und ich nicht einfach data-###ALTPARAMS### machen kann. Ich glaube, das ist in einer neueren Version gefixt, müsste ich mal testen. Dann werd ich den Artikel updaten.

Sven Wolfermann am 05. Dezember 2013 um 08:12

Hallo Sven,

super, vielen, vielen Dank für die Lösung zu IE7+8. Echt klasse! 😉

Zur Alt-Sache: ich habe die beta2, dort funktioniert data-###ALTPARAMS### noch nicht. Ist das ein gemeldeter Bug? Wonach muss ich suchen, um den aktuellen Status zu finden?

Christian Clemens am 05. Dezember 2013 um 11:12

Hallo Christian,

das Leerzeichen vor den ###ALTPARAMS### wird von TYPO3 erzeugt. In ###ALTPARAMS### steht nicht nur der alt Tag drin, sondern auch title und/oder longdesc. Das Leerzeichen vor dem alt=‘ kann prinzipiell entfernt werden, es kann aber je nach Konfiguration passierten, dass dann noch ein title oder ein longdesc mit ausgegeben wird.

Soweit ich das weis, gibt es zum entfernen des Leerzeichen noch kein Todo auf forge, wäre klasse wenn Du da eins anlegen würdest, dann kümmern wir uns um den Rest!

Grüße

Ingo

Ingo Schmitt am 05. Dezember 2013 um 11:48

Hallo Ingo,

klar, kann ich gerne machen. Nur: so ganz habe ich die Leerzeichen-Sache noch nicht verstanden.

Wenn ich im TS schreibe:

Kommt im Frontend heraus:

Im Grunde gut, nur das es alt-data heißen müsste und das data-=““ überflüssig ist.

Ist das durch das ominöse Leerzeichen begründet? 😉

Christian Clemens am 06. Dezember 2013 um 15:12

Aha, Tags werden hier rausgefiltert – zweiter Versuch:

Wenn ich im TS schreibe:
span data-picture=““ data-###ALTPARAMS###
Kommt im Frontend heraus:
span alt=“Hier ein Text“ data-=““ data-picture=““

Im Grunde gut, nur das es alt-data heißen müsste und das data-=”“ überflüssig ist.

Ist das durch das ominöse Leerzeichen begründet?

Christian Clemens am 06. Dezember 2013 um 15:14

Das Anpassen des Image-Renderings ist schon mal eine sehr gute Sache. Allerdings sollte man für responsive Images auch die Anpassung von Bildausschnitten für diverse Auflösungen beachten. Man bräuchte also bei der Pflege von Bildern die Möglichkeit mehrere Quellbilder auszuwählen und jedem einen bestimmten Media Query zuzuordnen.

Malte am 16. Dezember 2013 um 12:13

Wenn man verschiedene Bilder oder Ausschnitte für die verschiedenen Viewports haben möchte, wird die ganze Sachen direkt komplex und Individuell: Die Viewports definieren sich ja aus dem Layout, je nach Viewport wird dann mal ein abweichendes und mal kein abweichendes Bild benötigt. Das muss dann auch sauber im BE für den Redakteur dargestellt werden, sprich man muss dann für jedes Bild die Möglichkeit schaffen eine 1:N Verknüpfung pro Viewport anzulegen. Das sind dann IRRE Elemente im FAL.
Wenn man nun bedenkt, dass dies ja vom Layout abhängig ist, wird das schnell sehr individuell und schwer allgemeingültig im Core zu hinterlegen. Schließlich würde eine allgemein gültige 1:N IRRE Verknüpfung die Nutzung für alle (egal ob responsive oder nicht) Redakteure grundsätzlich verkomplizieren.
Genau für solche Zwecke gibt es aber einen Hook, in dem man das Rendering anpassen kann.

Ingo Schmitt am 16. Dezember 2013 um 15:56

Hallo zusammen,
danke für die schöne Zusammenfassung. Leider klappt das ganze bei mir nicht in etwas komplexeren Verschachtelungen bzw. cObjects. Kann mir jemand helfen/ erklären warum das nicht geht:

lib.main_menu = HMENU
lib.main_menu {
entryLevel = 0
1 = TMENU
1 {
..
..
NO {
ATagTitle.field = abstract // description // title
wrapItemAndSub = |
stdWrap.cObject = COA
stdWrap.cObject {
10 = FILES
10 {
references {
table = pages
uid.field = uid
fieldName = media
}
renderObj = IMAGE
renderObj {
file.import.data = file:current:publicUrl
altText.data = file:current:description
titleText.data = file:current:title
layoutKey = srcset
layout.picturefill {
element (

###SOURCECOLLECTION###

)
source =
}
sourceCollection {
small.maxW = 300px
small.mediaQuery = (max-width: 400px)

middle.maxW = 600px
middle.mediaQuery = (min-width: 401px) AND (max-width: 600px)

large.maxW = 900px
large.mediaQuery = (min-width: 601px)
}
}
}
20 = TEXT
20.field = title
}
}

Fabian am 21. Januar 2014 um 16:49

Hallo zusammen,
danke für die schöne Zusammenfassung, funktioniert auch für Content Elemente super.
Ich versuche es aber in einem Menü mit Bilder zu integrieren und da werden die „neuen“ responsive TYPOSCRIPT Optionen einfach
ignoriert. Eigentlich sollte das doch bei jedem Objekt vom Typ IMAGE gehen oder?

Kann mir jemand helfen/ erklären warum das nicht geht:

lib.main_menu = HMENU
lib.main_menu {
entryLevel = 0
1 = TMENU
1 {
..
NO {
..
stdWrap.cObject = COA
stdWrap.cObject {
10 = FILES
10 {
references {
..
}
renderObj = IMAGE
renderObj {
file.import.data = file:current:publicUrl
altText.data = file:current:description
titleText.data = file:current:title
layoutKey = srcset
layout.picturefill {
element (

###SOURCECOLLECTION###

)
source =
}
sourceCollection {
small.maxW = 300px
small.mediaQuery = (max-width: 400px)

middle.maxW = 600px
middle.mediaQuery = (min-width: 401px) AND (max-width: 600px)

large.maxW = 900px
large.mediaQuery = (min-width: 601px)
}
}
}
20 = TEXT
20.field = title
}
}

Fabian am 21. Januar 2014 um 16:53

Hallo Fabian,

so einfach ist die Sache nicht. Das responsiv Rendering der Bilder wird nur in der CSS styled Content User Function angestoßen. Das IMAGE Object selber wird dabei nicht berücksichtigt.

Untested aber grob überschlagen müsstest Du
– renderObj = IMAGE
ersetzen mit
+ renderObj < tt_content.image.20

Welche Keys im einzelnen für Deinen Fall dann angepasst werden müssen, müsstest Du bitte im TypoScript Object Browser nachschauen.

Sebastian Fischer am 22. Januar 2014 um 11:27

Danke für den Input. Klappt super. Hier als Referenz noch das Ergebnis:

lib.main_menu = HMENU
lib.main_menu {
..
1 {
..
NO {
..
stdWrap.cObject = COA
stdWrap.cObject {
10 = FILES
10 {
references {
table = pages
uid.field = uid
fieldName = media
}
renderObj
imgList.data = file:current:identifier
imgPath = fileadmin
imgMax = 1
1 {
file.import.current = 1
layoutKey = srcset
imgList.field.sourceCollection {
small.maxW = 300px
small.mediaQuery = (max-width: 400px)

middle.maxW = 600px
middle.mediaQuery = (min-width: 401px) AND (max-width: 600px)

large.maxW = 900px
large.mediaQuery = (min-width: 601px)
}
}
20 = TEXT
20.field = title
}
}
}
}

Fabian am 23. Januar 2014 um 17:05

sorry das ich das hier vollspamme. Vlt. kann ein Moderator jeweils meine ersten beiträge löschen. Fehler im Typoscript.

Danke für den Input. Klappt super. Hier als Referenz noch das Ergebnis:

##Menu oben
lib.main_menu = HMENU
lib.main_menu {
entryLevel = 0
1 = TMENU
1 {
expAll = 1
#noBlur = 1
wrap = |
NO = 1
NO {
ATagTitle.field = abstract // description // title
wrapItemAndSub = |
stdWrap.cObject = COA
stdWrap.cObject {
10 = FILES
10 {
references {
table = pages
uid.field = uid
fieldName = media
}
renderObj
imgList.data = file:current:identifier
imgPath = fileadmin
imgMax = 1
1 {
file.import.current = 1
layoutKey = srcset
imgList.field.sourceCollection {
small.maxW = 300px
small.mediaQuery = (max-width: 400px)
middle.maxW = 600px
middle.mediaQuery = (min-width: 401px) AND (max-width: 600px)
large.maxW = 900px
large.mediaQuery = (min-width: 601px)
}
}
}

}
20 = TEXT
20.field = title
}
}
ACT < .NO
ACT.wrapItemAndSub = |
IFSUB < .NO
IFSUB.wrapItemAndSub = |
IFSUB.ATagParams = class=“dropdown-toggle“ data-target=“#“ data-toggle=“dropdown“ role=“button“
ACTIFSUB < .IFSUB
ACTIFSUB.wrapItemAndSub = |
}
}

Fabian am 23. Januar 2014 um 17:08

Huhu,

ich habe heute die beta5 getestet, aber das mit dem data-alt funktioniert auch hier noch nicht – soweit ich das sehe. Die Bilder erhalten bei mir daher alle eine „null“ als Alt-Text.

Ingo hatte mich ja gebeten (s.o.), eine Todo auf forge anzulegen, aber ich habe nicht genau verstanden, was das Problem ist, weshalb ich mich das bislang noch nicht getraut habe.

Christian Clemens am 11. Februar 2014 um 15:03

Und noch eine Frage: im Code oben wird ja maxW definiert in Abhängigkeit von bestimmten Viewportmaßen.

Gibt es eine Möglichkeit, gleichzeitig maxWInText zu setzen? So dass die maximale Bildbreite abhängig davon ist, ob das Bild einzeln da steht oder neben einem Text?

Christian Clemens am 12. Februar 2014 um 12:44

Dadurch das $maxWInText im CssStyledContentController vor dem eigentlichen Rendering der Bilder in $maxW kopiert wird greift dieser Wert ohne Anpassung des TypoScripts.

Sebastian Fischer am 12. Februar 2014 um 14:03

@Sebastian: thank you for your quick response!
So if I set this:
tt_content.image.20.maxW >
tt_content.image.20.maxWInText >
tt_content.image.20.maxWInText = 375
tt_content.image.20.maxW = 500
and this:
large.maxW < tt_content.image.20.maxW
the maximum widht of text/image images should automatically be 375px?

Christian Clemens am 12. Februar 2014 um 15:32

Nein die Idee ein wenig anders. Du kannst maxW setzen und maxWInText. Beim Rendering wird dann je nachdem ob das Bild alleine oder im Text steht mit der passenden Größe ausgegeben. Dabei wird intern im PHP ohne das der Integrator was ändern muss der passende Wert in die Variable $maxW kopiert. Das hat vor der Änderung schon so funktioniert und tut es immer noch.

Sebastian Fischer am 12. Februar 2014 um 15:40

Warum habe ich eigentlich auf Englisch geschrieben…? Sorry!

Wenn ich das so mache, wie von Dir beschrieben, also maxW und maxWInText auf einen Wert setze (so wie in meinem Beispiel), dann wirkt bei mir leider nur maxW – auch bei Bildern neben Text. Deswegen hatte ich nachgefragt.

Möglicherweise bin ich auch zu blöd Dich richtig zu verstehen? Oder ist meine Zuweisung large.maxW < tt_content.image.20.maxW falsch? Aber irgendetwas muss ich hier doch zuweisen, oder ist das mein Denkfehler? Hier der Übersicht halber der komplette relevante Code von mir (wichtig in der SourceCollection ist der letzte large-Teil):

tt_content.image.20.maxW >
tt_content.image.20.maxWInText >
tt_content.image.20.maxWInText = 375
tt_content.image.20.maxW = 500

tt_content.image.20.1.sourceCollection {
small.maxW = 180px
small.mediaQuery = (max-width: 319px)

middle.maxW = 280px
middle.mediaQuery = (min-width: 320px) AND (max-width: 500px)

large.maxW < tt_content.image.20.maxW
large.mediaQuery = (min-width: 501px)
}

Christian Clemens am 12. Februar 2014 um 16:13

Vielen Dank, das sieht schon sehr vielversprechend aus.

Gibt es eine Möglichkeit, maxW in Abhängigkeit der Anzahl Spalten zu setzen?

Im Moment werden meine Bilder immer in der gleichen Grösse gerendert – unabhängig ob 1 oder 5 Bilder in eine Zeile dargestellt werden sollen – und meine Versuche bisher scheiterten …

David am 11. März 2014 um 15:43

@Ingo Schmitt:

„Mobile-first geht übrigens u.a. so:
tt_content.image.20.maxW = 200“

in der 6.2.0 geht das so nicht. Damit werden auch die sourceset-bilder auf diese Größe gerändert.

Peter am 02. April 2014 um 19:17

OK, man muss in der SourceCollection jeweils das maxW neu setzen, also so:

tt_content.image.20.maxW = 200

tt_content.image.20.1.sourceCollection {
small >
smallRetina >

small {
width = 200

srcsetCandidate = 600w
mediaQuery = (max-width: 600px)
dataKey = small
}
pad {
width = 400
maxW = 400
srcsetCandidate = 799w
mediaQuery = (max-width: 799)
dataKey = pad
}
normal {
width = 800
maxW = 800
srcsetCandidate = 1000w
mediaQuery = (max-width: 1000px)
dataKey = normal
}
wide {
width = 1000
maxW = 1000
srcsetCandidate =
mediaQuery = (max-width: 1000px)
dataKey = wide
}
}

So funktioniert es jetzt exakt so wie im Polyfill beschrieben.

Peter am 02. April 2014 um 19:47

Da ich mit den oben beschriebenen Ansätzen noch nicht so ganz glücklich war, möchte ich noch einmal eine Alternative mit Data-Attributes in den Ring werfen.
Ein großes Problem ist die Ausgabe des Standard-Bildes für Smartphones mit kleinem Bildschirm und vermutet schlechter Internetverbindung zu verhindern. Daher die Idee zunächst ein Platzhalter-Bild auszugeben und dann per Javascript die passenden Bilder zu platzieren. Hier das TS:

tt_content.image.20.1.layout.data.element (

)

tt_content.image.20.1.sourceCollection {
small >
smallRetina >

small {
maxW = 200
dataKey = small
}
normal {
maxW = 920
dataKey = normal
}
retina {

if {
value = {$styles.content.imgtext.layoutKey}
equals = default
negate = 1
}

maxW. = 2000
pixelDensity = 2
dataKey = retina
}

}

Dazu habe ich dann diese Javascript benutzt und leicht modifiziert:

https://github.com/highergroundstudio/jquery-retina-data

Niklas am 15. April 2014 um 21:56

Hmm, schade, beim Absenden des Formulars wird leider der wichtigste Teil rausgefiltert, keine Ahnung wie ich das verhindern kann.

Niklas am 15. April 2014 um 21:59

Hallo Niklas,

packe doch dein TS in ein Gist und verlinke es hier nochmal, oder schicke es mir, dann bearbeite ich den Kommentar so, dass es richtig dargestellt wird.

Grüße, Sven

Sven am 16. April 2014 um 07:55

übrigens in der aktuellen 6.2 scheint es auch zu klappen wenn man das Image Objekt direkt benutzt, ohne den Umweg über tt_content.image.20, ganz stark!

https://gist.github.com/anonymous/10831180

Fabian am 16. April 2014 um 10:20

Weiß jemand wie man das ganze nun auch im ViewHelper aus Fluid heraus nutzen kann oder alternativ aus einem extra-Viewhelper? Sodass dort am Ende ebenfalls das , etc. herausfällt mit den entsprechenden Attributen.

Moritz am 12. Mai 2014 um 15:34

Hallo zusammen,
meine Redakteure brauchen weiterhin die Option mehrspaltige Bilder anzulegen, bzw. Bilder zu verkleinern (50% o.ä.).
Leider scheinen die Bildspalten aktuell beim Responsive Image Rendering nicht zu klappen.
Deswegen wollte ich einfach das maxW Attribut durch die Anzahl der Columns teilen. Leider bin ich aber zu blöd dem maxW Attribut ein cObject zu zuweisen. Kann mir hier jemand helfen?

Im Prinzip sollte das in etwas so aussehen:

tt_content.image.20.1.sourceCollection {
small.maxW.cObject = TEXT
small.maxW.cObject.value = 400/{field:imagecols}
small.maxW.cObject.insertData = 1
small.maxW.cObject.prioriCalc = 1
small.maxW.cObject.wrap = |px
small.srcsetCandidate = 400w

Gerne bin ich auch für andere Ideen offen. Wie löst ihr das Problem?

Viele Grüße

Fabian

Fabian am 13. August 2014 um 09:59

Hallo zusammen!
auch ich beschäftige mich gerade mit TYPO3 6.2 und Responsive Images auch in Bezug auf Retina Displays. Die ein oder andere Anleitung wie die auf dieser Seite oder z.B. die von Ingo Schmitt: http://blog.marketing-factory.de/typo3/tutorial_responsive_images/ findet man ja schon im Netz – das funktioniert soweit bei mir auch schon sehr gut. Ich habe aber eine grundlegende (Verständnis-)frage: mit diesem Ansatz geht im Backend die Möglichkeit komplett verloren, Bilder durch den Redakteur skalieren zu lassen – also die Angaben Höhe und Breite bei Erscheinungsbild sind dann wirkungslos (und letztendlich auch die Ausgangsgröße in der das Bild hochgeladen wird). Damit könnte ich noch leben, denn bei einem einheitlichem Design ist es ggf. sogar von Vorteil, wenn der Redakteur das nicht jedes mal selbstständig festlegen kann Allerdings werden dann doch mehrere Breiten benötigt, z.B. bei „nur Bild“, „Bild mit Text“, verschiedenen Spalten oder – um noch einen drauf zu setzten – bei der Verwendung innerhalb von Plugins wie jfmulticontent. Habe ich da jetzt irgendetwas übersehen? Mir wäre es jetzt nicht wichtig, die Felder für Höhe und Breite wieder zu aktivieren, aber entweder dem Redakteur aus ein paar unterschiedlichen Breiten auswählen lassen, oder vielleicht sogar noch besser, abhängig von der Verwendungsart die Breiten zu definieren.
Freue mich über ein paar Gedanken von euch zu diesem Thema.
Danke schon mal
Christian

Christian Ehret am 01. September 2014 um 13:44

vielleicht noch als kleine Ergänzung:
ich kann natürlich über CSS die Breite beeinflussen und z.B. für Text/Bild so etwas machen:
div.csc-textpic-intext-right .csc-textpic-imagewrap {
width: 50%;
}

Jedoch wird die Grafik dann immer noch in der 100% Größe geladen, was ja in Sinne von Bandbreite nicht unbedingt sinnvoll ist.

Christian Ehret am 01. September 2014 um 14:59

Hallo zusammen,

ich wollte eben das Beispiel von Sven
(http://typo3-6.2beta.maddesigns.de/index.php?id=2)
testen aber unter Chrome funktioniert das nicht.
Auf 2 weiteren TYPO3 Seiten mit der gleichen Technik
z.b ( http://www.t3sbootstrap.de/javascript/ ) schauts ähnlich aus.

Gibt es eine Erklärung warum nur der Chroma damit Probleme hat?

Danke Gruß Carsten

Carsten Hager am 03. September 2014 um 13:02

@Carsten der Chrome unterstützt die srcset-Variante mit ‚w‘ ab Version 38. Bei caniuse.com ist die Referenz grün ab Version 34, das bezieht sich aber nur den srcset ‚2x‘ Support. Testen kannst du es im Chrome Canary – bei mir funktioniert es super.

Sven am 04. September 2014 um 08:21

Hallo zusammen,
das, dass mit den responsive images in Typo3 jetzt so funktioniert ist ja perfekt.
In Anlehnung an den Post von Ingo Schmitt vom 16. Dezember 2013 um 15:56, gibt es hier auch schon weitere Lösungsansätze oder evtl. eine Extension?
So das man verschiedene Bilder für verschiedene Viewports anzeigen lasen kann. Bsp. mobile ein grünes Bild und auf dem Desktop ein blaues Bild.
Ich hatte so was in der Art schon mal mit der Extension „Media“ umgesetzt und dort einem Bild (dem grünen Bild) ein alternatives Bild (blaues Bild) zugeordnet. Dem blauen Bild habe ich dann über die Kategorien die Eigenschaft „Desktop“ mitgegeben.

Oliver am 27. Oktober 2014 um 16:38

Hat jemand die srcset Lösung schonmal bei einem Projekt eingesetzt? Ich würde das gerne mal live sehen.

Markus am 28. November 2014 um 15:42
Ingo Schmitt am 28. November 2014 um 17:57

@ingo: das gefällt mir sehr gut. danke!

Markus am 01. Dezember 2014 um 07:43

eine Frage zu Bildern in Extensions, z.B in Fluid Templates:

Baut ihr dann einfach euer figure oder picture Konstrukt mit nach?

Oder mit einem eigenen viewhelper?

Markus am 02. Dezember 2014 um 11:34

Vielen Dank für die Anleitung. Als Ergänzung: Wenn die Bildgrößen mit w angegeben werden, muss „sizes“ angegeben werden. Ansonsten blasen Opera und Chrome die Bilder auf 100% auf. Dabei wird max-width ignoriert.
Ich habe das über „params“ gemacht:

params = sizes=“(min-width: 700px) 700px, 100vw“

Was mir nicht ganz klar ist: Kann ich hier nur die Breite definieren oder könnte man auch die Höhe als Zielwert angeben?

Grüße
Martin

fischhase am 22. Januar 2015 um 12:04

Hi zusammen, entweder ich denke zu kompliziert oder ich habs nicht verstanden.
Ich muss doch ein Javascript einsetzen, damit das responsive rendering doch funktioniert? Ich setze meinen layoutKey auf data. Wo bekomme ich jetzt das passende Javascript her?
Gruß
Michael

Michael am 05. Februar 2015 um 15:51

Hallo,
ich habe hier ein scheinbar größeres Problem welches mich seit Stunden zum Verzweifeln bringt. Ich habe alles wie in diversen Tutorials identisch beschrieben eingebaut (inkl. verschiedenster JavaScripte). Bei mir wird aber weder der HTML-Output verändert (also srcset gesetzt o.ä.) noch überhaupt irgendein Bild ausgegeben. Auch wenn ich alles wieder auf Anfang setze und alles TS und JS entferne bleiben meine Bilder unauffingbar. Laut FTP sind die Bilder aber an den Stellen an denen sie gesucht werden. Selbst Bilder die per CSS als Background-Image gesetzt sind sind weg. Rufe ich einen Bildpfad über den Browser direkt auf sind die Bilder ebenfalls nict verfügbar.
Ich hatte zwischendurch ganz kurz die Variante mit adaptive-images.php implementiert, diese aber da es genauso wenig funktioniert hat wieder entfernt.
Wie gesagt bei mir scheint gar nichts zu funktionieren. Für details würde ich die potentiellen Helfer bitte sich den Thread „Responsive Images srcset funktioniert nicht“ im German Forum auf Typo3.org anzuschauen.

Danke Euch

Manuel Bachl am 05. März 2015 um 13:07

Hallo, ich wunder mich, dass es bei euch allen auf Anhieb klappt. Ich habe picturefill.js und matchmedia.js von Scott Jehl included, in den Constants „styles.content.imgtext.layoutKey = picturefill“ eingesetzt und den entsprechenden Code im Setup „tt_content.image.20.1.layout.picturefill { […]“. Es passiert jarnüscht, das img-Element wird nicht mit picture etc. gewrapped. Was mache ich falsch?

Tolga am 29. April 2015 um 16:19
Trackbacks & Pingbacks

[…] getan. Ab der Version 6.2 LTS steht deren Lösung nun zur Verfügung und wirkt sich automatisch auf alle per Backend eingebundenen Bilder […]

[…] nachfolgenden Schritte basieren auf dem Blog Beitrag von Sven Wolfermann auf Typo3Blogger. Im Typoscript Template muss zunächst das aktuelle CSS Styled Content eingebunden […]

Pingback von Ein responsives Webdesign mit Typo3 (Teil 7) am 05. Dezember 2014 um 10:06

[…] Ein Komplettbeispiel für das IMAGE Objekt gibt es hier. Weitere Informationen sind hier und hier. […]

Pingback von TYPO3 CMS 6.2 LTS: Das sind die Vorteile und Änderungen - Lichtflut.Medien Blog am 20. April 2015 um 17:13

[…] Es wird kein Plugin benötigt, ab 6.2 sind grundsätzlich Adaptive Bilder Bestandteil des Cores. Je nachdem, welche Anforderungen bestehen, sind jedoch Anpassungen an der JavaScript-Bibliothek notwendig. Eine Anleitung gibt es beispielweise hier (ich würde die Einbindung von Picturefill von Scott Jehl empfehlen): Responsive Image Rendering in TYPO3 6.2 […]

Pingback von Plugins für responsive Bilder: Wordpress, Joomla, Typo3, Drupal am 28. März 2016 um 11:25

Kategorien

Archiv