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.
Related
I want to use .avif and .webp for images on my website, remembering that I need provide fallback for unsupported browsers. Docs https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set()#using_image-set_to_provide_alternative_formats suggest that -webkit-image-set should help:
background-image: url("/public/header-fallback.jpg");
background-image: -webkit-image-set(url('/public/header.avif') type('image/avif'), url('/public/header.webp') type('image/webp'), url('/public/header.jpg') type('image/jpeg'));
This works in Firefox (avif is skipped and webp is used) but Chrome gives me Invalid property value (entire style is ignored and 'header-fallback.jpg' is used). Why?
It's seems that chrome not fully supports image-set
our implementation has not been per the spec, as only URL values were accepted for the image, and only resolutions with 'x' as a unit were accepted.
source
To make it work with chrome try remove the type and add 1x instead
url('https://url.avif') 1x
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.
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.
I have a custom cursor that is using an image. My original code:
cursor:url(../images/drag_mini_bg.png);
I then discovered that Firefox requires you to define a default backup in case the image is not found, and changed it to:
cursor:url(../images/drag_mini_bg.png), default;
This worked for Firefox and Chrome, but not IE. I read that IE uses a different source for the path than other browsers and implemented this solution:
cursor:url(../images/drag_mini_bg.png),url(/images/drag_mini_bg.png),default;
(The second url is relative to the html file rather than the css file that this code is included in.)
This didn't seem to help, so I found out about this bug and changed the image to a .cur file:
cursor:url(../images/drag_mini_bg.cur),url(/images/drag_mini_bg.cur),default;
However, it is still not showing up in IE. Anything else I can try?
Most of what you've read is correct, but I'll make a few amendments:
Firefox does indeed require the additional parameter to be added. My understanding is that the ideal value for this is auto. But if default works for you, use it.
As you've been told, IE can only display cursors of the .cur file type. PNGs and GIFs do not work.
However, I've never heard anything about IE using a different path; the same path has always worked fine for me in all browsers (when using a CUR file, of course). You might want to provide a reference to where you heard this, but I'd suggest that dropping the second URL may solve your problems.
There's a good site called Quirksmode that has a lot of browser compatibility tables. In particular, they have a very thorough table covering CSS cursors, which shows exactly how to format it to make it work in all browsers, with examples and notes about the quirks.
Hope that helps.
If you're still trying to figure this out 8 years later...I'll add that some browsers have a maximum image size, so maybe yours was too big. I believe you want to keep it under 32x32 pixels.
basically a majority of the CSS styles defined for my website are not displayed when opening the page in IE8. This is not only happening for my custom styles (which I load separately through a custom css file), but also for the built-in features of Rockettheme IONOSPHERE template, for example the box1/2/3/4/5/6 module styles. Also, the rounded style is not rendered, and all modules are shown with sharp corners instead.
I am also using a custom css file (called ralph_golfanatics.css), which I load inside the index.php as follows:
$gantry->addStyles(array('template.css','joomla.css', 'ralph_golfanatics.css'));
All custom styles of this file are displayed fine in IE9, but the most important styles are not shown in IE8. Simply adding these css-styles manually in the file template_ie8.css (that file comes with the Ionosphere template package) did not change anything.
Looking forward to receive any help in this matter. The webpage is http://www.golfanatics.de
Thank you all in advance for your hints.
Ralph
Unfortunately, the link you've included isn't working so it's difficult to pin down exactly what the problem is.
If you're referring to rounded borders displaying with sharp corners this is because border-radius is a CSS3 property which is not supported in IE8.
See this link for border-radius browser support.
There are many CSS3 properties which don't work in older browsers; this is expected behavior and most web developers work around this by using either 'progressive enhancement' or 'graceful degradation'. See this link for more information.
Most websites using CSS3 techniques will never look the same in every browser.