9

I'm using jQuery's .css() method to set the background image of a div. The HTML in its final state is thus:

<div id="front-page-bg" style="background-image: url(http://peterfcarlson.com/wp-content/uploads/2011/09/ert-011.jpg); display: block; "></div>

It works fine, however, I'm getting an error/warning in Chrome, where the background-image property is struck through as though it's being ignored due to bad input, even though it is obviously being applied. Why would this be? Is it a problem with Chrome, or on my end?

An error in the Chrome Developer Tools window

I've tested the page in FF and IE, where it also seems to work without any errors or similar warnings. Any ideas about why this might be happening, and perhaps more importantly, should I ignore it, since the page seems to be working?

Isaac Lubow
  • 3,557
  • 5
  • 37
  • 53
  • Does Chrome give you an information as to the warning? – Jamie Dixon Oct 05 '11 at 16:42
  • No "warning" as such appears in the console, no. – Isaac Lubow Oct 05 '11 at 16:42
  • Definitely odd. I have to wonder if this is some sort of odd sandboxing error/bug. – Ryan Kinal Oct 05 '11 at 16:47
  • Curious. For what it’s worth, this produces the same behavior: `data:text/html,
    ` If you use `background` rather than `background-image`, it doesn’t do the strikethrough, but it still displays the warning icon. I have no idea what’s going on.     – Daniel Brockman Oct 05 '11 at 16:52
  • I've tried to duplicate the error and the only way to make it go away seems to be to use `background` shorthand instead, and throwing a couple of unnecessary properties in-- but yes, the icon remains. – Isaac Lubow Oct 05 '11 at 16:53
  • @IsaacLubow Remind me in a few days and I'll put a bounty on this. – Šime Vidas Oct 05 '11 at 17:48
  • 1
    Try wrapping the image's address with quotes or apostrophes like that: url('http://www.google.com/intl/en_com/images/srpr/logo3w.png'). – biphobe Oct 06 '11 at 07:57
  • 3
    Are there any other background properties applied your `#front-page-bg` from any other scripts or stylesheets? It could be indicating there is a conflict rather than a bad input. –  Oct 06 '11 at 21:31
  • @firian, the quotes make no difference to the problem. You can check that in Chrome. @Nathan, there are other background properties, such as `background-size`, in the stylesheet, but no duplicates. What's an example of a conflict? Even in the case of duplicate rules, one is simply overwritten, and in certain cases a rule is applied and then ignored (eg: `display:table-cell` causes `margin` to be ignored on the same element). – Isaac Lubow Oct 12 '11 at 02:52
  • 1
    @firian - While everyone should wrap URLs in quotes (it's the right practice), Chrome still shows such code without the quotes. – Christian Oct 14 '11 at 14:19
  • can you show us please your original site in order to debug in in real time ? – KodeFor.Me Oct 15 '11 at 07:18
  • I get the warning icon in both safari and chrome. setting it to background:url(imagename.png) repeat; removes it, but w/o the repeat the warning is still there. And when setting it in a css class, i.e in a style tag, the problem disappears. And if I set it via the inspector in element.style, the warning occurs as well, so it seems it's only when you set it to the html element directly. Strange.. :) – fredrik Oct 15 '11 at 12:08
  • What kind of wordpress site are you running? a single site or a network network site? Can you post the content of your .htaccess file? – Andres I Perez Oct 15 '11 at 12:54
  • The bug was fixed 2 weeks ago. http://trac.webkit.org/changeset/98714 Chrome '17.0.932.0 dev' works fine – loislo Nov 14 '11 at 12:31

4 Answers4

8

EDIT:

By inspecting more deeply (ignoring the first misleading 404 problem with image), seems that developer tools is ignoring the style definition; infact it applies a not-parsed-ok class which appends the warning icon, and an overloaded class which causes the line-through. The overloaded class is not appended if using background in place of background-image css definition.

But to discover the reasons of this behaviour would be necessary to analyze the developer tools source code.

My guess is that is a developer tools bug/incomplete feature.

This is my own test:

enter image description here

as you can see the image used is local, and have apix. And this is the resulting inspection:

enter image description here

Testing with a non existent css property, it shows the identical behaviour:

enter image description here

Your referenced image has some strange web server issues: infact it is returning a 404 error (maybe timeout?), then a redirect.

So you should check the image and the web server path, not your actual html code.

Chrome screenshot

Even trying to put in actual html code, the error is the same:

enter image description here

This is the actual response of your web server, instead of your image:

<!DOCTYPE html>
<html>
<head>
<style type="text/css">
html,body{height:100%;width:100%;margin:0;padding:0;}
body{overflow:hidden;background:#EDEDED url(http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png) center center no-repeat}
</style>
</head>
<body>
</body>
</html>
ʞᴉɯ
  • 5,376
  • 7
  • 52
  • 89
  • 1
    there no webserver issue check this example http://jsfiddle.net/sandeep/RDmRz/2/show/ you still get an warning in chrome & webkit – sandeep Oct 15 '11 at 09:32
  • This is not a developer tool bug its a warning since chrome and safari both throws warnings when you try to use deprecated features. – Koba Oct 15 '11 at 10:39
  • So why it does not explain in the console as it does with other warnings? And why does not add a more convenient "deprecated" class to its styles? And why it adds the line-through as it is overloaded, even if not? – ʞᴉɯ Oct 15 '11 at 10:43
  • warning doesn't means it's a wrong property. It's means not a good or not recommend value. That's why it's show image without any problem in chrome, firefox, safari etc.. – sandeep Oct 15 '11 at 10:51
  • We are not debating whether the property is correct or wrong, but that the "warning" has no indication that lets the user understand the reason for his presence; so if it is not a bug, it is at least a not complete feature. And anyway the line-through is not justified. – ʞᴉɯ Oct 15 '11 at 10:56
  • The HTML returned by the server is a result of the page not yet being live. And I don't see any evidence that setting `background-image` on a `
    ` inline is "deprecated" or "wrong" in any way.
     – Isaac Lubow Oct 20 '11 at 09:14
  • The bug was fixed 2 weeks ago. http://trac.webkit.org/changeset/98714 Chrome '17.0.932.0 dev' works fine – loislo Nov 14 '11 at 12:33
2

The problem is the DevTools/WebInspector bug. DevTools UI code just shows the data not always correctly generated by the back-end part of DevTools.

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=70325

Chromium bug: http://code.google.com/p/chromium/issues/detail?id=100646

loislo
  • 14,025
  • 1
  • 28
  • 24
1

@IsaacLubow; Both Chrome & Safari developer tool show that warning error. Then question is

Why they show a warning ?

Answer:- Both Chrome & Safari developer tool show warning when the property is not understand & recognized by them.

for example:- write -moz-border-radius in the css. Then check the page in chrome or safari. It's shows the same error which you have.

Then the second raised question is

But background-image property is recognized by all browsers !

Answer :- Yes; background-image property is recognized by all browsers & the image is still shows in the website but the way we define the image is cause for that warning/error. In your example if you define background-image property inside the html tag instead of css. It's shows the warning/error.

Check this example the first div images show an warning but second div is not show any warning:

http://jsfiddle.net/sandeep/RDmRz/3/show

So; why that's happen ?

Because assigning attributes in html tag is a Deprecated method means

Those deprecated features can still be used, but should be used with caution because they are expected to be removed entirely sometime in the future. You should work to remove their use from your code.

Check what mozilla said about that https://developer.mozilla.org/en/JavaScript/Reference/Deprecated_Features

https://developer.mozilla.org/en/DOM/HTMLImageElement

So; Developer tool are updated as per the new html standards & after introducing HTML4 some properties deprecated & outdated.

Check this for more http://fantasai.tripod.com/qref/HTML4/deprecated.html

http://www.createafreewebsite.net/html_tutorial/body_tag.html.

It's good to write background-image in css instead of html tag.

sandeep
  • 91,313
  • 23
  • 137
  • 155
  • Your answer is of topic. He is trying to set the background of a
    element and not of a body.     – KodeFor.Me Oct 15 '11 at 07:17
  • @MerianosNikos; but the reason is same giving background-image in html tags . Now check my updated answer – sandeep Oct 15 '11 at 07:22
  • I think that is depending on DOCTYPE and not in HTML at all ! Am I wrong ? :? – KodeFor.Me Oct 15 '11 at 07:25
  • So I think for best answer we need to know what is the DOCTYPE as your answer is correct only for specific DOCTYPE – KodeFor.Me Oct 15 '11 at 07:40
  • 2
    What does a deprecated HTML attribute (that doesn't even exist on `html`, it only exists on `body`) have to do with CSS? – BoltClock Oct 15 '11 at 08:05
  • You have that mixed up, sandeep. It's the `background` attribute of the body tag that has been deprecated. The css style `background` and `background-image` are alive and well. Here he only assigned the styles in the `style` attribute for demonstration purposes. Not recommended in the real world, but certainly not deprecated. – uɥƃnɐʌuop Oct 15 '11 at 08:12
  • @150PoundsOfDonamite & BoltClock DEPRECATED method means which use in inside html tag styling check this http://www.quackit.com/html/codes/html_background_image_codes.cfm what they said – sandeep Oct 15 '11 at 08:46
  • please who give downvoted me please exaplain me where iam wrong – sandeep Oct 15 '11 at 09:33
  • 1
    I think Sandip is right please check the jsfiddle he has attached. I checked it and it seems he is correct. – Koba Oct 15 '11 at 09:38
  • 2
    sandeep, i think you are wrong; your answer makes **assumptions** that you are **guessing**: infact **in no one url that you have posted is specified that the background-image inline style is deprecated**: they tell about deprecated html tags, not style sheets: actually in your last url the background-image is suggested as replacement, not as deprecated one! Background-image element in style sheet is not deprecated; if we must say something is deprecated, it is the inline style sheet at all; but this does not explain why other css properties are not signed, as you have assumed. – ʞᴉɯ Oct 15 '11 at 16:15
  • We know what "deprecated" means. Please read our comments again (as well as @Michele Virgilio's comment). Even the page too, which says "the HTML method is deprecated", not "the CSS method is deprecated". – BoltClock Oct 16 '11 at 09:56
  • @150PoundsOfDonamite In the "real world", such as in my example, the style is inline because I am not parsing the CSS file as PHP. As the source of the background image is being generated dynamically, my only choice is to put the style in the HTML. jQuery effects are another example of a "real-world" application that makes extensive use of inline styles, indeed, adding styles to the DOM is the only way I know of to change the page without a reload. – Isaac Lubow Oct 20 '11 at 09:20
1
http://peterfcarlson.com/wp-content/uploads/2011/09/ert-011.jpg

Your image is not coming up, instead we are getting a 404 error. I noticed that you are using a wordpress site from the structure of your image url, what we might be looking at is not your image but the image included inside your 404.php page inside your theme.

The html that is returned is the following:

<!DOCTYPE html>
<html>
<head>
<style type="text/css">
html,body{height:100%;width:100%;margin:0;padding:0;}
body{overflow:hidden;background:#EDEDED url(http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png) center center no-repeat}
</style>
</head>
<body>
</body>
</html>

And this is the image being loaded instead: http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png

I'm quite sure that if you check your 404.php page from your theme that is what you will find. So you might want to re-upload the image and use the new url.

Comment

I know the question was answered but wanted to chime in with my results as to what i found. I noticed that, for some reason, when you specify a background-image to an element it sometimes drops a warning in a webkit browser, which is the issue that the OP was having. But i noticed that the warning disappears when the background shorthand is used instead.

Like so:

background:#ffffff url('image.png') repeat scroll right top;

I modified @sandeep's demo to show how it works:

Here is the full fiddle: http://jsfiddle.net/RDmRz/7/

And demo page: http://jsfiddle.net/RDmRz/7/show/

Check the page with the developers tools and switch between the divs to show how it is working for the "works" images and not working for the others.

A couple of screenshots:

Works

Works

Doesn't Work

Doesn't Work

Andres I Perez
  • 75,075
  • 21
  • 157
  • 138
  • When referring to wordpress sites, random 404 errors are not being specific enough. Wordpress sites can use custom 404 error template files that come up anytime there is an error, something which you did not reference. – Andres I Perez Oct 15 '11 at 12:41
  • The image url is correct(just checked). Actually the problem lies with webkit browsers. Just replace the js/jquery css property with proper url in the css file itself. You will notice there is no error. The difference actually is using javascript/jquery puts the style as inline code in the XHTML file to which the webkit shows an error. – Sarthak Gupta Oct 15 '11 at 12:45
  • check this example http://jsfiddle.net/sandeep/RDmRz/3/show there no problem with image but it's still show a warning. – sandeep Oct 15 '11 at 12:45
  • Yes, but if you had better read the response, and the question, the problem is not the 404, as it occurs with any image, even without 404. – ʞᴉɯ Oct 15 '11 at 12:49
  • @user903598 No, the image also has errors in firefox, they just don't get reported, if you check the header of the image with firebug and the you can see that it hands out a "404 Not Found" error. Sandeep, the same problem also, you're not seeing the referenced image, which is **http://peterfcarlson.com/wp-content/uploads/2011/09/ert-011.jpg** and instead you are seeing **http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png** "from" the 404.php page im quite sure. – Andres I Perez Oct 15 '11 at 12:50
  • @user903598: the problem is not javascript/jquery, but the inline style sheet. – ʞᴉɯ Oct 15 '11 at 12:51
  • Please read other answers before re-make already done work/inspections. – ʞᴉɯ Oct 15 '11 at 12:52
  • @MicheleVirgilio then it's a problem with the htaccess file, and not the images themselves, the OP would have to post further info on the construct of the htaccess file. - Wordpress dev. – Andres I Perez Oct 15 '11 at 12:52
  • Again? It has been proved than the problem arises with **any** image, even without the 404 error. That was my first assumption of the error. – ʞᴉɯ Oct 15 '11 at 12:54
  • @MicheleVirgilio Do you understand how a wordpress site works? If so, do you understand how an htaccess file works? If so, do you know how it handles redirects? If so, do you understand how the OP's htaccess is structured? If not, then just wait for a reply from OP, no need for your baseless replies. – Andres I Perez Oct 15 '11 at 12:59
  • @Andres Ilich. I'm sorry to say, but perhaps you're a little 'dull. The 404 problem I was recognized as the primary cause of the question placed here (I know how it works wordpress, htaccess, etc.). But then doing more extensive testing, I found the problem in question occurs with any image (try it yourself with your own local server for example). So wordpress has absolutely nothing with the question exposed. The problem occurs when you use an inline style sheet with a background-image. – ʞᴉɯ Oct 15 '11 at 13:06
  • @MicheleVirgilio I apologize for my rashness, i based my answer on problems i've encountered before but that was clearly not the issue here and i acted too hastily. Please see my comment above. – Andres I Perez Oct 15 '11 at 21:20
  • Yes, the 404 is because the site is not yet live. WordPress has nothing to do with the issue. – Isaac Lubow Oct 20 '11 at 09:09