I've setup two pages with the background-size:cover; with one using a .jpg and one using a .png. Both pages render fine in Chrome/Safari/Firefox on the desktop, but for some reason the .jpg version does not render on iPhone/iPad in Chrome/Safari.
PNG Version
JPG Version
I suspect it might have something to do with the compression of the .jpg which I set to the lowest (smallest file size) setting in Photoshop, but I could not find any actual info on this. Any advice is much appreciated!
EDIT:
I am already using the browser specific prefixes in my css (e.g. -webkit-,-moz,-o-).
background-size is a new CSS property and therefore isn't available everywhere yet
although in mobile devices -webkit-background-size:cover; should do the trick
For Safari versions <5.1 the css3 property background-size doesn't work. In such cases you need webkit.
So you need to use -webkit-background-size attribute to specify the background-size.
Hence use -webkit-background-size:cover.
Reference-Safari versions using webkit
Related
On my TYPO3 v10 website I have some SVG icons in use, no problem.
I also have a few more complex SVG Figures (created with Inkscape), that I want to include in TYPO3 website. Of course I can upload the .svg files to the fileadmin/ folder, and link to them with the Text+Image (or Text+Media) Content Elements.
In the Backend, TYPO3 generates some fine png-thumbnails for preview. So far so good.
The file can be downloaded directly, from its fileadmin/images ... location.
However, inside web pages, my SVGs are not displayed as they should.
A lot of styling information gets removed from the SVG and I don't know where.
Here is a screenshot of the original vs corrupted image (as displayed in the TYPO3 frontend).
Here is a graphical diff that shows the difference between the figures.
It turns out that at some time during the rendering process, TYPO3 removes the values from the style="...." SVG attributes. See reddish boxes.
All my more complex SVGs look like the one on the right when embedded in TYPO3.
Here is the SVG if you want to try yourself: image on SVGshare.com
On the right, many style attributes have been set to style="".
but why?
It's Firefox, not TYPO3, who removes the style="..." attribute values. This seems to be a longstanding Firefox Issue, solved.
See Bugzilla Issue 1262842: [CSP] Blocks the use of style attributes inside SVG without generating console errors.
Look for "triply confusing" in the first comment.
Inline CSS styles can be a security Problem, and therefore Firefox has a Content-Security-Policy (CSP) in place, in order to correct this.
An explainer for the mitigation strategies, written jointly by professional Security Engineers is given in this Google Doc and in Gihub Repo (Content Security Policy), Issue 45, Further granularity of unsafe-inline styles.
Script inline attributes are a difficult subject to approach when it
comes to CSP, they have the same amount of power as any other script
element but they don’t have ways to be whitelisted, for example, by a
nonce or hash. This means that the actual content of the attribute is
mostly the only deciding factor.
I don't understand everything mentioned in these docs and discussions. Inline-style Elements seem to be vulnerable to XSS attacks, and then attacker can put CSS url() in there for instance.
Quick-and-dirty solution
Use Inkscape and save as "optimized SVG", and check the option "Convert CSS Attributes to XML attributes". See attached screenshot of the Inkscape Dialog (Linux).
This solution was proposed by a web-developer from the GIMP devteam.
TYPO3 9 introduced an SVG Sanitizer, which automatically modifies SVG files during "fileadmin upload time", meaning it removes any <style ...> elements from the uploaded SVG file.
In TYPO3 10 and later versions, this SVG Sanitizer is by default automatically set up via Symfony dependency injection via core's Services.yaml.
You can remove the SVG Sanitizer via your own site extension's Services.yaml, e.g. for your myextension/Configuration/Services.yaml:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
# ...
# remove TYPO3's default-autowired SvgSanitizer, which tampers with filadmin uploaded SVGs (e.g. removes necessary <style> information)'
TYPO3\CMS\Core\Resource\Security\SvgEventListener: ~
The tilde (~) removes/overwrites the definition previously set up by core's Services.yaml ( https://symfony.com/doc/current/service_container/service_decoration.html ).
This seems to be a problem of your individual TYPO3 installation. I've just tested your SVG image in a brand new TYPO3 v10 installation and the image is rendered properly in backend and frontend.
Maybe you have some 3rd party extensions installed who postprocess the HTML output of TYPO3, e.g EXT:sourceopt or EXT:scriptmerger.
Is this possible at all? I call Image.createSVG(...) and receive an Image object without any errors. I then call Button.setIcon(). But there's no icon on the button.
You need to check Image.isSVGSupported() which currently will always return false.
Back in the day J2ME supported SVG thru one of the JSR's. No platform since has supported SVG natively with the exception of the web so this doesn't work on any of the modern platforms and we didn't bother implementing this even for the JavaScript port.
In the future we'd like to have a more efficient/portable way of supporting SVG e.g.: https://github.com/codenameone/CodenameOne/issues/1890
Fontastic.me is a website that let you upload svg files so you can use your icons as a font. I've used this site lots of times, but today I noticed the icons are not working on mobile anymore. They do work in the browsers on computer. I only noticed it today, it has always worked before.
You can use this link to test on mobile.
To me it seems like a bug in the Fontastic CSS generator: your page links CSS
https://fontastic.s3.amazonaws.com/8pMGtiqubDqmpbD4ER7hE3/icons.css
this contains last SVG fallback linked as
https://cdn.myfontastic.com/8pMGtiqubDqmpbD4ER7hE3/fonts/1446830181.svg#1446830181
the hash part of the URL must correspond with font ID in the SVG, but actual source contains <font id="cloud-font" horiz-adv-x="512"> instead.
So replacing #14468301 with #cloud-font in CSS or replacing #id value in SVG should fix your problem.
This applies only for case your mobile really resorts to SVG version. Only few browsers would do that (I think Android below 4.4, maybe old Safari, Blackberry, and maybe Opera Mobile).
(Besides that, your HTML contains extra HEAD tag with icon CSS link in BODY, what is not valid. I donʼt think this will make any sane browser completely ignore the link, but cannot exclude such possibility. If you have served your page as real application/xhtml+xml, browser should show the error right away.)
Greg, i had the same issue. I end up ditching Fontastic and use https://glyphter.com/ instead.
Glyphter creates your own font set by uploading each character at a time.
It worked for me and perhaps you can try this too and see if it works.
I know this is a bit of a silly question, but I can't work out how to make a transparent PNG work in IE6. I've tried several things, but they haven't worked. I was wondering if anyone could let me know of a suitable hack?
Thanks in advance,
AD72
Hey use jQueries pngFix. Works like a charm! http://jquery.andreaseberhard.de/pngFix/
have you tried this method? link text
i have tried a number of png hacks fore IE6 and this is the best one that resolves all of the problems that ie has with pngs. good luck
Here's the code we use that seems to work fine.
// from http://labs.unitinteractive.com/unitpngfix.php
var clear="/images/template/clear.gif" //path to clear.gif
pngfix=function(){var els=document.getElementsByTagName('*');var ip=/\.png/i;var i=els.length;while(i-- >0){var el=els[i];var es=el.style;if(el.src&&el.src.match(ip)&&!es.filter){es.height=el.height;es.width=el.width;es.filter="progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+el.src+"',sizingMethod='crop')";el.src=clear;}else{var elb=el.currentStyle.backgroundImage;if(elb.match(ip)){var path=elb.split('"');var rep=(el.currentStyle.backgroundRepeat=='no-repeat')?'crop':'scale';es.filter="progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+path[1]+"',sizingMethod='"+rep+"')";es.height=el.clientHeight+'px';es.backgroundImage='none';var elkids=el.getElementsByTagName('*');if (elkids){var j=elkids.length;if(el.currentStyle.position!="absolute")es.position='static';while (j-- >0)if(!elkids[j].style.position)elkids[j].style.position="relative";}}}}}
window.attachEvent('onload',pngfix);
Ive used the one from TwinHelix or the jquery one mentioned above.
The PNG form of image is Post Notational Graphic and is primarily described in a law in the era of Queen Victoria of England and therefore is primarily for use in Great Britain. The software for creating and displaying a PNG image is sourced from and protected by England and the different display software versions required for all browsers and different and new browser versions and content environments may not have been commissioned to be done and the incompatibilities could persist for some time. Originally the agreement was with MS and the IE browser only for displaying PNG and it is possible a number of unofficial hacks and decodes have been developed for other browsers with varying success. PNG is officially and completely renderable only when used in a defined list of nations and provinces.
I made the following observation:
If I create an svg image that references an external raster image via xlink:href and try to load the svg in browsers, the external images are only shown if I use the <object> tag, but not when using the <img> tag.
Rendering with the <object> tag is quite slow and not as clean as using the img tag for images so I was wondering if there's a way to make it work through the <img> tag.
At first I thought it doesn't work because of a same origin policy, but even if the referenced image is in the same directory and I reference it through its name only, it wont load.
Any ideas?
Are you using IE? IE doesnt recognize SVG anyway. Microsoft is always ten years behind, yet they are more popular and far more costly, for some reason. Name brand propaganda?
SVG loads in Firefox. Both as an XML document referenced directly in the URL, and also if you embed it into an XHTML (fully XML compliant) document with proper namespacing, the SVG should render properly. The great thing about this option is that DHTML can manipulate your SVG. Everything I said in this paragraph also applies to MathML, if youre curious.
Aside from that, SVG doesn't load from an image tag. I do believe Firefox is working on this upgrade, though. Im not entirely sure.
Using the object or embed tag is reasonable, I suppose... but one of my earlier fixes was to use an iframe. Embed an iframe in your html that references the complete SVG file. Using CSS you can make the iframe look flush with the rest of your document, appearing and acting like an image. Encased in a div or span tag, you can have onhover and onclick event handlers.
Using the image tag, your src can be a PHP file on server side. If properly coded and with the appropriate cgi apps, you can rasterize your SVG on server-side, and have that PNG data sent back to your image via the PHP src.
There's no particular reason <object> should be any slower to load than <img> apart from possibly the interaction aspect (img's are static while object's are fully interactive documents). The images inside the svg should load in both scenarios, so it sounds like a bug in the browser.
Could you post a link to your example?
I think you are at least 10 months behind...IE9 supports SVG, and pre-release versions (including a beta) have been out for quite a while. Check out www.ietestdrive.com to grab the platform preview - it's pretty good. In my opinion, parts of their SVG support are much better than Firefox currently (but they don't support SMIL yet).