Summary: | right- and bottom-relative values in background-position-x/y don't work | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | John A. Bilicki III <jab_creations> | ||||||||||||||||
Component: | New Bugs | Assignee: | Simon Fraser (smfr) <simon.fraser> | ||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||
Severity: | Normal | CC: | 50167214, ap, darin, esprehn+autocc, ews-watchlist, glenn, gyuyoung.kim, koivisto, macpherson, menard, simon.fraser, webkit-bug-importer | ||||||||||||||||
Priority: | P2 | Keywords: | BrowserCompat, InRadar, WPTImpact | ||||||||||||||||
Version: | Safari 12 | ||||||||||||||||||
Hardware: | Mac | ||||||||||||||||||
OS: | macOS 10.14 | ||||||||||||||||||
Attachments: |
|
Description
John A. Bilicki III
2019-09-24 09:48:31 PDT
This page seems to look the same for me between Safari 13 and Chrome. Could you please attach screenshots of expected and actual rendering? Created attachment 379586 [details]
Potrait mode screenshot from an iPhone 6S.
I should have clarified this was Safari using an iPhone 6S. This occurs in both portrait and landscape orientations and I'll fix the unrelated rendering errors.
The rule is: background-position-x: right calc(var(--size_layout_border_radius) / 2) !important; which is resolving to 0%. This is more likely to be about calc than background-position. It's really hard to tell because the page is a mess, and it looks like Chrome has the same rendering. Please attach a more obvious testcase. Apparently WebKit doesn't support the two value syntax: https://developer.mozilla.org/en-US/docs/Web/CSS/background-position-x#browser_compatibility "It's really hard to tell because the page is a mess" I presume since your email address is @webkit.org that you're inherently qualified as an engineer who speaks with other engineers. So let's try this one more time: Copy - the following code: document.getElementById('post_title') Paste it - in to the developer console. It'll highlight the element. If you have a small screen you can scroll down. I was able to easily find the element. I was not able to see how the rendering was incorrect. Created attachment 437636 [details]
Gecko and WebKit background-position-x comparison PNG image.
I should mention that the second value is used because the input element has a border-radius so I need to use the second value offset to move it away from the right-most edge. I could use a high value from the left however the rendering would be drastic between tiny mobile screens and large displays of which my visitors use both and everything in between. Clarified by screeshot Created attachment 437646 [details]
Simple testcase
It seems that what doesn't work is specifically the right-relative form. Seems like we don't support `background-position-x: right 30%;` without calc (nor does Chrome). Created attachment 437658 [details]
Patch
Created attachment 437663 [details]
Patch
Comment on attachment 437663 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=437663&action=review > Source/WebCore/css/Pair.h:43 > + ASSERT(first); > + ASSERT(second); Why would we do this? If we can’t take nulls, then why not have the arguments be Ref<>? (In reply to Darin Adler from comment #15) > Comment on attachment 437663 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=437663&action=review > > > Source/WebCore/css/Pair.h:43 > > + ASSERT(first); > > + ASSERT(second); > > Why would we do this? If we can’t take nulls, then why not have the > arguments be Ref<>? I was trying to catch a null in this pair early, and seeing if EWS hit the assertions. If not, I can make them refs. Created attachment 437673 [details]
Patch
Created attachment 437676 [details]
Patch
Comment on attachment 437676 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=437676&action=review > Source/WebCore/css/parser/CSSPropertyParserHelpers.h:49 > +enum class BoxOrient : uint8_t; BoxEastAsia Comment on attachment 437676 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=437676&action=review > Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp:2824 > + if (value1 && !value2) > + return value1; > + > + if (!value1 && value2) > + return value2; > + > + return nullptr; This can be written more simply like this: return value1 ? value1 : value2; > Source/WebCore/css/parser/CSSPropertyParserHelpers.h:131 > +RefPtr<CSSPrimitiveValue> consumeSingleAxisPosition(CSSParserTokenRange&, CSSParserMode, BoxOrient, UnitlessQuirk = UnitlessQuirk::Forbid); Do we need the UnitlessQuirk argument? Are there future clients who will want to pass it? *** Bug 157511 has been marked as a duplicate of this bug. *** |