Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

Summary: add support for the CSS UI property 'appearance:none | auto' with
'-webkit-appearance' as an alias. Unship '-moz-appearance'.

'appearance:none' works exactly as '-moz-appearance:none' -- it turns off
the native theme for elements that have one. 'appearance:auto' (the
initial value) makes an element have its default appearance. We are
currently shipping '-moz-appearance' with a large number of other values,
such as 'button', 'range', 'radio' etc. '-moz-appearance' will continue
to work exactly as is, but will now be restricted to UA and chrome style
sheets, i.e. it will *not* be available to web content.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching

Platfrom coverage: All

Estimated release: 54 (tentatively)

Preferences: layout.css.appearance.enabled for
'appearance'/'-webkit-appearance' (enabled by default),
layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by
default). All these properties are available to UA and chrome style
sheets though, regardless of the preference settings.

Devtools bug: None needed, I think.

Status in other implementations: No other UA implements the unprefixed
'appearance' as far as I know. Edge implements '-webkit-appearance:none'
but no other values, nor do they implement it unprefixed. WebKit/Blink
implements '-webkit-appearance' with a plethora of values, much like we
currently do for '-moz-appearance'. I don't know what their plans are for
'appearance' and/or restricting the number of supported values.

I think the fact that Edge currently only ships '-webkit-appearance:none'
proves that's all that is needed for web compat. I tend to think we
should also implement the unprefixed property though, because that's what
the CSS spec says and I don't think it'll have any negative impact in
terms of web compat (I admit I'm not 100% certain of that though, but we
can adjust as needed).

Tests: Reftests and mochitests included.

[Tantek Çelik]

Makes sense Mats, exactly as you divided it up. Thanks for pushing this.

Note: the 'appearance' property was previously in a CSS3 UI CR:
* https://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance
Where it was stable for nearly 8 years but dropped subsequently due to
lack of interop (actual divergence among implementations)

It was subsequently moved to CSS UI level 4, simplified to two values,
'auto' and 'none':
* https://drafts.csswg.org/css-ui-4/#appearance-switching

Thus this is an intent for the complete implementation of the latest
'appearance' property as specified in css-ui-4.

Though not (currently) in a CR, this property and those two values in
particular have been unchanged for years, and their definitions can be
considered stable.

Thanks,

Tantek

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Justin Dolske]

Do we have any data on existing content usage of -moz-appearance? Or is
this a "ship it and see what breaks" kind of thing?

I have the vague recollection that this is something that might have
non-trivial usage (especially and specifically "-moz-appearance: none"), so
just want to make sure that's been considered. Otherwise yay for removing
this from the web. :)

Justin

On Fri, Feb 10, 2017 at 2:27 PM, Mats Palmgren <ma...@mozilla.com> wrote:

[Mats Palmgren]

On 02/11/2017 12:28 AM, Justin Dolske wrote:
> Do we have any data on existing content usage of -moz-appearance? Or
> is this a "ship it and see what breaks" kind of thing?

I'm not aware of any data that would be useful here. Data on how often
-moz-appearance is used isn't very useful since it doesn't say if that
rule also contains -webkit-appearance / appearance (which is what is
recommended).

So what we did was to look at CSS rules in projects in github, e.g.
https://github.com/search?l=CSS&utf8=%E2%9C%93&q=-webkit-appearance+none&type=Code&ref=searchresults
which makes it quite clear that dropping -moz-appearance in favor of
-webkit-appearance will improve web compat (if we assume these projects
are somewhat representative of the web).

Also note that any failure probably isn't catastrophic. Say there is
a rule with only -moz-appearance:none, that form control will now
render using the native theme styling instead of the author's style.
(In some cases -moz-appearance:none isn't even needed, since just
setting a border/background turns off the theme anyway.)
So the control should still be visible and usable.

I'm guessing Firefox add-ons might not bother with anything but
-moz-appearance though, but I assume those counts as chrome sheets,
so the property will continue to work there as before. (Please correct me
if I'm wrong about that.)

So I'm not too worried about dropping -moz-appearance.
I think the risk comes mostly from starting to honor rules that only have
-webkit-appearance:none in case that would make the control invisible
or ugly because of incompatibilities in other properties. I think that
risk is fairly low though. And Edge did this before us so there's some
evidence it works fine.


/Mats

[Boris Zbarsky]

On 2/10/17 8:03 PM, Mats Palmgren wrote:
> I'm guessing Firefox add-ons might not bother with anything but
> -moz-appearance though, but I assume those counts as chrome sheets,
> so the property will continue to work there as before. (Please correct me
> if I'm wrong about that.)

"Chrome sheets", for purposes of this discussion are sheets whose URI
starts with "chrome://".

The biggest worry for me is that inline style is never a "chrome sheet"
in this sense.

-Boris

[Mats Palmgren]

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

[Boris Zbarsky]

On 2/16/17 10:23 AM, Mats Palmgren wrote:
> That's a valid concern, but I think ignoring -moz-appearance has fairly
> benign effects in most cases.

Well, as in things just look wrong, is all, right?

> 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

For addons we can do better: we can just contact them about it. Please
talk to :jorgev.

-Boris

[Mats Palmgren]

On 02/16/2017 04:27 PM, Boris Zbarsky wrote:
> On 2/16/17 10:23 AM, Mats Palmgren wrote:
>> That's a valid concern, but I think ignoring -moz-appearance has fairly
>> benign effects in most cases.
>
> Well, as in things just look wrong, is all, right?

Right. But as I said, at least in some cases it actually looks better
(to me).

>> 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
>
> For addons we can do better: we can just contact them about it. Please
> talk to :jorgev.

Will do.

FYI, Kohei-san has posted a heads-up here:
https://www.fxsitecompat.com/en-CA/docs/2017/moz-appearance-property-has-been-removed/


/Mats

[Benjamin Smedberg]

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

[Jet Villegas]

On Thu, Feb 16, 2017 at 7:23 AM, Mats Palmgren <ma...@mozilla.com> 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
>
>

That's not exactly what I said:
https://bugzilla.mozilla.org/show_bug.cgi?id=1340014#c2

Our procedure for these legacy properties has been to land the unprefixed
property, and file separate bugs for removing the prefixed version at a
later date. Bug 775235 <https://bugzilla.mozilla.org/show_bug.cgi?id=775235>
is really a collection of those legacy prefix removals, which tend to never
get removed at the later date unless we track them.

We have plenty of evidence that the planet requires -webkit-appearance so
we should ship that ASAP:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

If we need more time to evaluate the -moz-appearance removal, let's give it
the time it needs. The Microsoft Edge team has already done the work to
justify landing the unprefixed and -webkit variants.

--Jet

[L. David Baron]

On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote:
> 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.

I don't think this is a realistic argument. Basically any change we
make to Gecko, including implementing new features, can affect Web
compat. We have to use judgment about which ones require measuring.

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

This is a good argument that some measuring is needed in this case.

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

The cost is long-term or permanent differences between rendering
engines, which leads to extra work for Web developers and to
Web-compatibility problems for us.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Mats Palmgren]

On 02/16/2017 07:20 PM, Benjamin Smedberg wrote:
> It has happened repeatedly over the past two years that we discovered
> critical issues that affect websites only after we ship to release.

I don't think removing -moz-appearance even has the potential of being
"critical". All that happens is that you get native styling instead
(at worst). There shouldn't be any loss of function. I don't think
an average web user will even notice it.

In the unlikely event that we do want to roll this back, all we need
to do is toggle the preference values, which I believe we can do even
in release builds nowadays by pushing a restart-less system add-on.

> It is not hard nowadays to add metrics (telemetry) to measure web
> feature usage.

Getting the data we would need in this case is actually a lot harder
than you may think. It's probably easy to measure "does this web page
have a style rule that declares a valid -moz-appearance value?", but
that's useless in this case, since we really need to know if there's an
'appearance/-webkit-appearance' declaration that "wins" in this style
rule, or in some other rule. Or if there's a 'border' declaration etc
that also turns off native styling in some cases, or if the element
is a <div> or something that has no support for native styling to begin
with, etc.

Adding that telemetry machinery to the style system seems rather tricky
to me. And given the low risk with removing -moz-appearance - doesn't
seem worth implementing to me. (I think our goal is to remove all
-moz-prefixed CSS properties eventually anyway, at which point this
machinery would have little value.)

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

It seems you haven't considered that *removing* a -moz-prefixed property
could actually *improve* web compatibility. We actually have some
evidence of that for -moz-appearance:none in bug 1328474.

I suspect this is the case for -moz-appearance. If the web author also
wrote -webkit-appearance/appearance:none (as they should) then there is
no change, and if they didn't they might not have intended to have 'none'
styling in the first place. It's just that they never tested it in
Firefox. I get that impression after studying the usage of these
properties in some github projects.

AFAICT, IE11 (on a Win7 desktop) has no support for 'appearance' at all
(or any prefixed variant thereof), and Edge specifically added support
only for '-webkit-appearance:none'. And I assume the web still works
in those browsers.


/Mats

[Boris Zbarsky]

On 2/16/17 6:54 PM, Mats Palmgren wrote:
> I don't think removing -moz-appearance even has the potential of being
> "critical". All that happens is that you get native styling instead
> (at worst). There shouldn't be any loss of function.

That depends. It's not hard to come up with examples where doing that
means you can't read any of the labels on the buttons you're supposed to
click.

I thought about this a fair bit the last few days, and I think it would
be a mistake to tie shipping appearance/-webkit-appearance to the
removal of -moz-appearance. We should ship the no-prefix version and
the -webkit version. Then we should get people to switch to them. Then
we can remove -moz-appearance.

> I suspect this is the case for -moz-appearance. If the web author also
> wrote -webkit-appearance/appearance:none (as they should)

I'm 99% sure there are pages (including some produced by Google and
Facebook, last I checked) that do server-side sniffing and send only
-moz-appearance to Firefox and only -webkit-appearance to Chrome and
"appearance" to no one at all.

> AFAICT, IE11 (on a Win7 desktop) has no support for 'appearance' at all
> (or any prefixed variant thereof), and Edge specifically added support
> only for '-webkit-appearance:none'. And I assume the web still works
> in those browsers.

Edge also has a UA string that sniffs as "Chrome" unless you very
carefully try to disambiguate. This is not an accident.

-Boris

[Karl Dubost]

Sorry to not have chimed in before, but needed to do a bit of research in webcompat bugs.

TLDR: removing -moz-appearance will break some sites. At least Japan airlines.

Le 11 févr. 2017 à 07:27, Mats Palmgren <ma...@mozilla.com> a écrit :
> Status in other implementations: No other UA implements the unprefixed 'appearance' as far as I know. Edge implements '-webkit-appearance:none' but no other values, nor do they implement it unprefixed.

See also https://github.com/whatwg/compat/issues/6#issuecomment-234159236

Le 17 févr. 2017 à 03:20, Benjamin Smedberg <benj...@smedbergs.us> a écrit :
> - 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.

While this is true, things have improved a bit.

Right now
* Nightly Desktop ship with the report site issue button which lands on https://webcompat.com.
* Nightly Android has it for a long time

In fact, it helped us to detect many breakages and fixed them. :) I intend to talk about it in platform lightning talks in SF, if there is such a session.


# About -moz-appearance. A selection of issues with one example for each.


## Case 1 (Double drop down arrows)

Here a case where the site is using:
https://webcompat.com/issues/3295#issuecomment-249768573
-webkit-appearance: none
appearance: none
but not -moz-appearance: none. This is a common pattern it leads to double drop-down arrows for Firefox Android. Usually the -webkit-appearance: none is using in combination of a background-image.



## Case 2 (background-image appearance sublimation)

There are cases more subtle and difficult.
https://webcompat.com/issues/1006#issuecomment-181650441

In this case the site has this markup
-webkit-appearance: button;
-moz-appearance: button;
appearance: button;

The solution to this would be for the site to either add -moz-appearance: none
OR for Gecko to change its behaviour so that we do like webkit and drops the appearance: button when there is a background-image.
A similar issue here:
https://webcompat.com/issues/1005#issuecomment-120774729



## Case 3

In https://webcompat.com/issues/3836#issuecomment-263342153
They use only -webkit-appearance: none;
select {
font-family: Arial;
outline: none;
-webkit-appearance: none;
}

Currently what we usually recommend in these cases is to add `-moz-appearance: none;`. They were contacted on Nov 2016, still not fixed.



## Case 4

This one was confusing
https://webcompat.com/issues/4177

.nav-search .nav-category input[type="checkbox"] {
background:0;
-moz-appearance:none;
}

but eventually led to
https://bugzilla.mozilla.org/show_bug.cgi?id=1328474#c7
I need to retest once Mats patch lands in Nightly



## Case 5 (against removing -moz-appearance)

Here we will probably break again Japan Airlines if we remove -moz-appearance: none.
They implemented our suggestion to add -moz-appearance: none, which fixed the site issue. The site relies on the behaviour explained in Case 2, aka dropping the appearance when there is a background-image.

div.domModule table td select {
font-weight: bold;
font-size: 18px;
height: 54px;
border: none;
border-radius: 0px;
-webkit-border-radius: 0px;
background-color: transparent;
background-position: 97% 50%;
width: 100%;
-webkit-appearance: button;
-moz-appearance: none;
appearance: button;
}
div.domModule table td select {
background-image: url(../img/bg_dom_select_arw.png);
background-repeat: no-repeat;
background-size: 14px 14px;
-webkit-background-size: 14px 14px;
}




## Case 6 (another funky one, variation of case #2)

https://webcompat.com/issues/1061
<div class="target">
<select id="search_kbn" name="search_kbn" style="text-align:center;">
<option value="8">全てから</option>
…
</select>
</div>

The background image is a sprite (multiple images on a big png which is positioned) on the **DIV element**
AND the select has background: none but NO -webkit-appearance: none…

it's working for Webkit devices. FUN!

```
.listview li > a::after, .listview.frontbullet > li > a::after, .listview > li > div.additional-info::before, .icon, .search-box > .main > div.target, .search-box > .main > button[type="submit"], header > a::before, footer > div.go-to-top > a::before, .slide-navigation > .locator > .mark, .slide-navigation > a::before, .pager > a::before, .pager > a::after, .link-to-help > a::before, span.gift-icon, span.signage-icon, .member-icon, .notice.info::before, .notice.success::before, .notice.warning::before, .close-btn, .step-label > li::after, .options > label::before {
background-image: url(image/splite.png);
background-repeat: no-repeat;
background-size: 240px 215px;
-webkit-background-size: 240px 215px;
-moz-background-size: 240px 215px;
}
.search-box > .main > div.target {
width: 116px;
height: 32px;
background-position: -90px -115px;
}

.search-box > .main > div.target > select {
width: 116px;
height: 32px;
color: #FFF !important;
font-size: 12px;
font-weight: bold;
border: none;
background: none;
padding: 0 24px 0 5px;
}
```







--
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz

[Mike Taylor]

On 2/16/17 8:22 PM, Boris Zbarsky wrote:
> I'm 99% sure there are pages (including some produced by Google and
> Facebook, last I checked) that do server-side sniffing and send only
> -moz-appearance to Firefox and only -webkit-appearance to Chrome and
> "appearance" to no one at all.

Yeah, this happens, most predominately on the larger sites that serve N
versions to N devices. One example:

https://bugzilla.mozilla.org/show_bug.cgi?id=418833#c123

--
Mike Taylor
Web Compat, Mozilla

[Karl Dubost]

Mats, and others,

Le 17 févr. 2017 à 17:38, Karl Dubost <kdu...@mozilla.com> a écrit :
> TLDR: removing -moz-appearance will break some sites. At least Japan airlines.

Let me rephrase this in a way which is more interesting for the Web compatibility stand point of view.

SHIP: OK!
-appearance: none
-webkit-appearance: none


UNSHIP: OK with a condition.
-moz-appearance: none

If I check carefully the way the site are currently dropping the arrows on the select/option widget is by having -webkit-appearance: button or -webkit-appearance: none.

For compatibility we would need this at the same time we unship -moz-appearance: none

-webkit-appearance: button
-moz-appearance: button
appearance: button

-webkit-appearance: button and -moz-appearance: button behaves differently.
See the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1246836


I created a test.
http://www.la-grange.net/2017/02/21/appearance/appearance-test-0001.html

The issue is that when we set

-moz-appearance: button

we get a widget with arrows while -webkit-appearance: button deliver a simple button.

So if the site does:

-webkit-appearance: button;
-moz-appearance: button;
background: <image>

The rendering looks broken in Firefox.

and if the site does:

-webkit-appearance: button;
-moz-appearance: none;
appearance: button

background: <image>

the site will be broken if we unship -moz-appearance: none

[Benjamin Smedberg]

On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote:
> > 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.
>
> I don't think this is a realistic argument. Basically any change we
> make to Gecko, including implementing new features, can affect Web
> compat. We have to use judgment about which ones require measuring.
>

I agree that not everything requires measurement. I am saying that we need
a deliberate approach to risk, and that if we primarily relies on our
prerelease users to file bugs, we are not going to have any strong
guarantees of web compatibility.

Agree that this is not just for feature removals: new features may have
little risk if nobody on the web is using them. Or they may be very risky
if Chrome has deployed them and they already have traction, to the point
where web compatibility means implementing bug-for-bug compatibility with
Chrome and altering the specification.

So I want us to approach this from multiple approaches: what kinds of web
crawling automation could help mitigate webcompat risk? What about
targeted fuzzing?

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

> The cost is long-term or permanent differences between rendering
> engines, which leads to extra work for Web developers and to
> Web-compatibility problems for us.
>

And yet, that is sometimes (often?) a cost we should be prepared to bear.
The market costs of breaking almost any existing web content is so high
that we cannot afford to do it without knowing, and we should be prepared
to keep our quirks at the cost of extra engineering time and legacy support.

--BDS

[Mats Palmgren]

On 02/17/2017 03:22 AM, Boris Zbarsky wrote:
> I thought about this a fair bit the last few days, and I think it would be
> a mistake to tie shipping appearance/-webkit-appearance to the removal of
> -moz-appearance. We should ship the no-prefix version and the -webkit
> version. Then we should get people to switch to them. Then we can remove
> -moz-appearance.

Fair enough, I've updated the patches so that both prefs are now enabled
by default. IOW, we'll ship both appearance/-webkit-appearance:none, and
-moz-appearance with no change in semantics except that it is now trumped
by an appearance/-webkit-appearance:none.

Does that sound reasonable?


/Mats

[Boris Zbarsky]

On 3/22/17 2:38 PM, Mats Palmgren wrote:
> Does that sound reasonable?

Yes, thank you!

-Boris

[Mike Taylor]

Seconded.