I made my site some years ago, and people here were of great help. I check on it periodically and all was well until today, where I went there and all of the background images (figured woods) are all blown up, like when you zoom in to see individual pixels in a graphics editor.
I am using Firefox on Linux, and can not test it in IE. I suspect that something has changed in how this line in my HTML5 is being interpreted by Firefox (possibly other browsers):
<body style="background: url('../resources/css/maincontentback.jpg') repeat center center fixed; -webkit-background-size: cover; -moz-background-size: cover; -o-background-size: cover;" onload="parent.resizeIframe(document.body.scrollHeight)">
The site is of fluid design, and the backgrounds are all wide enough for the page width restrictions in my CSS, but are supposed to be stacked repeatedly to the page height, which used to work great.
To see for yourself go to http//www.rdelutherie.com, the main content backgrounds should be of the same quality as the headers and side bars.
background: url('../resources/css/maincontentback.jpg') repeat center center fixed;
-webkit-background-size: cover;
-moz-background-size: cover;
-o-background-size: cover;
You are using vendor prefixes for background-size, but there is none without the prefix, which should come last.
As those prefixes become redundant as support grows, you need the property without any prefix.
The blurriness is coming from the page within the iframe. You have to go to that page to add the unprefixed background-size property to that <body> element.
Thanks for the quick response SamA74. Sorry for being a little dense here; do you mean I can get rid of those three statements all together, and keep everything starting with “cover;”? like this:
<body style="background: url('../resources/css/maincontentback.jpg') repeat center center fixed; cover;" onload="parent.resizeIframe(document.body.scrollHeight)">
Or am I missing something?
There are only a few pages using the same code in HTML, the other pages showing the same behavior are all in CSS, but if it is just those statements, it should not be hard for me to remove them all, as long as I get it right to begin with.
I do have plans to revamp the whole site without the trouble causing Iframes, and making other major changes, but that is a huge project with my limited skills.
You can add an unprefixed background-size:cover as the last property in line or replace the prefixed three with the one without a prefix. Depends on your target audience but all modern browsers support the unprefixed version. http://caniuse.com/#search=background-size
In longhand:
body {
background-image: url('../resources/css/maincontentback.jpg');
background-repeat:repeat;
background-position:center center;
background-attachment:fixed;
background-size:cover;
}
To get Sam’s attention, you need to “tag” him like this, @SamA74.
Support for background-size is probably good enough to lose the prefixes now. Keep them only if you want to support old versions of those browsers.
But for future reference, when you do need to use prefixes, always have the un-prefixed property there, last in the list. By omitting it you are essentially not supporting browsers that do fully support the property.
Thanks again guys, I should have mentioned, that I am 90%+ illiterate when it comes to coding of any kind, and spent a huge amount of time, trial and error just to make my still crippled website without all of the various softwares, template systems and CMS that none of gave me the look and feel I was going for without adding to the confusion, and it was years ago. So I am still not 100% sure what you are trying to tell me.
My target audience is local, and although unlikely, there are probably still a few people that are not up to date with their browsers, but they should be able to get the important stuff from my site, even so. So I will omit the platform specific stuff. But just to make sure I get the in line CSS right, which if I am correct is denoted by the style statement is this OK:
<body style="background: url('../resources/css/maincontentback.jpg') repeat center center fixed; background-size: cover;" onload="parent.resizeIframe(document.body.scrollHeight)">
And if I understand Sam’s last reply right this:
<body style="background: url('../resources/css/maincontentback.jpg') -webkit-background-size: cover; -moz-background-size: cover; -o-background-size: cover; repeat center center fixed cover" onload="parent.resizeIframe(document.body.scrollHeight)">
That is how you do in-line styling, but I don’t consider in-line styling to be “OK”.
It is very much frowned upon these days as poor practice and a maintenance nightmare. It’s better to use a global css for all styling.
No, you are mixing properties within properties there. Going back to your original example, it’s just a case of adding the background-size without any prefix.
<body style="background: url('../resources/css/maincontentback.jpg') repeat center center fixed; -webkit-background-size: cover; -moz-background-size: cover; -o-background-size: cover; background-size: cover;" onload="parent.resizeIframe(document.body.scrollHeight)">
Thank you Sam, now I can see what you meant by prefix.
As for having in line statements in the first place: Everything I have read points to having one CSS file taking care of the styling of many HTML pages, which makes sense given the reasoning behind it, and I do for the most part. I also have a few pages that differ slightly from all others, which would require one separate CSS page for each. That sort of defeats the purpose of reducing calls to the server, work load reduction and what not. So far I have not seen a way to have a CSS file with statements that only pertain to some pages, but not others. Would be nice, and make sense too. There may even be a way, but I am lucky to know what little I already do.
Besides, the fact that one can not link to any of my pages in a way that the parent loads with them (at least not in Firefox) using load statements made for exactly that purpose, without some kind of major scripting as a workaround (none of the many I tried even worked), even though it in no way violates Firefox’s own “Same Origin Policy” rules, tells me that I am not alone in not keeping with good practices, and at least I have an acceptable excuse, being a novice. If it were not for one high ranking Mozzilla staffers belief/opinion that “Browser developers should have some artistic freedom in how web pages are displayed”, I wouldn’t need the iframes at all.
Thanks again @SamA74 and @ronpat, I will commence repair of my site ASAP.
Two that spring to mind (there are possibly many more).
One is to just put a <style> section on the page head with the page’s unique css rules.
Another is to have an ID on the <body> then use that in selectors in the global css to target only elements on those pages.
I’m not sure what any of that paragraph means . All I know is there is no reason I can think of with modern css, to be using iframes for layout purposes.
I do use ID’s and similar things, but again I was being specific to my own limited knowledge, and am sure that there is much to be improved on my site, which is why I am going to make a replacement for the whole thing, as time allows.
About the use of Iframes: It’s a long story, but being an electrical engineer (again no coding experience), I do have a knack of being able to recognize workarounds, and how to re-purpose things, and can come up with unorthodox but working solutions to get around the seemingly impossible.
I will most likely (hopefully) not have that problem for using iframes anymore, and definitely do without them in my new design. I have already started making new and better graphics, but most of all gathering information to make my new design much better in all ways, especially under the hood. So you can expect to see me back here more regularly in the near future.
<body style="background: url('../resources/css/maincontentback.jpg') repeat center center fixed; background-size: cover;" onload="parent.resizeIframe(document.body.scrollHeight)">
and I stripped out the prefixes from the CSS files too, but there was no change. I did clear out my browser cash too of course, so I wasn’t looking at a cashed version, and checked the image just in case. It’s as I made it. Since I also had a script (html5shiv.js) to take care of compatibility issues, I removed the refferences to it too throughout the site, but it did not do the trick either.
I was thinking it may just have to do with the browser, but I do not know of any specific page with similar backgrounds I can check it with. I am at a loss as to what can be causing it.
For a better explanation, the image is being showed zoomed in by quite a bit. I use percentages for most of the styling because it is a fluid design, if that could be the issue. The problem exists on my site as hosted as well as the backup on my PC.
@Mittineague The images are identical online and on my PC as I already stated. I have a good hosting company and way more space than I may ever use, and they do not mess with it. The site has been up for a few years with no problems, this just started. I have changed nothing. I have a lot of graphical eliments and a lot of pictures, only the backgrounds are out of whack.
and 
I will commence repair of my site ASAP.
. All I know is there is no reason I can think of with modern css, to be using iframes for layout purposes.
