UPDTATE
Since Apple are $2 trillion company let's try and get them to fix this by submitting a bug report here: https://www.apple.com/feedback/safari.html
https://discussions.apple.com/thread/251753724?answerId=253364840022&page=1
In Chrome and Firefox there are no issues but here is the issue in safari:
its supposed to look like in chrome:
If I add fixed style="position: fixed" to the outer div then they position correct, but ther size is still the smaller one in safari.
I tried adding Body to the root of an object but that just made them disappear completely from Safari. Also this post mentions it:
Safari is not respecting scaling applied to a foreignObject
You can see very clearly hear that safari (new ie) does not respect the scaling
Related
I'm using the foreignObject tag inside an SVG, which is working on Chrome, however, it isn't working on Safari. I have gone through about 20 solutions, but the issue persists.
One of the solutions was a user mistyping foreignObject, they instead wrote it as foreignobject (lowercase "O").
In my code, foreignObject is spelled with the correct casing, however, in Safari's devtools, I notice that the tag is spelled foreignobject!
(Below, Safari devtools screenshot, and my code screenshot)
I'm sure this is what is causing the issue I'm having, but it makes no sense, since I have it written correctly in the code, but it's misread when Safari builds the site.
Is there any precedence for something like this? What can I do to change this misreading of my element tag name?
The problem is that you are setting the xmlns attribute of your <foreignObject> to the XHTML name-space. Safari will thus consider it an HTML element when the SVG document is served as a standalone (if it was served inline in an HTML document, then they'd discard it.
This attribute must be set on the top HTML element, that is on the <foreignObject> content:
<foreignObject
requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"
width="300"
height="100"
>
<html-elem xmlns="http://www.w3.org/1999/xhtml">...
(Note that when served inline in an HTML document, Safari's web-dev tools will also show this element lower-cased, even though it will work correctly).
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 am having issues with inconsistent SVG rendering of what seems to be a basic file between browsers. I need to find a way to make this SVG cross-browser, but can't seem to pinpoint the problem. Firefox 23 and Inkscape issues go away if the stop-color statements for the gradients are moved from the CSS to style = style="stop-color:#XXXXXX". Sadly, this is not an option because of the way this file will be used. This file validates on the W3C validator, and seems to only use simple features, but rendering is inconsistent. What is wrong?
I am not allowed to post images yet, so here is a link to an image showing the problem:
http://www.flickr.com/photos/95652985#N07/9754841655/lightbox/
SVG Source is here:
https://dl.dropboxusercontent.com/u/11366066/fire.svg
Thanks for help with this baffling problem!
I think your coordinates x1,y1, etc (for instance
<linearGradient id="id1" gradientUnits="userSpaceOnUse" xlink:href="#id0"
x1="32093.5" y1="4749.35" x2="37189.8" y2="4749.35">
)
could exceed the user space bounding box, thus got wrapped in Chrome, and clipped in Firefox, etc (also my Ubuntu SVG viewer get the same results as Firefox).
A bit of philosophy: SVG, like HTML, is required to be tolerant in rendering, then is common to have different behaviours where the 'simpler' specification is extendend (actually SVG is far from simple)
Edit: my SVG viewer reports as dimensions: 4252 x 2835 pixels 74,2 kB 34 %. Even if we multiply 4252 * 3 we are far below the x1,x2 values....
I am using a drop shadow filter inside an SVG file that is embedded using an img tag. On my MacBook, it looks fine in Safari. However, in mobile Safari, the graphic gets really pixelated and loses all it's sharpness. When the filter is not applied, the SVG renders fine. Is there any way to fix that besides to pass on the filter?
This problem is still relevant in 2018, and I've found a solution. You can duplicate the element you give the filter to, place it below the actual element, and keep filter only on it, without any filter on the element. This way, Safari and other browsers will only rasterise the element with the shadow when resizing, however it will be hidden by the sharp-looking vector element. You can see examples and read more here.
Unfortunately I tried all the suggested workarounds for this, none of them worked, the only thing that worked for me was putting the svg inline, not as an img tag.
Surprised this issue appears to have been around for so long!
You should try explicitly setting the "filterRes" attribute of the filter to a value that matches retina displays.
It's 2021 and it's still relevant. I found a workaround that worked for me: You can enlarge the svg and then use a css-transform to scale it back:
.section_logo img {
height: 500%;
transform-origin: top left;
transform: scale(0.2);
}
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?