I am on a team trying to convert our Flash Application into HTML5 and Css, and I am running into a bug affecting WebKit and wanted some help trying to figure it out. The basic idea is that there is a table with a single cell with a background image and a background color and for whatever reason when the image is exactly the right size background-size: 100% 100% the image actually shrinks to reveal the background color. This also repeats if I use pixel values instead of % values.
Before anyone tells me to just use a div (since its only one cell anyway), this content is authored by other people who are using an existing tool to create a custom xml document that gives us tables and I have to get my solution to work on the pre-existing content we already have.
This is the fiddle which shows it and follows are image in various browsers:
http://jsfiddle.net/CEvnx/2/
Flash (Reference)
Firefox (working)
Chrome (the image shrinks)
Safari (the image grows)
P.S. Ignore the height and font differences as those aren't in any way relevant to the problem.
has to do with the table's border-width, if you set border-width at 2px or less the background sizes correct (in Chrome/Safari). Quite strange that Chrome shrinks and Safari grows. There must be some odd math or image resize logic in webkit and probably worth submitting a bug report.
Related
Google Chrome always seems to be changing the color of an image that I'm trying to match to a background color. I tried saving it in Photoshop and GIMP and even adjusted the color settings in each but it doesn't help in Chrome. FF and IE work fine (for once).
The color of my image is #282828. After I saved it as a PNG, I reopened it in both GIMP and Photoshop and used the eyedropper tool to confirm that the color was still #282828. When it renders in Chrome it's darker. I have a div with a background color of #282828, and the image is right next to it. I took a screen shot and the div's background color was #282828 and the images background color was #1d1d1d. I tried this for several different colors and each has had the same result. I even tried making the source image the color Chrome was rendering it as but Chrome still changes it. So for example, since Chrome was changing #282828 to #1d1d1d, I made the source image #1d1d1d, and when I rendered it in Chrome it was not #1d1d1d, but some other darker color.
At this point, I'm looking for either a fix or a programmatic work-around. Because the image is transparent, has curves, and a drop-shadow, there's really no way for me to avoid replacing the it, or even parts of it, with html.
Update:
I also tried saving it as a jpg and gif. gif actually works but can't preserve the drop shadow. The image I'm using is attached. If I take a screenshot of this in Chrome, GIMP's eyedropper tool says it's #1d1d1d. If I open the original and do the same, it's #282828.
PNG uses gamma correction to try to ensure that the image looks kinda the same across all monitors, and this can cause color mismatches like the one you're seeing. It's a combination of image editor issues and browser issues: image editors are not forced to embed gamma data inside images, and browsers are free to ignore the gamma correction if it's there and free to enforce some at random when it's not there. In this case, I'd rather think that Firefox ignores it.
Use a transparent PNG if you don't want its background to interfere with your page's background.
[EDIT] For your specific case, you may be able to replicate the graphics you're looking for by styling elements, using border-radius and box-shadow, two widely-implemented CSS3 properties that reasonably decay on older browsers.
I am using html5 and am trying to create a rough edged seamless border(top, sides + bottom).
I am aware ie8 does not support the CSS3 border image. IE8 is as far back as am willing to cater for.
So am using 3 div's to have the background image display, the only problem is depending on the length of the content, the bottom background image does not align nicely and make the box appear seamless, due to the repeated middle image being cut off prior to the point where the border merges.
I have used a brush in photoshop to create the jagged container. I have had a nose around about this but can not find a solution to fit.
The solution is to set a specific increase of height increment for your content area. This can be done in a couple of ways:
If your content is mostly text, you can set your line-height and/or the height of any other used elements to be the desired increment (or a multiple thereof) and hope for the best.
If this will not work, the only other way would be to use JavaScript.
Here are a couple discussions of this very challenge, including some thoughts on using line height and some starts at workable JavaScript code:
http://doctype.com/any-way-increase-hieght-div-specific-increment
http://www.dynamicdrive.com/forums/showthread.php?t=64034
I'm wondering if this is something somewhat simple, but I'm having a problem ONLY on iPad with my sprited images. I have an tag that I use a sprite for to display an image of a star (similar to gmail or picasa) to indicate a favorite. On every other browser (including safari) on a computer, it's all completely fine.
The problem is on an iPad, it's showing more of the sprite than it should and it looks strange. What's even stranger is that this image is repeated several times and it doesn't seem to happen consistently.
Is this some sort of zoom issue or viewport setting problem specifically for iPad? It's driving me crazy, and anything I do to fix it cuts off some of the image and ruins the normal browser look.
Here's an example of what I mean since I can't put up the page I'm currently working on.
On this site I've worked on in the past, the viewing options look strange on an iPad:
http://demo.qlikview.com/index.aspx?section=Life
For example the "Download" viewing option looks different on the FEMA app than on the Kick It app so it doesn't even appear to be consistent.
Any help would be appreciated.
Thanks!
This is because the iPad scales your page.
The size of your element where the sprite is used is scaled and the sprite image to. But it seems not to behave precisely.
The same thing happens when you zoom out in safari. This is because an image is not scaled the same way in the browser then a dom element. A dom element is rendered as vector object. So when you zoom in or out, the lines keep sharp. When you do the same with a bitmap. It gets blurry and the browser need to guess how the image would look like smaller or bigger.
You have two options:
use more space between the sprites.
use EMs and not Pixels in your CSS
PS: Don't use !important in your css
Like meo pointed out, best option would be to leave space between the sprites.
There is also one last thing you can do, which is not to let the user zoom the web page by putting the following line in your tag. It would look the exact same as you view in the browser, which is pretty neat if you have loads of elements messed up in the iPad because of the sprite issue.
<meta name="viewport" content="minimum-scale=1.0, maximum-scale=1.0" />
Good luck!
The simplest fix for this is to put an outline around your spite with the border color the same as the parent container's background color. The outline is outside you element and does not effect layout. What you see is a problem mobile Webkit has when it scales down images with background color or background images, they bleed out of their container. The outline will sit on top of that and cover it.
What I usually do is just define separate images (non-sprited) for iPad users. I know it doesn't load as quickly as you're hoping for with sprited images, but I feel it's a price they have to pay. What I do is have individual images on the server with #media in your stylesheet to define different images for iPad browsers. A quick review of how to use #media for iPad can be found at:
http://css-tricks.com/snippets/css/ipad-specific-css/
I just ran into this problem as well. I've been leaving extra space between my sprites since I first noticed the iPad imperfections. However, my current project involved sprites and another element with CSS3 transforms. The combination made the sprites blurry, with strange clipping around the edges. I actually found a fix over at No more jagged edges in iOS. Try applying the following CSS to your sprites:
/* IOS fix for incorrectly scaled sprites */
-webkit-background-clip:padding-box;
background-clip:padding-box;
Those few lines worked magic in my project. Of course, YMMV.
I have a conceptual question about photo galleries like this:
http://www.nikesh.me/demo/image-hover.html
If you open this in a browser that supports CSS Transitions (for example Chrome), it will smoothly scale the hovered image whilst the zoomed version remains of a high quality.
This is accomplished by showing the non-zoomed images into a slightly smaller version than they really are, in essence the zoom shows them in their true dimensions.
So, normal images are first scaled down:
-webkit-transform:scale(0.8);
And then upon hover scaled up:
-webkit-transform:scale(1.2);
My question: How is the initial scaling down supposed to work for browsers that do not support this method of scaling down? Try opening that gallery in IE to see what I mean, it shows the images not scaled down, which makes them too large and thereby they break the layout.
What I want:
The full effect in browsers that support it. Important is that the zoomed version remains quality.
No effect at all for browsers that do not support it, yet a solid original dimension so that no layout is broken
It should work for both image orientations and there may be variety in image widths and heights too
Anyone? Preferably an elegant solution that does not need browser sniffing or javascript, but all answers are welcome.
If you are wanting it to work without the use of javascript then it seems the only method you have is to forgo the initial scale down with css. You will want to do this in the "antiquated" way of adjusting the width and height of the image in the markup.
<img src="yourImageSrc" width="80%" height="80%">
This would allow you to still keep your layout in tact if the user agent is not up to date.
** I don't know if the percentage works in the literal height/width definition. But you can always figure out the ratio you need and plug it in.
Written pages, why in the ie6 png images in it will automatically cast a shadow
There are two possible reasons, depending on how it looks.
IE 6 doesn't support transparency for PNG images (unless you use a filter to display the image), so if there is a transparent background in the image it will be replaced with a solid gray.
The PNG format contains a gamma correction value that was intended to solve some color profiling problems, but it actually hurts as much as it helps as images are displayed somewhat differently on different systems. If you have a color in your PNG image that is supposed to match the background of the page, it might be slightly off, which will show the iamge as a square with a slightly different color.
that's one of the many bugs of IE6: wrong rendering of transparent png's.
there are a lot of JS fixes, like this one, but i've never seen one that works perfectly.
some break the clickable elements that have png background, some others change alignment or margis or position