I'm surprised and disheartened that "land it and see what breaks" is considered an acceptable strategy for pretty much any commit, but especially for web compat. We *don't* see what breaks fast enough or before things hit the release population. We cannot currently rely on our prerelease population to be an effective signal of web compatibility, for the following reasons:
- They are not distributed geographically; some geographies and languages are not well represented on beta, and nightly/aurora are even more skewed. So we could easily break a market-critical topsite in some geography and have little or no testing of that on beta. - We cannot rely on prerelease users to file bugs about issues they do encounter. Bugzilla is intimidating in general, and even more intimidating for people who don't speak English fluently. We have very little non-English documentation about filing a good bug. The signal that there is a bug might be people ceasing using Firefox, or a forum post in a language-specific board. - Even when people do file bugs, our bug handling and triage isn't fast enough to get these in front of the right person. It has happened repeatedly over the past two years that we discovered critical issues that affect websites only after we ship to release. The two top market concerns in terms of Firefox quality are speed and web compatibility. I'd encourage teams to measure carefully before taking known web compatibility risk. It is not hard nowadays to add metrics (telemetry) to measure web feature usage. Analyzing results is still harder than we want, but it's self-service and we have training and data engineer partners available to help you analyze data and make informed decisions. We *know* that -moz-appearance: none has long been a webdev technique used to unstyle various form controls [1][2][3][4]. We can also presume that sometimes people sniff and hand us different markup than other browsers. So we can't simply use data about what other engines have shipped to reason about how changes to our own engine will affect site behavior and layout. In this case, I understand the advantage of shipping CSS 'appearance'. I'm less sure about what it would cost us to keep supporting -moz-appearance: none, perhaps indefinitely. --BDS [1] http://stackoverflow.com/questions/6787667/what-is-the-correct-moz-appearance-value-to-hide-dropdown-arrow-of-a-select [2] http://stackoverflow.com/questions/4457834/how-to-use-moz-appearance-to-display-a-menulist-button [3] https://www.w3schools.com/cssref/css3_pr_appearance.asp [4] https://gist.github.com/joaocunha/6273016 On Thu, Feb 16, 2017 at 10:23 AM, Mats Palmgren <[email protected]> wrote: > On 02/11/2017 04:59 AM, Boris Zbarsky wrote: > >> The biggest worry for me is that inline style is never a "chrome sheet" >> in this sense. >> > > That's a valid concern, but I think ignoring -moz-appearance has fairly > benign effects in most cases. And as Jet pointed out to me, just landing > it and see what breaks is standard procedure for unprefixing properties: > https://bugzilla.mozilla.org/show_bug.cgi?id=775235 > > Anyway, I took a quick look at some add-on usage in XUL files: > https://dxr.mozilla.org/addons/search?q=moz-appearance+file%3A*.xul > > Most uses appears to be "-moz-appearance:none" which is reasonably safe > to ignore, and can be easily amended with a "appearance:none" if needed. > > For other values, I installed the first four add-ons that use > non-none values and analyzed what effect ignoring -moz-appearance > would have. > > "dnsqueries": > https://dxr.mozilla.org/addons/source/addons/11806/chrome/ > content/dnsqueries.xul#42 > The "-moz-appearance:textfield" has the effect of creating an extra > border+padding around the input field. This causes the control to > have extra height making the whole toolbar have more height than > needed. Ignoring this -moz-appearance makes those "problems" go > away and the toolbar and text control actually looks better (IMO). > Also, the text control still works with no loss in function. > > "RDS Bar": > https://dxr.mozilla.org/addons/source/addons/14581/chrome/ > content/dialogs/preferences/parameters/weather/window.xul#20 > https://dxr.mozilla.org/addons/source/addons/14581/chrome/ > content/rdstb.xul#3492,3525 > It appears this "weather" button is dead code, I couldn't find a way > to enable it. > > "Print Edit": > https://dxr.mozilla.org/addons/source/addons/193270/chrome/ > content/printedit-options.xul#123 > <colorpicker style="-moz-appearance: menulist"> has the effect of adding > a chevron to the button. Ignoring it makes it look like a standard > color picker button (which is an improvement, IMO). > There is no loss in function. > > "Smart Text" > https://dxr.mozilla.org/addons/source/addons/161982/content/options.xul#16 > The "-moz-appearance:textfield" has the effect of creating an extra > border+padding around the input field. However, in this case it appears > that the <h:style> (XHTML) element does count as a chrome sheet so there > is no change in behavior for this add-on since the -moz-appearance is > still honored. (IMO, it would actually have looked better without it). > > While this is a small sample, there were no problems detected. > To the contrary, it actually looks like an improvement IMO. > > > /Mats > > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
