I'm trying to inline a svg in my css
background-image: url('data:image/svg+xml;utf8,<?xml ......');
Here is an example with my original SVG, which does work in Chrome but not in FireFox: jsfiddle
To understand the problem I created this DEMO. I've used different SVGs and they work, except the one attached to the #a0 element (this one also doesn't work in Chrome)
Does someone know why FF doesn't render the SVG ?
Your data URI is invalid as it contains # characters which are reserved to indicate the start of a fragment identifier
You need to URL encode the data in order for it to be valid and for Firefox to display it. URL encoding will replace the # character by %23, it may replace other reserved characters depending on which, if any you've used.
Related
I cannot get Chrome on OSX to print emoji, is there any css trick or other?
Here are 2 emoji: 👍🇦🇹
When I try to print this page, the emoji space is preserved, but it's white. In Safari printing the emoji works just fine.
Here is a screenshot of the print preview of this page on Chrome:
After a lot of dialog in the question's comments, it seems you have a font rendering issue (perhaps a Chrome bug). I do not think this can be solved with any combination of HTML, CSS, or Javascript.
There is, however, the option to work around the issue by not using a font.
You can use a vector image like SVG to have the same kind of scaling capabilities as a font:
SVG for đź‘ŤTHUMBS UP SIGN Unicode character
SVG for 🇦 REGIONAL INDICATOR SYMBOL LETTER A Unicode character
SVG for 🇹 REGIONAL INDICATOR SYMBOL LETTER T Unicode character
SVG for Thumbs up sign
SVG for Austrian flag
Just link to the SVG as an image and specify its dimensions either in HTML or in CSS as needed.
With a little work, you could automate conversion of user-generated emojis to images by using a dictionary of known images and supplement the misses with the either the SVG or the emoji PNG at FileFormat.Info. They have a list of emojis you could scrape (assuming it's not a violation of their terms of service) for PNGs as well as an SVG for every character (emoji or otherwise) which can be obtained from from just the character code. For example, here's U+1f44d (đź‘Ť):
http://www.fileformat.info/info/unicode/char/1f44d
It'll be the only SVG link on the page, so you could do this in JS:
var svg_src = fileformat_info.querySelector('a[href$=".svg"]').href;
That said, it'd be vastly preferable to have this ready-made rather than creating from scratch. #pandawan's answer suggesting twemoji looks promising.
Perhaps there is a CSS-only workaround: I've also read elsewhere that you can properly print these characters by avoiding bold (and perhaps all font and text manipulation? perhaps just make the font size bigger?). This may depend on the fonts installed on the client system.
This is due to a rendering difference between Chrome and Safari, I would not named it a bug since I do not believe that the expect behavior is defined anywhere (Firefox has issues rendering your emojis too by the way).
If you want a full and simple emoji support across all platforms you can use twemoji, a small library developed by Twitter for this specific need.
My site acro.batcave.net shows up differently on IE (Windows 7, IE 11.x) and FF (Windows 7, FF 37.x). Chrome has the same behavior as FF. The CSS is located at acro.batcave.net/css/index.css. Initially I thought I might have used non-standard CSS (the intent is to use CSS3). But I did not find any using the CSS validator at W3C. What am I doing wrong and how do I make FF (and Chrome) to display this similar to IE?
I don't know how that's happening but when your site loads in Chrome the CSS returned is all gibberish. That's why its not getting applied.
Check out the screenshot below:
http://screencast.com/t/tCYGkUnAxO
You have saved the HTML code as UTF-16 with a byte order mark, and I suspect that you have saved the CSS code the same way. Firefox and Chrome fail to decode the CSS file to text because of the encoding.
Most browsers doesn't support UTF-16 for data files unless you specify it in the link tag or the header. Instead save the files (the HTML too) as UTF-8, without a byte order mark.
link
In chrome, it is working perfect. However, in Firefox, the images do not appear.
I have set the SVG's mime type, and mime type checkers are displaying that the mime type is correct.
Could someone help me out?
It's because you're using the new shorthand notation for filter effects on html elements (as defined here), in Firefox you'll have to use the url(#...) notation for filters (also part of the same spec, and of SVG 1.1 where it's been working for a long time).
If you want to see how to do a grayscale filter that works in most browsers see here, and if you want to read about how you make it apply to some html see e.g here.
It's probably just a syntax error but I can't find any thorough references on this kind of usage. Chrome is overstriking my background property, so I've obviously offended something.
http://jsfiddle.net/YbA39/2/
I want what's in the red box (an svg css background) to render just like the inline svg in the html. Simple, right?
Don't say it can't be done! My inspiration is this: http://jsfiddle.net/estelle/SJjJb/
You haven't escaped the '#' characters in the url() syntax. And it's 'viewBox' not 'viewbox'.
Here's something that works: http://jsfiddle.net/YbA39/3/ (just a quick urlescaped string).
The newlines in the declaration were breaking it. Removing all the newlines fixes it in all but IE, which requires base64 or URI encoding:
http://jsfiddle.net/YbA39/4/
Playing around with shjs in order to display line numbers, line breaks and spaces, i came across this: Using Pseudo-Elements for the ›hidden‹ characters it behaves just as expected (in Firefox): no line numbers, spaces or line endings get copied to clipboard.
As IE8 displays everything well, I was surprised it behaves different with copy+paste.
Copy+pasting a line from FF looks like so (which is fine):
config = ({
While the same, copied from IE8 reads:
14·config· =· ({¶
The same with Opera, btw.
Does anyone know which behaviour is the correct one, and if there is a way to teach the browser the desired behaviour?
Thanks in advance
Opera and IE are correct: There is no rule which forbids copying generated content. Mozilla’s behavior is btw one of the many reasons why you can’t use the <q> element …
Unfortunately, you can’t bring all browsers in line. Generated content is not part of the DOM and therefor not accessible per Javascript.