Bug 97761 - Do not initialize background-size when the background shorthand doesn't include it
: Do not initialize background-size when the background shorthand doesn't inclu...
Status: RESOLVED WONTFIX
: WebKit
CSS
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-09-27 00:09 PST by
Modified: 2012-11-26 16:51 PST (History)


Attachments
Patch (11.22 KB, patch)
2012-09-27 19:14 PST, KyungTae Kim
no flags Review Patch | Details | Formatted Diff | Diff
buggy_site_screenshot1 (15.55 KB, image/png)
2012-09-27 19:31 PST, KyungTae Kim
no flags Details
buggy_site_screenshot2 (32.69 KB, image/png)
2012-09-27 19:34 PST, KyungTae Kim
no flags Details
test page (10.52 KB, application/zip)
2012-09-27 20:07 PST, KyungTae Kim
no flags Details
Patch (14.35 KB, patch)
2012-09-27 22:42 PST, KyungTae Kim
simon.fraser: review-
webkit.review.bot: commit‑queue-
Review Patch | Details | Formatted Diff | Diff
buggy_site_3_google_logo (262.17 KB, image/png)
2012-11-26 07:20 PST, John Mellor
no flags Details
buggy_site_4_plus_one_button (225.18 KB, image/png)
2012-11-26 07:21 PST, John Mellor
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-09-27 00:09:44 PST
With the bug https://bugs.webkit.org/show_bug.cgi?id=27577, background-size is added to the background shorthand,
by CSS3 spec http://www.w3.org/TR/css3-background/#the-background.

But many legacy sites set background-size first and then set background for setting background-image,
in these cases, the backgrounds became weird.

So, for backward-compatibility, if 'background' shorthand have no 'background-size' attribute, 
not to initialize the 'background-size' seems better.
------- Comment #1 From 2012-09-27 10:41:53 PST -------
> But many legacy sites set background-size first and then set background for setting background-image,

Could you please provide some examples of sites that were broken by this change?

This looks like a duplicate of bug 86880, which got resolved as INVALID. Unless there is evidence of large-scale brokenness, we will likely stick to current behavior.
------- Comment #2 From 2012-09-27 10:46:33 PST -------
To repeat what Alexey said and add to it a bit:

If the CSS standard describes something that’s bad for compatibility we’ll want to change the standard as well as WebKit, not just make a non-standard change to WebKit. So we’ll need some data, both for the WebKit community and the larger web standards community, on what websites have this compatibility problem.
------- Comment #3 From 2012-09-27 19:14:53 PST -------
Created an attachment (id=166114) [details]
Patch
------- Comment #4 From 2012-09-27 19:31:06 PST -------
Created an attachment (id=166121) [details]
buggy_site_screenshot1
------- Comment #5 From 2012-09-27 19:34:23 PST -------
Created an attachment (id=166123) [details]
buggy_site_screenshot2

1st example legacy page is http://m.map.naver.com/map.nhn.
The styles for control buttons are like below.
On mobile device that have '-webkit-min-device-pixel-ratio:2', the 2nd style overwrites the background-size with an initial value.

.oa_rd{position:absolute;top:8px;left:4px;width:38px;height:38px;
background:url(http://static.naver.net/m/region/im/sp_oa_v1.png) no-repeat -60px 0;
background-size:300px 180px
}

@media screen and (-webkit-min-device-pixel-ratio:2){
.oa_rd{background:url(http://static.naver.net/m/region/im/sp_oa_v2.png) no-repeat -60px 0}
}

2nd example is an adult site.
When connect to m.pornhub.com and select "full version" with mobile device that have '-webkit-min-device-pixel-ratio:2',
the menu icons looks wierd (same cause).
------- Comment #6 From 2012-09-27 20:07:32 PST -------
Created an attachment (id=166128) [details]
test page

testcase.zip is an example test page for a common case.
It want to change only the background-image on mouse over, 
but background-size will be overwritten after http://webkit.org/b/27577
------- Comment #7 From 2012-09-27 20:22:53 PST -------
(From update of attachment 166114 [details])
Attachment 166114 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14061105

New failing tests:
inspector/styles/inject-stylesheet.html
------- Comment #8 From 2012-09-27 22:42:17 PST -------
Created an attachment (id=166143) [details]
Patch
------- Comment #9 From 2012-09-27 23:29:23 PST -------
(From update of attachment 166143 [details])
Attachment 166143 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14050532

New failing tests:
inspector/styles/inject-stylesheet.html
------- Comment #10 From 2012-09-28 10:36:29 PST -------
KyungTae Kim, can you email www-style@w3.org about this issue?  We'll want to get this changed in the spec.

http://lists.w3.org/Archives/Public/www-style/
------- Comment #11 From 2012-11-26 07:20:05 PST -------
Created an attachment (id=175998) [details]
buggy_site_3_google_logo
------- Comment #12 From 2012-11-26 07:21:22 PST -------
Created an attachment (id=175999) [details]
buggy_site_4_plus_one_button
------- Comment #13 From 2012-11-26 07:27:05 PST -------
FWIW this caused issues with the logo on Google search results, and on embeddable +1 buttons (across the web) - screenshots attached. The bugs are easy to diagnose when you know what's happening, and we'll have those fixed shortly. But this might provide a hint that this could be a reasonably widespread issue?

KyungTae Kim, did you ever email www-style@w3.org?
------- Comment #14 From 2012-11-26 07:31:28 PST -------
(In reply to comment #13)
> FWIW this caused issues with the logo on Google search results, and on embeddable +1 buttons (across the web) - screenshots attached. The bugs are easy to diagnose when you know what's happening, and we'll have those fixed shortly. But this might provide a hint that this could be a reasonably widespread issue?
> 
> KyungTae Kim, did you ever email www-style@w3.org?

Yes, see http://lists.w3.org/Archives/Public/www-style/2012Oct/0112.html.

We've also seen this problem on http://m.9gag.com, http://m.weibo.cn, and http://html5test.com (the latter has fixed it since we reported it to them).
------- Comment #15 From 2012-11-26 09:22:00 PST -------
(In reply to comment #14)
> (In reply to comment #13)
> > KyungTae Kim, did you ever email www-style@w3.org?
> 
> Yes, see http://lists.w3.org/Archives/Public/www-style/2012Oct/0112.html.

Thanks! Hmm, that thread seemed pretty conclusive (and makes some good points). It doesn't make sense for WebKit to behave differently to all other browsers on this, so I guess we'll have to resolve this as WONTFIX and just do our best to reach out to site authors who get this wrong... :/
------- Comment #16 From 2012-11-26 10:31:38 PST -------
(From update of attachment 166143 [details])
r- based on www-style feedback.
------- Comment #17 From 2012-11-26 16:51:57 PST -------
(In reply to comment #15)
The opinions of www-style guys were that  it's Webkit's fault that applying 'adding the background-size' and 'adding the background-size to the background shorthand' separately.

So, I'll make this bug RESOLVED WONTFIX.