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/
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.
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.
If you look at this example in a webkit browser, chrome, safari
http://freemotive.co.uk/dev/exp2.html
the overflow: hidden set on the span element doesn't seem to work when positioned absolutely.
The general idea is that the span element will hide the image within a circle using border radius.
i've read that it is a bug within webkit, however i'm wondering if there is a work around to solve the issue?
i've played with ideas, but nothing has worked yet.
hope some of you can help.
If I understand you correctly, you're basically trying to "frame" the image within a circle by using a span with border-radius and overflow:hidden... why not try applying the border-radius to the image element itself?
So I want a page that's nothing but a square image which scales up to the height of the window. Fine, great, I do:
img
{
max-height:100%;
height:100%;
width:auto;
}
and stick an in a center-aligned div. Firefox loves it, but insists on the height:100%. Chrome doesn't need that, but adds a little bit of height to the page and so a scrollbar pops up. The whole page itself is still rendering identically down to the last pixel, but Chrome seems to think its window is a little heightier than it actually is. What's going on?
Check the margin and padding on the html and body elements -- often a hidden source of pain!
Yes, I know this was in my comment, but this way the question looks answered :-)
In my application I have a row of buttons (for BBcode) that is included in various places. Each button is an empty div with fixed dimensions, a background image and an onclick handler. This has worked very well in all browsers - so far.
Now I have added one more instance of this row, but this time it is inside an absolutely positioned pop-up div. (At least that's the one notable difference that I can think of, because otherwise it's the exact same code.) This also works in all browsers except for IE8, where clicking the buttons does not do anything. Unless I switch on compatibility mode, in which case it works pretty much fine.
Isn't there any other way to make Internet Explorer behave like it should?
I had the same problem in IE8. The transparent areas in the DIVs were not clickable. An easy solution is to set the background-image to a transparent .gif.
My solution in CSS:
background-image: url("images/pixel.gif");
...where pixel.gif is a 1x1 transparent image.
I've found the solution. It was the "float:left" attribute on the buttons that made it fail.
Which is rather strange because in all the other places where this code was included, it also had the float - and it worked. Even in IE8.
Anyway, removing it and using "display:inline-block" for the placement did the trick.