Having issues getting specific background images to display in Firefox/Opera, all other browsers are playing ball (except obviously IE, for which I've had to compromise).
Currently, Opera won't allow multiple background images like so:
background-image: url('/images/h2_default_bg.png'), url('/images/dashed_bg_default.gif');
background-repeat: no-repeat, repeat-x;
background-position: top left, bottom left;
Also both Firefox and Opera are both being awkward when a background image is positioned in pixels:
background: url('/assets/images/dashed_bg.gif') bottom 2px repeat-x;
Are there any simple workarounds for either of these problems?
Multiple backgrounds are only supported starting from Firefox 3.6 and Opera 10.5. Are those the versions you're testing in? Chrome and Safari already support them, which I presume you mean with "all other browsers ... except obviously IE"
As for your second problem, the spec says this about the background-position syntax:
If two values are given and at least one value is not a keyword, then the first value represents the horizontal position (or offset) and the second represents the vertical position (or offset).
So you've given them in the wrong order. Make it 2px bottom instead.
Currently, Opera won't allow multiple background images like so:
Multiple background images like that are not possible in CSS2 / 2.1, which at the moment we still have to adhere to.
See this quirksmode page on which browsers currently support multiple backgrounds.
As for the other settings, background position definitely works across browsers, I'm not aware of any incompatibilies there. What exactly happens in Firefox and Opera?
As you found out, multiple backgrounds works in all the modern browsers. It does work in Opera as of version 10.5. There is no information on whether IE9 will have it nor if/when IE will ever support it.
Related
I've spotted some weird behavior across browsers border-radius implementation. Take this code: http://jsfiddle.net/pm7FZ/1/ On Windows every browser excerpt Chrome rounds inner image: http://imgur.com/54In8 Chrome doesn't and the image stays square.
I don't have OS X, but my friend send me this: https://img.skitch.com/20120925-eypjk593tdest3ud9hcji1sauf.png Seems it behaves differently. Although another friend says that if you set border-radius to 20px on OS X it will round the image corners on OS X's version of Firefox.
Question - what is happening here? Why so much inconsistency.
It's obviously easy to "fix", just curiosity.
I can only speculate but here's what I suspect is going on. If you check out the W3C spec for the basic box model (http://www.w3.org/TR/2007/WD-css3-box-20070809/) you'll see a graphic that demonstrates how elements are laid out. Each element has a content area, padding, border, and margin areas. I believe browsers render each of these areas as a layer and where FF would render the 'border layer' on top of the content layer Chrome would render the 'content layer' on top of all the other layers. In your sample if you would remove the height and width attributes from your img tag you'll see the image does get rounded but is not affected by the border itself. I haven't found any specification on the way browsers should handle this but I'm pretty sure the Chrome devs chose this method to squeeze out some more performance.
This is best explained with images.
Firefox, right:
Chrome, wrong:
jsfiddle.
That is a (fully green) image with 2px (red) border and a border-radius of 6px. In my design, the border is barely visible, so the image looks completely square in Chrome.
Is it possible to achieve the correct result in Chrome without extra markup nor javascript?
I don't believe you can do this with Chrome. Images will extend over the bounds of border-radius, and I think that's the intended behavior (or else they just didn't notice).
When using a div, for example, you can see that the background behaves as it should. You could consider using a div instead of img, and using your source image as the background (and forcing its width and height).
Plainly said: In Chrome, there does not seem to be a way to force your image to be hidden by the border of itself (or even of its container) unless it is set as a background. In fact, the issue has been asked about before, and blogged about as well (and, in fact, patrickzdb's comment there may help you).
Apparently it is a bug in chrome..
I normally apply box-shadow for chrome instead of border.
so, if you don't mind to apply css hack to workaround it without javascript: http://jsfiddle.net/3cuHU/
I have an element, with a child container which is initially hidden. When I hover over the parent, the child should be displayed. Simple.
Now, for real browsers, I want to add some flair and have the child fade in — while still keeping basic functionality for non-CSS3 compliant browsers. For old browsers, I simply toggle display, while I animate the opacity for all the kids with cool browsers. Should be a simple operation, right?
To my great surprise and disappointment, this is kind of buggy.
In Firefox, when I hover on, the child element switches to being fully opaque, before fading out. But hey, I want it to start as fully transparent, and then fade in!
In Webkit, the animation does not trigger — only the display toggle.
In IE (including IE10 PP) it also simply toggles display (as expected, though I had hoped it would animate in IE10).
In Opera everything works swell. <3 <3
Now, if I remove the display:none; from the initial declaration, the animation works beautifully in Fx, but then I will have problems with uncool browsers, which is sadly predominant among the visitors of this particular project.
Since I possess the powers of Modernizr, I can simply make a conditional style so that I use the display toggle only on the silly browsers, and life is great again, but the question remains:
Is this a bug in Fx/Webkitz, or is it intentional?
Here's a fiddle for you to look at: http://jsfiddle.net/TheNix/q5bAZ/4/
The problem is that transitions happen on computed value changes, and browsers don't compute values for most properties when display: none is set.
There is some ... lively discussion about what the spec should say about this. See the thread starting http://lists.w3.org/Archives/Public/www-style/2011Dec/0353.html and going over the last 4 months or so.
Simply omit the display declaration and add
-moz-opacity: 0.5;
-khtml-opacity: 0.5;
filter: alpha(opacity=x); // x = 0 ... 100.
Now with targeting the IEs and other older browsers, you should be fine.
If you want to be extra-accurate you put the filter into an extra IE-stylesheet so you don't invalidate your stylesheet with stupid IE-stuff. ( But with proprietary prefixes only xD )
I'm using css animations on my page and Safari seems to change unrelated font weights elsewhere on the page when animations are running. Any idea why this happens? All other browsers work fine, include webkit ones like Chrome.
I've detailed the bug in a video here - http://www.screenr.com/gZN8
The site is also here - http://airport-r7.appspot.com/ but it might keep changing rapidly.
I'm using compass (#transition-property, #transition-duration) on the arrow icons. No transitions applied on the heading that's flashing. On a Mac - so it might be the hardware acceleration, but I'm still trying to figure it out.
When you trigger GPU compositing (eg, through CSS animation), the browser sends that element to the GPU, but also anything that would appear on top of that element if its top/left properties were changed. This includes any position:relative elements that appear after the animating one.
The solution is to give the animating element position:relative and a z-index that puts it above everything else. That way you get your animation but keep the (superior IMO) sub-pixel font rendering on unrelated elements.
Here's a demo of the problem and solution http://www.youtube.com/watch?v=9Woaz-cKPCE&hd=1
Update: Newer versions of Chrome retain sub-pixel antialiasing on GPU composited elements as long as the element has no transparency, eg has a background with no transparent or semi-transparent pixels. Note that things like border-radius introduce semi-transparent pixels.
Apparently, that's the price you pay for hardware acceleration: all text momentarily turns into images, which causes the drop in render quality.
However, applying html {-webkit-font-smoothing: antialiased} to turn off the sub-pixel anti-aliasing makes this problem go away. That's what I'm doing for now.
UPDATE: Since then, I've also come to learn that this happens only when the browser can't be sure if the section being animated is going to affect the text. This can usually be handled by having the text above (higher z-index than) the elements being animated, and/or making sure the text has a fully opaque background.
I've faced this issue numerous times and have had success adding the following css to the animated element:
z-index: 60000;
position: relative;
It seems it needs both z-index and position to be effective. In my case I was using it with Font Awesome animated spinners.
I added a box-shadow to a section of a page recently to give it the same shadow border effect that is seen on Mac OS X apps. It looked great, but I noticed that scrolling up and down on the page made it lag. I usually only see this on pages that have annoying background images and tons of images and embedded videos plastered all over (cough MySpace cough). I originally decided to use box-shadow since I figured that it would remove the need to use an image, which would remove any possibility of scroll lag.
I know that CSS3 is still new, but is this the reason for the lag? Is the shadow being software rendered or something? When I apply the box shadow to smaller elements, it doesn't lag at all. I'm just wondering if anyone else has experienced this.
I just tried it on the Stack Overflow front page, on the #content div using Firebug with a setting of:
-moz-box-shadow: 1px 1px 10px;
And I did notice some scroll lag afterwards. I am using Firefox 3.5.
My question is, what are some alternatives to using this attribute if I want to add a Mac OS X style border to a section of my page?
On a side note, does anyone know if it is possible to apply the box shadow only to the top, left, and right sides of the element and not the bottom? I tried 1px -1px 10px but it still shows the shadow on the bottom. If I keep decreasing the second offset, it eventually removes the shadow from the bottom but then the top shadow is now way darker and bigger.
And yes, I have seen the articles on box-shadow at:
CSS3 Info
fredericiana's blog
Your best bet would be to use -moz-border-image instead. That should solve both your issues.
E.g. you could use an image like this,
, combined with CSS like this
-moz-border-image: url(shadow.png) 10 / 10px;
to create your shadow. And since you're using an image, you can leave out the bottom shadow as well, if you want.
You're not going to be able to remove the shadow from the bottom using -moz-box-shadow; it's not called "box shadow" for nothing. It applies a shadow to the entire box. You can't specify a shadow for each side separately like with border, say. The best you could do is fiddle around with the placement, blur and spread of the shadow. But that inevitably leads to a darker shadow on the opposite side.
I get the box shadow lag as well when I try it on Stackoverflow. It affects performance on Safari as well when I try -webkit-box-shadow, though it isn't as noticeable as in Firefox. The performance will hopefully improve in the future, but I presume the shadow will always have some impact since as far as I know it is software rendered.
This has been fixed in webkit as of two days ago. :)
https://bugs.webkit.org/show_bug.cgi?id=22102
You can pick up a chromium nightly to try it out.
I looked in FF3.6 and FF4 and don't see terrible scroll performance there, so it might be addressed there as well.
The issue still persists in Chrome for Android as of the current date. Some box-shadow combos result in a poor scrolling performance. In my case stacking two inset box-shadows (e.g. top / bottom) lead to the described problem. The only solution I can provide is to make the box-shadows less complex and try again...that worked for me. That's unsatisfactory but yeah instead u can also use the border-image solution or remove the affected box-shadow completely. Hope this gets fixed soon, finally. Btw the Android Version of Firefox does not have the problems anymore (for my css3). Moreover the desktop versions of both browsers are not affected in my case.
#shadow {
-moz-border-image: url(img.png) 10 / 10px; #Firefox under v15.0#
-webkit-border-image: url(img.png) 10 / 10px; #Safari, Chrome under v15.0, Android & iOS#
-o-border-image: url(img.png) 10 / 10px; #Opera under v15.0#
border-image: url(img.png) 10 / 10px; #IE v11+, other new Browser#
}
Cross browser version for old and new browser.
Simple img: http://i28.tinypic.com/2njzkt1.png
style :fixed for images too overload perfomance browser