This is the weirdest thing I've ever seen.
I have a class of div that has a background-image, defined as such:
background-image: url("circle.png")
background-size: contain
You can see the divs here: Rouvou.com/fiction. They're called .circle-blue or .circle-red and both classes behave identically.
So here's where it gets weird: on a Lenovo ThinkCentre machine with a ThinkVision monitor, using Firefox, they "pulsate" rapidly, or grow by a pixel in width and height rightwards and downwards, and then shrink again, very rapidly, like a flicker.
Since the Lenovo is a school computer with only two browsers installed, the only other browser I could test it on was IE, in which this behavior was not found. I wish I could post video here to show it, but here's a screenshot of one of the divs:
I've tested it on almost every browser on many other types of machines, and the only place I've ever found this behavior was Firefox on a Lenovo ThinkCentre, with a ThinkVision monitor. I also tested like 20 different ThinkCentres, and this error displayed on every single one.
Has anyone run into anything like this before? What could possibly be causing it? Can anyone at least reproduce the problem on their machine/browser?
I'm using Firefox 31.0, if that matters.
I cannot test it without access to one of these machines, but after looking at your page, I can say with 99% certainty that the issue is actually the background-size: contain part of the rule below. Firefox was only beginning to support that with that browser version, and it may have still been a bit buggy.
(http://caniuse.com/#feat=background-img-opts)
The other thing that leads me to believe this is the case is when that rule is not applied, the background image expands to the right and down as you described.
The fix, since the size of these dots do not change when re-sizing the page, would be to re-size the image manually in Gimp or Photoshop to the correct size, and not try to do it on the fly. This little cleanup will make a minor improvement overall loading/rendering of the page as well.
If you do need the image to resize, your options are using an img tag with a width: 100%; height: auto and overlaying the text over the top, or making a larger image that just has the two-tone colors and the horizontal slash. I would probably just make this all a square image, then add that as the background-image with the position set at center/center (to keep the slash in the correct spot if you need to resize) and set a border-radius on the div to 50% of the div size, making it once again, a circle.
#category .category-thing .category-thing-right-wrapper-wrapper .category-thing-right-wrapper {
display: inline-block;
position: absolute;
width: 57px;
height: 57px;
background-size: contain;
}
I believe it's just the version of Firefox you are running. For example I had trouble with HTML 5 validation with Firefox. The version of Firefox with the graphical error was 22.0, when I viewed the same thing on my laptop, using version 38.0.1, it was in the correct place. I think Firefox was just slower to implement certain things and had no way of accomplishing certain aspects without updating the browser.
I think that the same thing is happening in your scenario. Whereby those images are stylised in such a way that your version of Firefox does not fully support; it tries it's best to show them to you but just can't do it properly.
I tested several of the css properties by going on respective w3schools pages and the only style that seemed to have any sort of graphical error was background-size:contain. However, this only happens on an even earlier version of Firefox, which may not be the same as the one you are running.
I went on this Firefox website and it says that you need:
a browser that supports scaling background images (such as Firefox 3.6 or later)
to use background-size:contain;.
Final answer: your version of Firefox does not fully support background-size:contain; so there are some visual errors.
Just a thought, don't know if it'll help since I can't test it on my machine but have you tried setting max-width and max-height on your divs? On inspecting them they only have width and height set.
Try setting them to the same width and height:
max-width: 57px;
max-height: 57px;
You could also try setting the min-height and min-width:
min-width: 57px;
min-height: 57px;
The images are originally 72x72, and you make the browser downscale them to 57x57, yet the GPU might correct the scaling to fit even boundaries (depending on the graphic card your machines have). If so, the rescaling might cause the parent element to resize in order to fit its contents (as you haven't specified the overflow behavior), which will in turn cause a recalculation of the contained element.
Solution: Render the background image as 57x57 taking into account that it will be even rounded, or - preferable if you can - render it as 56x56. You will also make the CSS a bit lighter :)
Can you just clear all the CSS loaded in your browser
CTRL+SHIFT+DELETE
I have a feeling too that there's more than one CSS files pointing to id of the div. You may also update your browser.
Related
I have a huge div with size of 33,554,432x33,554,432 px on a page with absolute position. There are two divs inside it with these styles:
position: absolute;
left: calc(64.2571% - 1px);
top: 100px;
width: 46px;
height: 10px;
and
position: absolute;
left: calc(64.2571% + 1px);
top: 111px;
width: 46px;
height: 10px;
which should be placed 2 pixels different from each other, but there's absolutely no difference between the left position of them.
If I change the left properties to calc(64.2571% - 2px); and calc(64.2571% + 2px);, it's working fine.
I tried to post a fiddle with those conditions but at jsfiddle it works fine. I'm worried it's a silly problem, but I checked everything and can't solve it.
I'm using Chrome Version 51.0.2704.103 m.
I've just managed to make a similar fiddle.
I would believe this has to do with the way Chrome handles very large sizes, or possibly how other browsers handle them.
Even though you specify that you want the wrapper element to be 33554432px wide (more than 33 million pixels!!) Firefox only creates a space of 17895700 pixels (almost half). This is visible in your fiddle (slightly edited version, added console logs) when you open up the dev tools. After some digging, I found out that Gecko-based browsers do put these limits. Other browsers most definitely also have them in place (to prevent memory issues I presume), but for Geckos, it's at 17,895,700 pixels.
More precisely, as this website puts it:
Gecko-based browsers like Firefox show an interesting behavior when
trying to make the site any higher than 18.939583 kilometers,
“shrinking” or “collapsing” its main container.
If you convert that value to cm (a valid web unit), and set the item to this width (18939583cm) you'll see that this indeed agrees with the width in pixels I showed previously.
The point is that, even though your code should theoretically work on Chrome, it doesn't (probably because something goes wrong with the number crunching/rounding). That sucks. The upside is, though that it doesn't work on Firefox either - at least not in full, as it shrinks down the page. As a consequence it is probably better to find another way to achieve what you are doing -- instead of creating a canvas of more than 33 million pixels wide.
What comes to mind is ajax loading of content, and only showing the necessary parts (e.g. 1000px overflow in each direction). This will ensure a good loading time as well, though it may be harder to SEO optimise and implement.
EDIT: I didn't notice at first, but from the given fiddle it is also clear that Chrome puts a limit on the size! It's set at 33,554,428 pixels, which is almost the size you want.
This is my use case:
I have a web page with a responsive design. The page is vertically split in two halves, on the right hand side I want to show an image (a PDF page rendered as PNG or JPG). The size of the image should change as soon as the window is resized.
I thought I already solved this. I render the image on the server to be big enough for the biggest possible window size (according to our company setup). Chrome and Firefox scale down (and interpolate) the image just fine.
But then there is Internet Explorer 10: If the image size is scaled down to anything beneath 100% it looks like a million flies randomly covering the image ... I cannot seem to find a solution for this.
I learned that in the ol' days (IE7) there used to be a CSS rule for this called -ms-interpolation-mode that could be set to bicubic. But this has been declared obsolete and is not available in IE9+
Do I have to accept it like that? How can this setting be called obsolete if there is no interpolation for scaled images in IE9+? Is there any solution for this?
I know: Usually you don't let your browser scale your images. But do you have a better solution for this use case?
EDIT: I should have mentioned that the images in question are black text on white background. The effect is better visible when using thin lined fonts in the image.
EDIT2: Please recheck the fiddle (http://jsfiddle.net/7grxut1t/16/) before you close this thread. If you resize to a very small size in Chrome and IE you will see the difference!
The relevant part of my code
<div>
<img src="http://websocket.bplaced.net/test.png"/>
</div>
CSS:
div {
position: relative;
width: 50%;
height: 100%;
}
img {
width: 100%;
}
Ok, I found a quite dirty, yet applicable workaround
The angular service from https://gist.github.com/fisch0920/37bac5e741eaec60e983 uses the canvas element to interpolate the image on-the-fly. It works for me in IE10 (I am not sure about IE9- though).
Its method imageService.resizeStep is amazingly fast in IE ... it renders noticeably faster than the native Firefox image interpolation rendering.
I don't really like it, but it works and it doesn't even slow down the user's workflow.
First off, this is not the zoom issue that I've seen in other questions. Also, I'm testing this using an iPhone 4, running iOS 6. In working on a mobile project, I discovered an issue with the viewport tag and mobile safari. I distilled everything into code as basic as I could get it. I have there parameters set:
width=device-width
height=device-height
initial-scale=1.0
maximum-scale=1.0
user-scalable=no
It all works fine, until you rotate the screen. Nothing gets resized, and a black bar appears on the right side to fill in the gap (see screenshots). If I remove height=device-height completely, the problem goes away. However, I do need to use this parameter. Otherwise, I will have to ask a different question.
After rotating back to portrait mode, that black bar remains, and I can scroll left and right. This is a very strange issue. Removing width=device-width does something else unexpected. I have the code here if you would like to try it: http://toastd.net/viewport.html
Here are some screenshots:
Here it is working fine in portrait mode:
When rotated to landscape mode
Then rotated back into portrait mode
The meta tag will help define rules for the viewport but you still need to apply visual styling to address the change in orientation. Give these CSS values a try:
body { width: 100%; height: 100%; }
If you'd like a good resource to help continue your project, PhoneGap has a starter app on GitHub that you can fork.
PhoneGap Start
I believe this is a bug on Safari, but I figured out a way to work around it. It has to do with certain elements and their styles. By process of elimination, I narrowed it down to a few "offending" HTML elements. Deleting width: 100%; from some elements and CSS styles, as well as other static widths like width: 120px; would start to get reduce problem. I say "start to reduce", because the margin on the right became smaller, but didn't go away completely. I then started playing with other CSS attributes like margin and padding. After getting rid of some left and right padding from some elements, the problem finally went away. But this wasn't really acceptable, as those styles were there for a reason.
The solution was to wrap everything in a container element, size that appropriately, and set overflow: hidden; in CSS. Setting overflow: hidden; to the body or html tags would work too, but that did funky things with vertical scrolling in Mobile Safari. In my case, there was already such a container element, so all I had to do was add the overflow property to it.
Like I said, I think this is a bug in Safari. When you rotate from Landscape to Portrait, everything should be resized back to fit portrait mode. Visually, everything does look like it was resized properly. However, Safari must have thought something wasn't resized properly, so it displayed the page wider than it really was. This works just fine in Chrome on an Android device. I also added different background colors and borders to highlight which element might be causing the page to stretch beyond the width of the device screen. Visually, there was no apparent culprit.
If you're thinking it might be a width: 100% plus padding issue, I had the same thought. But then deleting either the width or the margin/padding alone should have fixed the issue, which it did not. Not a single element was sitting beyond the edge of the screen. There was nothing but empty space there.
On http://phoenixprints.org/viewpicture.php?pid=258 the main picture stretches vertically and looks bad. I don't know why its happening at all, and seems to only happen sometime. This does not happen on all pictures, and is puzzling me.
I'm running 18.0.1025.151 (Developer Build 130497 Linux) Built on Ubuntu 12.04 on chromium and it does not happen.
19.0.1084.56 m google chrome on windows xp it does?
You set the image height to 100% with this style:
.viewimg img {
width: 100%;
height: 100%;
}
None of the parent elements seemed to have an explicit height given, so WebKit (Mac/Safari in my case) probably chose the window's height as a reference for calculating percentages.
In firefox it only works because it seems to completely ignore the height: 100% part. Try it with some other values, and you will see.
My solution would be simply removing the height: 100% from the css, browsers should (in theory) resize the image by keeping its normal aspect ratio.
I recall it was long ago best practice to hardcode width and height for any image (generally so it allocated appropriate amount of space while loading), but now with most people on high speed and things generally more dynamic, what is the best practice for this? Is it still preferred that any content image have inline size set with html?
It doesn't matter if you set the size using HTML attributes or in a stylesheet, but you should still specify the size for images.
Eventhough images are loaded a lot faster nowadays, there is still a noticable delay between the page being displayed and the images pop up. It's still irritating when the layout of a page changes while the images are loading.
Yes, it is still preferred.
Plenty of people are not on high speed connections, and mobile is becoming more common.
It doesn't have to be inline - you can do it in external CSS. Some older browsers, if you don't specify the size, will just treat it as 0px;
Its always best to use CSS
You could hardcode the image height and width like this
.myimg img {
width: 10px;
height: 10px;
}
your image file itself should be the size you want it to display as, for the most part, if your concerned about slow loading especially! if you've got a 500X800 px image, that you only want to show as 100X200, scale it down! the file size will be much smaller so it will load faster :)
I would say yes if you want to make sure the white space is included in case of the image does not load or during document load. But no if you're scaling/resizing the image with those attributes, as its unnecessary load on the browser and causes image distortion.
If you are designing for cross browser compatibility, then you should at the very least specify the height and width in your CSS for the image itself. I have found inconsistency between FireFox, IE, Opera, etc if sizes are not specified specifically for the image. Due to the fact that each browser, not to mention different versions, handle adherence to HTML Standards differently. I have found that some browsers will do its best to extrapolate the HTML designers intent, while others just croak on the first error. I would also recommend em sizes, rather than pixel or %'s if you intend for the website to be viewed from a mobile device such as a tablet. I will say, however I have just started playing with HTML5 so I don't of the difference in HTML5 with respect to images.
I just answered a similar question on Wordpress Stack Exchange and also on Webmaster Stack. I am posting it here intending to clarify and help more people. (admins/moderators: if this isn't allowed, let me know the proper way to help).
doesn't really means you need to specify width and height in the html. What it means is that is you gotta reserve te proper space and when the image is loaded, the browser doens't have to reflow and repaint the page.
Besides, if you hardcode the dimensions, it kinds of defeats responsive behaviour. If your layout is not responsive, it's ok, but if you want to keep some responsiveness, you could use only CSS to achieve the results.
Most of time, using both width and max-width:100 will do the work, but this post from Smashing Magazine has an interesting technique: instead of using max-width:100%, you can use The Padding-Bottom Hack :
"With the technique, we define the height as a measure relative to the width. Padding and margin have such intrinsic properties, and we can use them to create aspect ratios for elements that do not have any content in them.
Because padding has this capability, we can set padding-bottom to be relative to the width of an element. If we also set height to be 0, we’ll get what we want. [...]
The next step is to place an image inside the container and make sure it fills up the container. To do this, we need to position the image absolutely inside the container, like so:"
.img-container {
padding-bottom: 56.25%; /* 16:9 ratio */
height: 0;
background-color: black;
}
.img-container img {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
}