SVG niet scherp op niet-retina, wel op retina

[Ronnyrr]

Hi Tweakers,

Voor een nieuw project maak ik gebruik SVG elementen om afbeeldingen (met enkel een border te tonen). Dit deed ik op de volgende manier:

code:

<img width="80" height="90"  src="/assets/images/shape.svg" />

Helaas zijn deze afbeeldingen niet scherp op niet-retina schermen en wél scherp op een retina scherm. Zie ook onderstaand waar links niet-retina is en rechts retina.


Ik kon er niet achter komen waardoor dit komt.
In een Stack Overflow topic werd gesuggereerd een <object /> te gebruiken in plaats van een image. Helaas werkt dit ook niet, het resultaat is gelijk aan het gebruik van een <img /> tag.

Iemand die hier een oplossing en eventuele uitleg voor heeft?
Bij voorbaat dank!

[rewind.]

Vermoed dat je SVG groter is dan de 80x90? Waardoor tijdens het schalen je lijndikte te dun wordt voor de lagere resolutie om goed weer te geven.

[Ronnyrr]

Haha soms kan het zo simpel zijn dus. Thanks, was inderdaad het geval!

[JaPPa03]

Als je svg gebruikt kun je het beste de svg code in je HTML plaatsen. Dit scheelt weer een request tijdens het laden en de afbeelding kan dan automatisch schalen naar ieder formaat/resolutie.

[Caelorum]

Zolang het maar niet animated svgs zijn, want daar snapt IE niets van

[n8n]

JaPPa03 schreef op donderdag 28 mei 2015 @ 08:59:
Als je svg gebruikt kun je het beste de svg code in je HTML plaatsen. Dit scheelt weer een request tijdens het laden en de afbeelding kan dan automatisch schalen naar ieder formaat/resolutie.

Scheelt een request ja maar je hebt overhead en de afbeelding wordt niet gecached. Komt de afbeelding op meerdere pagina's voor zit je met de extra bytes elke keer. Daarnaast is het verminderen van requests goed maar tot een treshhold. Wil je dat de hele pagina moet wachten op 1 afbeelding? Als je het vaker doet dan eens, is het oké als de html over de 100kb gaat?

Een connectie gaat ook nog eens langzaam omhoog qua bytes die er doorheen kunnen beginnend met 14kb. Het is dus aan te raden de eerste request daar onder te houden.

Ik zeg niet dat inline svg nooit handig is, maar zeker niet altijd.

[NMe]

En dan heb je het nog niet eens over de footprint van je HTML als je hetzelfde plaatje meerdere keren nodig hebt op dezelfde pagina. Al die plaatjes inline zetten betekent allemaal extra data in je HTML. Kan natuurlijk subliem compressed worden door GZip maar of het nou zou handig is...

[Ronnyrr]

Handig om te weten. Om hier nog even op in te haken heb ik nog een vraag.
Ik liep met het testen op Android (3.1) via een Galaxy Tab op een probleem met de weergave van de SVG in een <img> tag. Zodra ik de SVG weergaf via een <object> had ik hier geen probleem mee:



Het bovenste voorbeeld is met een <img> en de onderste met een <object> zoals:

code:

<object data="your.svg" type="image/svg+xml">
  <img src="yourfallback.jpg" />
</object>

Tevens het ik met <img> op desktop en andere mobiele apparaten (iPhone 6 en Nexus 5) geen problemen kunnen ontdekken. Op een Samsung Y werd de fallback gebruikt.

Worden <object> tags wél gecached zoals een afbeelding <img>?
De SVG wordt binnen mijn website namelijk redelijk vaak gebruikt.

[ Voor 29% gewijzigd door Ronnyrr op 29-05-2015 22:17 ]

[Verwijderd]

Caelorum schreef op donderdag 28 mei 2015 @ 09:11:
Zolang het maar niet animated svgs zijn, want daar snapt IE niets van

Nog steeds niet? Maar daar was toch wel een Polyfill die die feature voor IE enabled?
https://leunen.me/fakesmile/
IE is ook nog steeds niet bezig met Web Components. (ook nog een polyfill voor nodig) Trage boel daar bij die IE developers. Alleen maar bezig met het renamen van hun producten.

[ Voor 9% gewijzigd door Verwijderd op 31-05-2015 13:30 ]

[Caelorum]

fakesmile is leuk, maar de ondersteuning is niet helemaal perfect, dus dat levert ook nog wel problemen op.
Probleem is overigens niet dat ze geen animated svg's ondersteunen, maar dat ze de declaratieve standaard niet willen ondersteunen. Dat laatste is een aparte standaard en staat niet op de planning. Had iets te maken met dat ze het beter vonden als je dat via javascript of CSS regelde. Javascript kan nu al, en CSS animations en transitions zitten als preview in IE (Edge denk ik?).

[Spinal]

SMIL is deprecated in Chrome, dus Opera, Vivaldi en andere Chromium-browsers zullen snel volgen. Vertrouw er dus niet op dat het in de toekomst blijft werken

[Boelie-Boelie]

offtopic:
Het plaatje zegt:
Via onze gratis video's laten wij zien wat MVO inhoud en hoe het uw organisatie een impuls geeft!
Daar zou ik 'inhoud' veranderen in 'inhoudt'.

[_Thanatos_]

Klein beetje offtopic:
Ik denk dat het het niet waard is om Android 3.x te ondersteunen met een <object> tag. Daar komen vast allerlei problemen van, en Android 3 is redelijk ancient. Vgs mij zijn alle 3.x tablets geupgrade naar 4.x.

Klein beetje ontopic:
Er lijkt nog iets mis te gaan met behoud van aspect ratio. Dat kun je oplossen met een preserveAspectRatio attribuut op je SVG. Maar daarvoor moet je dus geen <object> gaan gebruiken. Ook zou ik je aanraden om deze SVG als CSS-background te zetten, want het lijkt erop dat dat het ook is. Je kunt dan ernaast met (bijv) Modernizr een evt fallback met PNG voor fossiele browsers maken.

[n8n]

Hoezo modernizer, dat laat je een browser zelf uitzoeken door eerst de png te declareren en daarna de svg.

background-image: url(x.png);
background-image: url(x.svg);

In dit geval zijn de afbeeldingen ook content dus als background is semantisch incorrect.

[ Voor 21% gewijzigd door n8n op 01-06-2015 18:39 ]

[_Thanatos_]

@n8n dan moet je wel heel goed testen of dit werkt op alle verouderde browsers die je wilt ondersteunen, en je moet heel goed op moderne browsers testen of ze niet beide plaatjes gaan binnenhengelen. En of het uberhaupt werkt.

Bovendien werkt dit dus alleen voor SVG die je in CSS refereert. SVG in een <img> komt hiervoor niet in aanmerking.

[n8n]

In de css pakt ie altijd 1 op die manier, dat wordt eerst 'gelezen' en dan pas reageert de browser.

Voor html-elementen klopt dat maar ik vind zelf de svg ondersteunig goed genoeg, jammer voor de antieke browsers.