I've run into some SVG rendering bugs in all browsers except Chrome. The SVGs are all embedded in the HTML file, which is supported by all current browsers. However, most browsers get the colors wrong (which are just standard hex colors), while others fail to render some at all (and others just fine). Here's the source file and screenshots: http://awesomegeek.com/bugreport/bugreport.zip See for yourself and let me know if you can replicate it or come up with a solution.
I'm afraid your html file is invalid. You've got multiple elements with the same id e.g. linearGradient id="a". I know they occur in different svg fragments but you still can't do that, all Ids must be globally unique in the file. I think Firefox is drawing the icons correctly by picking out the first one of these in the file as a whole.
Related
I have a new website with a set of favicon images auto generated from a source file using Real Favicon Generator, and there are:
9 Apple favicons
1 Android favicon
3 named favicons
1 Safari pinned SVG
1 json manifest
1 set of Microsoft tile image/colour
Obviously most of these can be placed for their respective vendors - Apple, Microsoft tiles, etc.
I have an issue in that running the website on Firefox, I want the favicon it uses to change but I do not know which one it actually uses?
I have read this question but the stated answer on here is incorrect and
Firefox and Safari will use the favicon that comes last.
is no longer true.
Obviously it's a time consuming repetition to go through ~15 images to find the one that gets changed on one browser, and I actually found that Firefox 42 selects the 96x96 dimension favicon, rather than the last one presented.
Question:
Is there a way [aside from trial and error] to load a page and then find a declaration in the browser defining which image from the HTML head is used as the page favicon in that browser?
Additional Information:
There is an incomplete reference list here. However, this misses out various versions and various OS, and I can only assume these details where found from trial and error.
While this is useful, the various links and solutions on that question give a single URL result for an automated process, such as
http://www.google.com/s2/favicons?domain=www.domain.com
Which works fine in returning a valid favicon but it does not return the favicon that my browser uses when I tested it.
Other links from that question are similar, most only returned a 16x16 favicon and many clearly did not return the image used. Some probably didn't return the image used... it is hard to differentiate 16x16px sometimes!
You can use the Compatibility test of RealFaviconGenerator. The test will ask you which icon you see. But there is a twist: the test is not really for the end-user, so you will have to right-click the image corresponding to the icon you see, inspect it, and look at the alt attribute of the img tag. But that will prevent you from playing with 20+ images to make them different. Much easier!
Full disclosure: I'm the author of RealFaviconGenerator.
Note: I would be interested in your investigations to fix the answer you mention (I'm his author).
Using the Inspect Element, or just Inspect tool, available in Firefox and Chromium. The Network tab shows all http operations related to reload. Filtering by 'favicon' most likely peeks the correct operation, when the page is reloaded.
The fact that the browser downloads an image is a strong hint of what gets displayed. Yet, doubts can persist, e.g. which part of an .ICO. Unfortunately, the tab is a computed element not visible in the (computed) page source.
On Firefox, the iconuri is visible in the json code of exported bookmarks.
I've got a font for a website that I'm loading via #font-face. However, in Safari, it shows up at different weights on different pages, even though inspector shows all styles to be identical.
I've tried setting the font-weights (and anything else I can think of) explicitly, but nothing seems to affect it.
You can see for yourself the variation below:
Has anyone seen this before? or know how to fix it?
Try using -webkit-font-smoothing:antialiased;. This will force safari rendering method then safari will render the font using this method only, instead of automatically switching it.
I had this problem one time, when I implemented a CSS-only slideshow, and the site title rendered bolder when a specific image was shown.
Be aware of that some texts will look bad with this.
I'm having a SVG file that's around 6300 lines long. Opening this file as .svg in Chrome works just fine. But as soon as I use it inline in an HTML file via the <object> tag only half the elements are drawn.
With Chrome's "analyze element" option I see, that the source for the embedded SVG is cut off.
I also tried Firefox, but here the SVG is as empty as before, with the only difference, that the missing elements are drawn underneath in strange positions.
If I open the SVG as external data via <object data=""> it works fine, but that is not a viable option, since my scripts are not properly working that way.
Because the SVG contains confidential data I can't link it here. I hope someone can help me.
Are you sure there is not a parsing problem with the file that is only happening when it is inlined? SVG renderers will generally stop rendering when they encounter the problem.
I would start by trying to locate the element it stops at. Then look for any oddities.
I've spent eons diving into #font-face issues for RTL languages, font-rendering on different browsers, PDF support, and so on.
My objective is to have CSS-compatible Arabic (a RTL language) text on an HTML document, which , when rendered into a PDF, looks, renders, and wraps exactly the same on the PDF as it did on the HTML webpage, regardless of the user's browser or platform.
I've been using #font-face but it turned out that Windows machines render fonts a little wider than they do on a Mac, while the PDF generator is browser-independent and seems to render fonts more like a Mac does. So what happens is that Windows users see one line of text, while the PDF ends up having the last word on that line wrapped over onto the next line, and so the PDF is not exactly what the Windows user expected it to be.
I thought at one point that Cufon could be the solution because apparently it looks the same cross-browser - but I think it doesn't support Arabic? I tried generation PDFs using wkhtmltodpf and PhantomJS, but despite being awesome 'virtual' browsers, both use Webkit QT, which renders text differently from Windows, so once again the PDF that was generated had line wraps or text width that wasn't the same as the original HTML document. Basically, my question is:
What's the best way to ensure that whatever the text the user sees on their browser is exactly what they will see on the PDF? I don't really need it to be exactly pixel-perfect, as long as the text at least follows the same line wraps, with a given width for the containing div. I think the only thing I really need to make sure of is that font hinting is uniform. Or does it all come down to using images?
On an aside, does HTML5 have some sort of cross-browser font-rendering?
I can suggest you two things:
Use em´s for the size of your fonts. em´s are a relative measure.
Don´t use sIFR or anything based on flash rendering due that it won´t work on mobile devices that doesn´t support flash.
There is no way to render the exact same thing across all existing web browsers, that will be like being in heaven. But as we are not there, what I suggest you too is to reduce a little bit the font until it fits your goal.
Regards.
I have a HTML file with inline SVG, which in turn refers to SVG elements in external SVG file with library elements. It uses a <use> elements with xlink:href="Library.svg#libraryShapeID". It works as a breeze in Opera and Firefox, but doesn't work in Safari. I've made a simple test file here:
http://sasq.comyr.com/Stuff/SVG/test01.html
Is it some browser bug or am I doing something wrong?
How should I rewrite it to make it work in Safari too?
There was a bug about this on Webkit but it has been fixed for the Version: 420+ BUT the bug for Fragment identifier is still not solved.
Someone gave an answer: Importing external SVG (with WebKit) using XMLHttpRequest. Quite unfortunate but in the meantime, I guess working.
I realize that this is an old question. But as this method of using SVGs has become more popular these days, I wrote a polyfill to make this technique work in browsers that fail to load the external SVG by default. At the time of writing this, IE9+ doesn't support referencing external SVGs in use elements. The polyfill that I wrote is quite simple and lightweight; it detects whether the SVG has failed to load and if so, sends a GET request to fetch it. It will then prepend it to body.
I hope you find it useful. I would appreciate any feedback.