I was trying to create a simple rotating planet with css and javascript. First I tried to put the image as a background, which worked fine in all browsers but the background-position animation had very poor performance in IE and quickly raised RAM usage (50-100 MB increase per second) until the browser crahsed. Then I decided to try using image in the planet div and animate its position which resulted in smooth animation with low memory consumption, but as you can see in the image below the image leaks beyond the border. The planet div has border-radius: 50%.
I've tried adding overflow: hidden to the planet but that didn't work. Is there a way, to prevent the leak from happening other than using some kind of mask?
So to answer my question, css3pie is not able to clip content in IE 7 and 8, therefore it is not possible.
You can only clip images with css3pie if you apply its behaviour on the img tag itself, or if you use the image as a background of a rounded container...
I guess you want the moon to rotate around the vertical (y) axis right? It'd be possible around the z-axis... but css3pie generates images on the fly so if you need to animate the content of a rounded container it'll redraw on every frame. So no solution for that really. Kill IE maybe!?
Related
http://1aproductions.ots-internet3.net
So my wordless theme has a built in slider. It is responsive. The slider is in the background and seems to have a height of 100%. On browsers that are normal width but tall this means that a lot of the image is hidden behind the white background of the content lower down the page. If you resize the page while the slider is on the slide image of the queen you will see why this is a problem. My boss would like it to always show her heard and shoulders.
Is there a way of, on longer shaped browser windows, stopping the image from being 100% height and therefore making it display better on longer height browsers as well as normal shaped ones?
As you can probably tell I'm kind of out of my depth on this one, so any help would be fantastic!
Thanks
Luckily for you there is a quick fix on this particular slider. The elements are set to have a background-attachment of fixed on #slider-container .full-bg-image. Clear it and the whole picture will display. You should then be able to use the background-position to align more specifically for mobile, or only have the fixed position for desktop use with a media query. I'm not sure what method the powers that be would like best :)
While learning how to use css sprites, I quickly noticed and/or read that it is best to have 1 or 2 empty pixel space between all images inside a sprite to avoid other images bleeding through when the user zooms in or out.
While looking at the apple homepage, I noticed that they don't do this, without suffering from bleeding images. I did not find any reason in their css that would explain this.
How is that possible? ;)
There's no need for padding between sprites if you know exactly what size the containing element is going to be. The problem comes from when something inside the element causes it to grow. For example, if the text inside that element has to use a fall-back font it may end up causing the container to grow.
The reason padding between sprites is recommended is that there's no real downside to it. It doesn't increase the file size by any meaningful amount and it gives you a bit of a safety margin when a browser does something slightly different than you expect.
It seems like it is indeed necessary, because when the browser deems it necessary to scale the cropped areas (for example, if one zooms in or out or if an animation temporarily changes the size) the browser will use anti aliasing to smoothen the scaled image. Since anti aliasing uses surrounding pixels, the most outer pixels of a crop will be influenced by those that lie outside of the cropped area.
The transparent padding ensures that this doesn't happen since the transparent padding wouldn't affect the resulting color. Without padding, the cropped pictures would affect each other.
This can easily be tested by filling the (theoretically invisible) padding area with a color like magenta and then zoom in or out in one's page, all crops will have a bit of magenta on their edges.
I'm about to go through my CSS and compile images into sprites, and I'm wondering what will be the most efficient approach. Currently, I've got a bunch of tiny, ~10x10 px images that need to be animated. I'm wondering if adding these images to a sprite with much larger dimensions (~1000x1000px), and then animating them will cause any difference in CPU load/performance. It's the difference between animating a small div or animating a giant div where only a small part (the specified background position) is visible.
It is better to animate a sprite.
1 server request for all images and once it is cached it's no problem.
What I would take care is the ammount of animation effects you intend to put in since doing to much could result in running slow (specially css3 3d transforms).
Have you thought of using canvas for animation instead of a container div?
An animated GIF is handled at a lower level than JavaScript, even if you're just swapping class names. Animated GIFs don't suffer from garbage collection delays and take less overhead.
Go with the animated GIF over the sprite. The file size won't differ much anyway.
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 putting together a book flip where I flip pages using CSS, JavaScript and HTML. It works very well, except for this one thing.
Every image has a block-level parent. The block-level parent's dimensions has the same ratio as the image but it's scaled down to fit inside the window. Every image has a width:100%; and height:100%; declaration making it fit directly inside its block-level parent.
Now, this works great but when I start sliding the pages the animation's VERY slow and laggish because I scale the images down. If I remove the width and height declaration from the images the animation runs smoothly but the images exceed their block-level parent's dimensions.
What can I do to fix this? Creating a new image with new dimensions isn't an option since I want the images to fit inside every screen resolution.
The animation is only slow in the following browsers/OS'es:
Opera 10, Mac
Chrome 6, Mac
Firefox 3, Windows
Safari 5 and Firefox 3 on Mac and IE7 on Windows handle the animation very well but there are some browsers, where the performance gets killed when scaling down images.
I'm not sure if this will work in your use-case, but have you tried setting the images/blocks to display: absolute or display: fixed?
Because absolute and fixed elements are not in the flow, they do not cause reflows when their properties change, so that can drastically help speed things up, depending on the circumstances.
Could we see a little code, or maybe a live example?
Some browsers are very slow at image scaling. Chrome 8 is the worst at this, in my experience, being about 5x slower than FF3.6 when resizing large images.
You can use Canvas as a workaround on browsers that support it. It's not faster at the actual scaling (yet), but it lets you guarantee that you only scale the images once, when they're loaded, instead of over and over during rendering.