Created attachment 276505 [details] testcase 1 What steps will reproduce the problem? (1) Visit https://jsfiddle.net/d557kky5/ or load attached testcase. What is the expected output? No red should be visible. (The inner element's background should not be clipped.) What do you see instead? Red is visible. (The inner element's background *is* clipped.) NOTES: This bug indicates that Safari is incorrectly accepting "-webkit-background-clip:content" as valid CSS. It should not -- "content" is not a valid value for the "background-clip" property. The correct value is "content-box" (note the "-box" suffix). The same thing happens for "border"/"border-box" & "padding"/"padding-box". (Safari accepts the former values -- missing the "-box" suffix -- in the -webkit-background-clip alias, but it should not.) More details on this property here: https://drafts.csswg.org/css-backgrounds-3/#the-background-clip Value: <box> [ , <box> ]* <box> = border-box | padding-box | content-box I ran into this because Mozilla is implementing support for "-webkit-background-clip" as an alias in Firefox Nightly (and Edge has done the same), and I ran across an ancient WebKit blogpost[1] which did not work in Firefox Nightly or in Edge 13, but which does work in Chrome & Safari. Turns out it's because it relies on one of these old keyword values ("border"). If there's a web-compatibility need to keep these "-box" suffixless aliases around, please let me know, and maybe we'll have to consider adding support for them. But otherwise, please get rid of them for the sake of interoperability. Thanks! [1] https://webkit.org/blog/164/background-clip-text/
Here's the Blink version of this bug, BTW: https://bugs.chromium.org/p/chromium/issues/detail?id=604023
<rdar://problem/25780703>
Created attachment 461775 [details] Safari 15.6.1 and STP 151 matches Chrome but differs from Firefox I am able to reproduce this bug using attached test case and Safari matches with Chrome Canary but differ from Firefox as can be seen from attached screenshot. Just wanted to share updated testing results. Thanks!
When the bug was reported by Daniel (Hello Daniel :) ) in 2016 (6+ years ago) on both here and chromium Mike Lawther replied: https://bugs.chromium.org/p/chromium/issues/detail?id=604023#c2 > chromestatus.com currently shows 15% of page loads contain -webkit-background-clip (https://www.chromestatus.com/metrics/css/timeline/popularity/178 - really high!). We don't have information about the usage of non'-box'-suffixed values, but without this data it's too risky to change behaviour. Let's see what it looks like now: https://chromestatus.com/metrics/css/timeline/popularity/178 It seems the usage has been decreasing a bit for `-webkit-background-clip` * background-clip 35.6766% * -webkit-background-clip 7.5421% Though the issue is really about the values content, padding, border, still being valid. And nobody has data about these. * -webkit-background-clip: content (instead of content-box) * -webkit-background-clip: padding (instead of padding-box) * -webkit-background-clip: border (instead of border-box) In https://chromestatus.com/metrics/css/timeline/popularity/178 the results might be a bit off too for the feature adoption on top sites (which is from 2018). There is a list of sample URLs, but each time I checked the site CSS seems to have been updated to a modern syntax, even for things which essentially depends on WebKit behavior. Example: ``` .iv-drawer-content::-webkit-scrollbar-thumb { border: 4px solid transparent; border-radius: 8px; background-clip: content-box; background-color:rgba(102, 102, 102, .5) } ``` Searching on GitHub, I mostly see correct form being used. https://github.com/search?q=%22-webkit-background-clip%22+padding&type=Code There was this recent bug on chromium too. https://bugs.chromium.org/p/chromium/issues/detail?id=1339290 > According to the compat spec, -webkit-background-clip is an alias for background-clip. > > This issue involves supporting the 'text' value for background-clip and disallow the box-less values 'padding', 'border', 'content'. https://wpt.fyi/results/compat/css-style-declaration-alias-enumeration.html?label=master&label=experimental&aligned&view=subtest&q=enumeration There are a couple of things to fix related to background-clip behavior. https://wpt.fyi/results/css?label=master&label=experimental&aligned&view=subtest&q=background-clip 1. Keep `-webkit-background-clip` as an alias of `background-clip` 2. Remove content, padding and border from the acceptable values could be a path forward. I wonder if there would be any regressions. Mozilla has site interventions to quickly intervene on eventual regressions. Safari has Quirks.cpp There would be a number of tests to fix. https://searchfox.org/wubkat/search?q=-webkit-background-clip&path=LayoutTests&case=false®exp=false According to https://searchfox.org/wubkat/rev/340573c924b370891b7a0794ef39d4995d3670ee/Source/WebCore/css/parser/CSSPropertyParser.cpp#3224-3232 // The values 'border', 'padding' and 'content' are deprecated and do not apply to the version of the property that has the -webkit- prefix removed. so only the prefixed version has the old values. I wonder if there was any regression reported previously. It doesn't seem. Most of the issues seem to revolve around the text value. https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f2=product&f3=component&f4=alias&f5=short_desc&f7=content&f8=CP&f9=CP&j1=OR&list_id=8503339&o2=substring&o3=substring&o4=substring&o5=substring&o6=substring&o7=matches&query_format=advanced&v2=webkit-background-clip&v3=webkit-background-clip&v4=webkit-background-clip&v5=webkit-background-clip&v6=webkit-background-clip&v7=%22webkit-background-clip%22