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
Related
i have a problem with image-set property when i use it with an avif file as first option to render in Microsoft Edge. The fallback doesn't work( as you know, Edge doesn't support avif type yet ) and Edge load the avif file even if can't support it. Is there a way to make the fallback works properly??
Note: I am using autoprefixer in my gulp file so it isn't a prefix problem.
.speaker__imagen { background-image: url(../img/bg_1.png); background-image: image-set( url(../img/bg_1.avif) 1x, url(../img/bg_1.webp) 1x, url(../img/bg_1.png) 1x ); }
I want to leave the image-set property without taking off the avif option from the render option's list
The fallback is the "fallback" to image-set/-webkit-image-set, so apparently it does not work if image-set/-webkit-image-set works even though .avif is not supported in Edge. Interestingly, Edge and Chrome share the same prefix -webkit so you'll have to treat them as the same.
Actually, you can use type() to provide alternative image formats, which should work in a more favorable way than background-image: url() as the fallback. However, type() has not been supported on Chrome and Edge yet since in the doc they said :
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.
Additionally, Edge's support for .avif may be on the way because we have a new command line flag --enable-features=msEdgeAVIF on Edge Canary, which means the Dev Team may have been testing the implementation.
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.
I am using the background-color property in CSS media type print.
The problem is that Google Chrome does not show background-color or background-image in print preview.
How can this be solved?
Chrome supports control of background colour / image printing via CSS. You can set the following CSS property on elements whose background should be printed:
-webkit-print-color-adjust: exact;
Normally of course, this is determined by browser settings - but Chrome allows web designers to determine how backgrounds are printed on a per-element basis...
Notes:
Requires Chrome 17 or higher.
The background of the body tag is not printed.
Thanks to Cron’s Web Tech Blog, where I first spotted it:-
http://blog.crondesign.com/2011/11/print-css-backgrounds-in-google-chrome.html
Also, this leads to some background (no pun intended!) info regarding the feature:-
http://code.google.com/p/chromium/issues/detail?id=107763
Hope this helps...
I tried for hours using the ideas suggested but none worked. I needed to use !important
Somehow chrome must be deferring to a different background-color statement.
background-color:red !important
I think the issue is not with your code, but with Chrome: there is no option to print background (images or colors) : see http://www.google.com/support/forum/p/Chrome/thread?tid=17a4ac343580c8d3&hl=en
With Firefox, the background images are not printed by default, but it can be activated in "Print... -> Page setup"
You can try the developer tools in chrome to check which css rules applied in your DOM element. That will help you debug and fix the issue.
Is there a way that I can use the CSS3 'Background-Size' property and then use something like Modernizr to ensure that it's supported in older browsers (in particular I want to use 'background-size: cover' option)?
I took a look at cssFx, which is mentioned from the Modernizr website, but this only seems to add vendor prefixes for browsers which need them to use a property, rather than allowing browsers such as IE8 to support the background size property.
Also looked at CSS3Pie, but that doesn't seem to currently support the background-size property.
[11/10/2011 - By older browsers I'm thinking mainly of IE7/8, but ideally I would like to cover FF3.6, etc.]
You're right that background-size is not supported on a number of older browsers.
The typical solution to this is to simulate it using an additional <div> or even an <img> element positioned behind the element you want to have the background.
This can be achieved simply by using additional markup, but this solution has the disadvantage of meaning that you'll be using it for all browsers, instead of the background-size property. In other words, it means deliberately degrading your code for the sake of old browsers, which is not ideal.
If you want to use the CSS property for browsers that support it, you could use a bit of Javascript to generate the above markup, but only if required. This means that modern browsers can happily use background-size, and only older browsers will use the fallback.
There are a number of Javascript solutions to this available on the web (a quick google turned up the following: http://css-tricks.com/766-how-to-resizeable-background-image/ among others), but more importantly you need to know how to trigger it based on the browser.
This is where Modernizr comes in. The description you've given of Modernizr in the question is not entirely accurate. What it does is produce a set of CSS classes in your HTML markup and matching variables in your Javascript that represent all the browser features. These are boolean flags indicating whether the current browser supports.
So with Modernizr you can then check in Javascript whether the browser supports background-size or not, and only run the alternative javascript function if it doesn't support it.
if(!Modernizr.backgroundsize) {
//do stuff here to simulate the background-size property for older browsers.
}
Hope that helps.
You can see support for background-size and its properties at: http://www.standardista.com/css3/css3-background-properties
This CSS supports IE9+, FireFox 3.6+, Safari, Chrome:
background-size: cover;
-moz-background-size: cover;
For IE7/8 support, caniuse.com lists this polyfill: https://github.com/louisremi/background-size-polyfill
First of all there is an easy fix for Firefox 3.6. There is a vendor prefix:
-moz-background-size
With regard a solution when using media queries: You could use Modernizr to target another image for when users are viewing older browsers, this would mean another browser request. However, presumably you will be loading smaller images for each query where the screen size gets smaller. Because Modernizr will create a situation where these requests will be ignored in newer browsers you will cut down on server requests for the majority of people using newer browsers.
Out of curiosity, I tried the above solution and it worked. I applied the following modernizr classes as: .no-backgroundsize for non background-size supporting ie and loaded in a new image.
For all other browsers I added the class .backgroundsize and included the prefix mention at the top for FF. This could be repeated for each media query with a new image for .no-background. This is one way to solve the problem.
-I edited this post after I tried it 12/15/12.
I think you probably want to use modernizr to check whether or not the property is supported in the current browser. If not, try to figure out an alternative display of your site/application that still looks good without the need of the background-size property.
Of course, you can also try another approach that does not involve this property at all like an underlying div with a picture in it (which you can size) and the content that is overlapping this div. Good luck.
Another option would be Background Size Polyfill:
.selector {
background-size: cover;
/* The url is relative to the document, not to the css file! */
/* Prefer absolute urls to avoid confusion. */
-ms-behavior: url(/backgroundsize.min.htc);
}
Best sample to support better:
background-image: url(bg-image.png);
-webkit-background-size: 100% 100%; /* Safari 3.0 - Old Chrome - Old Android */
-moz-background-size: 100% 100%; /* Gecko 1.9.2 (Firefox 3.6) */
-o-background-size: 100% 100%; /* Opera 9.5 */
background-size: 100% 100%; /* Gecko 2.0 (Firefox 4.0) and other CSS3-compliant browsers */
Don't add this, because it made problem in new firefox versions:
-moz-border-image: url(bg-image.png) 0; /* Gecko 1.9.1 (Firefox 3.5)
Source: mozilla.org
I'm using Chris Pederick's Firefox addon "Web Developer 1.1.6". I get this warning when hitting a certain web page on my site:
Unknown property 'MozOpacity'. Declaration dropped.
What does this mean and how can I fix this on my site?
It's customary for browsers to prefix experimental or proprietary features with -moz (for Gecko-based browsers) or -webkit (for webkit) so they can be used but don't interfere with standard CSS rendering. In the case of -moz-opacity, it seems that they have finally removed the proprietary tag since the standard opacity tag is supported.
I don't think any equivalent convention is followed by the IE team, but then again IE is so behind the pack it probably never came up ;)
Are you using mozopacity in your CSS stylesheet? This might be spelled wrong and is thus triggering an error.
You might be looking for -moz-opacity which has been dropped as of Firefox 3.0.
It might not be an issue with your site. Some browser plugins - for instance, Firebug or Web Developer - often add extra styles dynamically to the page for debugging purposes; I've noticed the unofficial -moz-* styles pop up in my own Firefox debugging.
However, this isn't necessarily a problem with your page; it could be a problem that your user agent is first creating itself, and then assuming later that there's a problem with your page.
First, I suggest trying to disable your Firefox plugins and seeing if you still get aforementioned error. Then, make sure your plugins are up-to-date - especially any development/debugging type ones that might be manipulating the DOM after pageload.
there is some proprietary css declaration :
- filter (from microsoft);
- -moz-corner-radius, -moz-opacity and other -moz prefixed from mozilla
- -khtml prefixed from safari
these are NOT standard and it works ONLY in that browser.
If you don't expect -moz properties to work on safari and filter on firefox, you can ignore that warnings :)