Bug 97761 – Do not initialize background-size when the background shorthand doesn't include it

• Component: CSS
• Status: RESOLVED WONTFIX

[KyungTae Kim]

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.

[Alexey Proskuryakov]

> 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.

[Darin Adler]

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.

[KyungTae Kim]

Created attachment 166114 [details]
Patch

[KyungTae Kim]

Created attachment 166121 [details]
buggy_site_screenshot1

[KyungTae Kim]

Created attachment 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).

[KyungTae Kim]

Created attachment 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

[WebKit Review Bot]

Comment on attachment 166114 [details]
Patch

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

[KyungTae Kim]

Created attachment 166143 [details]
Patch

[WebKit Review Bot]

Comment on attachment 166143 [details]
Patch

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

[Tony Chang]

KyungTae Kim, can you email [e-mail] about this issue?  We'll want to get this changed in the spec.

http://lists.w3.org/Archives/Public/www-style/

[John Mellor]

Created attachment 175998 [details]
buggy_site_3_google_logo

[John Mellor]

Created attachment 175999 [details]
buggy_site_4_plus_one_button

[John Mellor]

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 [e-mail]?

[Liam Quinn]

(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 [e-mail]?

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).

[John Mellor]

(In reply to comment #14)
> (In reply to comment #13)
> > KyungTae Kim, did you ever email [e-mail]?
> 
> 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... :/

[Simon Fraser (smfr)]

Comment on attachment 166143 [details]
Patch

r- based on www-style feedback.

[KyungTae Kim]

(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.