Regarding criteria for letting -webkit-appearance ride the trains, I assume you're wondering about that due to my use of EARLY_BETA_OR_EARLIER to flip the pref. That was mostly because Mats has been away on summer vacation and I suspect that he'll want to have input on whether this is ready to ship. It was also to allow some time for feedback here before making that decision. So far nobody has objected to it being ready, but we'll see what Mats says once he's back. If there are no objections and no issues crop up then I plan to put a patch up on bug 1368555 before soft freeze to let the pref ride the trains to Release. (Easily revertible if necessary, of course.)
There are certainly differences between Chrome and Safari. Some that I noted down are: * 'checkbox'/'radio' cropping the entire content of an element is Safari * different background color for 'button-bevel' and many other values * 'menulist' working on <div> in Safari but not Chrome * 'menulist-button' setting a background on buttons in Safari * padding and margin differences The fact that Chrome hasn't had to stay consistent with Safari in many cases I looked at is likely due to the fact that only a limited number of values on a limited number of element types are common. That's part of the reason I'm not too worried about the bugs blocking bug 1481581 (the issues where we know we have differences to Chrome) since they seem fall into the "infrequently encountered" bucket. Jonathan On 08/08/2018 01:40, Chris Peterson wrote: > Awesome! This should fix some common webcompat issues for > Firefox/GeckoView on Android. > > What are the criteria for letting -webkit-appearance ride the trains? > The GeckoView team is eager to ship mobile webcompat fixes, so they > might be willing to accept more risk than Firefox desktop. > > Are there any significant differences between -webkit-appearance on > Chrome and WebKit? Chrome has more mobile market share than Safari, but > many of these mobile sites may have been written when a -webkit- prefix > actually meant WebKit. :) > > > On 2018-08-07 3:16 PM, Jonathan Watt wrote: >> Summary >> ------- >> >> I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to >> turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref >> simultaneously changes the behavior of the 'menulist-button' value, and >> shortly >> the 'button-bevel' value. >> >> Spec: None. We're reverse engineering Chrome and ignoring >> https://drafts.csswg.org/css-ui-4/#appearance-switching >> since the 'appearance' property defined there is not >> web compatible. >> >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480073 >> >> Preferences: layout.css.webkit-appearance.enabled >> >> Platfrom coverage: All >> >> Estimated release: 63 (tentatively) >> >> Known webcompat impact: 19 out of 20 of the open -webkit-appearance >> webcompat.org issues are fixed by this change. >> >> >> The alias >> --------- >> >> The primary concern currently is to get `-webkit-appearance: none` shipped to >> fix a bunch of web compat issues and unblock geckoview. That said, >> previously we >> tried to implement and ship the 'appearance' property with only the values >> 'none' and 'auto' (as per CSS UI 4), along with a '-webkit-appearance' alias. >> That attempt was unsuccessful for various reasons, but mainly because >> cascading >> of a '-moz-appearance' other than 'none'/'auto' would not replace a lower >> specificity 'appearance' value, breaking current web content and user >> expectations about how the properties should cascade. >> >> This time around by aliasing '-webkit-appearance' to '-moz-appearance' our >> implementation of '-webkit-appearance' will support all the values that >> '-moz-appearance' supports, avoiding the funky cascading issues. >> >> >> Changes in behavior for existing values >> --------------------------------------- >> >> Aliasing means that we'll recognize and react to a bunch of other >> '-webkit-appearance' values that sites set, so to minimize the chances of >> undesirable changes on existing web content, we've also been changing the >> behavior of some '-moz-appearance' values to more closely align with the way >> that Chrome handles the values of the same name for '-webkit-appearance'. >> Some >> of those changes have shipped. The two that haven't are guarded behind the >> same >> pref that turns on the '-webkit-appearance' alias: 'menulist-button' and >> 'button-bevel'. (They probably don't need to be though, so we could >> potentially >> ship those separately if desirable.) >> >> Both 'menulist-button' and 'button-bevel' occur two orders of magnitude fewer >> than 'none' as a '-moz-appearance' value in github repos, and almost all the >> occurrences for the two values seem to be non-interesting. >> >> menulist-button >> >> https://github.com/search?o=desc&q=-moz-appearance+menulist-button&type=Code >> >> I dug through hundreds of these and didn't encounter any instances >> that would impact web content. The vast majority appear to occur in >> forks of the Mozilla source or appear in a list of possible values in >> csslint.js. >> >> The change here makes us display the appearance of an entire (collapsed) >> menulist, not just the drop marker to its right. That makes the change >> here more substantial and so in principal breakage could be significant. >> >> button-bevel >> https://github.com/search?o=desc&q=-moz-appearance+button-bevel&type=Code >> >> Again, I dug through hundreds of these with the same observation as >> for menulist-button. Even in the places where it is used, border is >> typically overridden meaning that there will likely be no visual >> change for consumers. >> >> Additionally, the difference between the way button-bevel currently >> displays and how it will be changed to match Chrome is minimal. >> >> Perhaps more significant is the usage count of the various values reported by >> the crawl MS did for Edge: >> >> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/ >> >> Blink/Webkit have no equivalent to our old behavior for 'menulist-button' >> (show >> a dropmarker) which indicates that demand hasn't been high enough for them to >> add that functionality. Given that, I expect the number of sites using and >> depending on our old 'menulist-button' behavior are extremely low. >> >> Blink's 'square-button' (which behaves the same as our 'button-bevel') was >> only >> used on 0.002% of the pages that they crawled, and again, the visual >> appearance >> change we're making is minimal. >> >> >> Further aligning '-moz-appearance' with '-webkit-appearance' >> ------------------------------------------------------------ >> >> I've filed a bunch of bugs for the differences that I'm aware of between the >> behavior of '-moz-appearance' in Firefox and '-webkit-appearance' in Chrome, >> and >> marked them as blocking this meta bug: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1481581 >> >> The possible uses and permutations of '-moz/webkit-appearance' are vast, so >> if >> anyone is aware of anything significant that I may have missed please file a >> new >> bug and make it block that meta bug. >> >> I don't think fixing/not fixing any of the issues that that meta bug tracks >> so >> far is likely to cause significant improvements/regressions for a significant >> amount of web content, or prevent us from shipping the alias. (Comment here >> or >> in the bugs if you disagree, please.) That said I intend to fix some of them >> before 63 rides the trains to improved alignment between Firefox and Chrome, >> and >> reduce the risk of shipping the alias (we have 16 days before the start of >> the >> soft freeze/30 before uplift). >> >> >> -Jonathan >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
