-moz- gradients dropping creates Web Compatibility issues

[Karl Dubost]

Boris, David, Daniel,

Mozilla dropped support for -moz- gradients. [1]
This creates Web Compatibility issues. In a couple of days we found

* gmail buttons
https://bugzilla.mozilla.org/show_bug.cgi?id=1182775
* hotspot shield homepage
https://bugzilla.mozilla.org/show_bug.cgi?id=1182861
* facebook
https://bugzilla.mozilla.org/show_bug.cgi?id=1183504
* a site on blogspot
https://bugzilla.mozilla.org/show_bug.cgi?id=1183602
* music oricon
https://webcompat.com/issues/1061
* bg-mania.jp
https://webcompat.com/issues/1393

This for what we know.

There are two options here. Reverse the dropping of -moz- and do it in a more collegial way with other browser vendors. So it breaks heavenly everywhere and we have more chances to get it fixed. (CSS Working Group).

And/or drop but taking care of -moz- when standard properties are not there with the CSS unprefixing service [2] enabled for the Web (what we are planning but not yet done [3]).


Opinions?


[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1176496
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1107378
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1177263

PS: I have found also an issue with -moz-background-size.

--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Daniel Holbert]

[adding emk (VYV03354) to CC; he added support for unprefixed gradients,
and landed the patch to drop support for prefixed gradients]

On 07/14/2015 04:36 PM, Karl Dubost wrote:
> Mozilla dropped support for -moz- gradients. [1]

> This creates Web Compatibility issues. In a couple of days we found...

Yeah, this seems concerning. :-/

> There are two options here. Reverse the dropping of -moz- and do it in a more collegial way with other browser vendors. So it breaks heavenly everywhere and we have more chances to get it fixed. (CSS Working Group).

I can imagine we *might( be able to get Microsoft to join us & drop -ms
prefixed gradient support. But I'm extremely skeptical that
Blink/WebKit-based browsers would be open to dropping their -webkit
prefixed gradient support. By our own judgement in bug 1107378, the web
(particularly the mobile web) requires -webkit-gradient support at the
moment. I can't imagine webkit/blink browsers jumping at the chance to
break all those sites.

> And/or drop but taking care of -moz- when standard properties are not there with the CSS unprefixing service [2] enabled for the Web (what we are planning but not yet done [3]).

Two other options:

(3) Add back -moz gradient support and consider it an unfortunate bit of
web legacy that we have to support, for the time being at least. (This is
functionally equivalent to your second option, but is easier & more direct.)

(4) Add back -moz gradient support, behind an about:config flag, and keep
it disabled *only* on Nightly for the immediate future, to evaluate how
bad things are & how far we can get with evangelism (without affecting
release users).

Right now, I'm leaning towards (3). But if we really do let this change
ride the trains in any way, it's looking like we need to be prepared to do
tons of evangelism and help web developers rewrite their gradients (since
the conversion between -moz-linear-gradient & linear-gradient syntax is
non-obvious in many cases). Maybe we can provide a tool to automate the
conversion process so there's no guesswork and less need to check
documentation; but it's still going to be a lot of evang.

[Boris Zbarsky]

On 7/14/15 8:23 PM, Daniel Holbert wrote:
> I can imagine we *might( be able to get Microsoft to join us & drop -ms
> prefixed gradient support. But I'm extremely skeptical that
> Blink/WebKit-based browsers would be open to dropping their -webkit
> prefixed gradient support.

Yeah, I don't see it happening any time in the foreseeable future. :(

>> And/or drop but taking care of -moz- when standard properties are not there with the CSS unprefixing service [2] enabled for the Web (what we are planning but not yet done [3]).

This seems strictly worse than just restoring the code we already had,
which is well-tested and all that... Certainly in the short term.

> (3) Add back -moz gradient support and consider it an unfortunate bit of
> web legacy that we have to support, for the time being at least. (This is
> functionally equivalent to your second option, but is easier & more direct.)
>
> (4) Add back -moz gradient support, behind an about:config flag, and keep
> it disabled *only* on Nightly for the immediate future, to evaluate how
> bad things are & how far we can get with evangelism (without affecting
> release users).

Is the breakage we've seen so far typically cosmetic or functional (i.e.
missing background or unreadable text due to missing background)? If
it's cosmetic, I would probably lean toward option 4. Otherwise,
probably option 3.

In either case, I think we should contact the sites we already know
about _and_ see whether we can raise awareness of this problem amongst
web developers in general...

Though there is also a possible option (5): pick one of the prefixed
gradient syntaxes (whichever one maps most simply to the spec?) and spec
that all UAs must implement that prefix. Or something.

-Boris

[Jet Villegas]

Let's back out the -moz unprefixing as Daniel suggests. It appears that
there's far too much breakage in the wild to drop the prefix now, and it's
not cosmetic. There's also a report that the -moz syntax is baked into
consumer hardware that may never get updated [1] :-/

We're bringing a vendor-legacy-prefixing spec proposal to the CSS working
group to cover Mobile Webkit, and I think the spec should cover gradients
as well.

--Jet

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1182775#c6

> _______________________________________________
> compatibility mailing list
> compat...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/compatibility
>

[Mike Taylor]

On 7/14/15 21:13, Boris Zbarsky wrote:
> In either case, I think we should contact the sites we already know
> about _and_ see whether we can raise awareness of this problem amongst
> web developers in general...

Jason, is this on DevRel's radar? Maybe a hacks blog post?

> Though there is also a possible option (5): pick one of the prefixed
> gradient syntaxes (whichever one maps most simply to the spec?) and spec
> that all UAs must implement that prefix. Or something.

I had this thought too. If we end up having to spec and support some
version of -webkit- gradient _and_ the standard variant I wonder if
that's enough to ditch -moz-prefixed entirely.

I filed [1] as a placeholder to investigate this.

[1] <https://github.com/whatwg/compat/issues/1>

--
Mike Taylor
Web Compat, Mozilla

[Daniel Holbert]

On 07/14/2015 07:23 PM, Mike Taylor wrote:
>> Though there is also a possible option (5): pick one of the prefixed
>> gradient syntaxes (whichever one maps most simply to the spec?) and spec
>> that all UAs must implement that prefix. Or something.
>
> I had this thought too. If we end up having to spec and support some
> version of -webkit- gradient _and_ the standard variant I wonder if that's
> enough to ditch -moz-prefixed entirely.

As one data-point: this solution wouldn't have fixed the instance of this
bug with Facebook.

FB sends us *just one* gradient declaration, and it's -moz prefixed. (And
they send other browsers *just* their own vendor prefixed versions.) See
https://bugzilla.mozilla.org/show_bug.cgi?id=1183504#c6 -- this is to cut
down on the amount of CSS that they're sending over the wire.

I wouldn't be surprised if other sites do similar things. But maybe this
exclusive-browser-specific-CSS sort of thing is rare enough that we can
deal with sites like that on a case-by-case basis.

[L. David Baron]

On Tuesday 2015-07-14 17:23 -0700, Daniel Holbert wrote:
> (3) Add back -moz gradient support and consider it an unfortunate bit of
> web legacy that we have to support, for the time being at least. (This is
> functionally equivalent to your second option, but is easier & more direct.)

> Right now, I'm leaning towards (3). But if we really do let this change
> ride the trains in any way, it's looking like we need to be prepared to do
> tons of evangelism and help web developers rewrite their gradients (since
> the conversion between -moz-linear-gradient & linear-gradient syntax is
> non-obvious in many cases). Maybe we can provide a tool to automate the
> conversion process so there's no guesswork and less need to check
> documentation; but it's still going to be a lot of evang.

I agree that for now we should do (3). But we should probably also
put -moz- gradients behind a pref (that's on everywhere) but that
allows people to experiment with what happens when it's off.

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

[Mike Taylor]

Good point, we have seen some of this on other sites as well (usually
high profile sites).

[Anthony Ricaud]

When we implement unprefixed versions, are we sending a deprecated
warning message in the devtools for websites still using the prefixed
version?

[Anthony Ricaud]

On 15/07/15 15:41, Mike Taylor wrote:

[Jason Weathersby]

Do we think it is a good idea to put together a hacks post to shine some
light on this?

On Wed, Jul 15, 2015 at 6:41 AM, Mike Taylor <mi...@mozilla.com> wrote:

> On 7/14/15 22:19, Daniel Holbert wrote:
>
>> On 07/14/2015 07:23 PM, Mike Taylor wrote:
>>
>>> Though there is also a possible option (5): pick one of the prefixed
>>>> gradient syntaxes (whichever one maps most simply to the spec?) and spec
>>>> that all UAs must implement that prefix. Or something.
>>>>
>>>
>>> I had this thought too. If we end up having to spec and support some
>>> version of -webkit- gradient _and_ the standard variant I wonder if
>>> that's
>>> enough to ditch -moz-prefixed entirely.
>>>
>>
>> As one data-point: this solution wouldn't have fixed the instance of this
>> bug with Facebook.
>>
>> FB sends us *just one* gradient declaration, and it's -moz prefixed. (And
>> they send other browsers *just* their own vendor prefixed versions.) See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1183504#c6 -- this is to cut
>> down on the amount of CSS that they're sending over the wire.
>>
>> I wouldn't be surprised if other sites do similar things. But maybe this
>> exclusive-browser-specific-CSS sort of thing is rare enough that we can
>> deal with sites like that on a case-by-case basis.
>>
>
> Good point, we have seen some of this on other sites as well (usually high
> profile sites).
>

[Boris Zbarsky]

On 7/15/15 11:12 AM, Jason Weathersby wrote:
> Do we think it is a good idea to put together a hacks post to shine some
> light on this?

I do. I'd go further than a hacks post if we have other outreach
options... The sites that are doing this prefix-only stuff are breaking
the web, and we really want them to stop.

-Boris

[Mike Taylor]

On 7/15/15 10:12 AM, Jason Weathersby wrote:
> Do we think it is a good idea to put together a hacks post to shine some
> light on this?

Dietrich and I co-authored a post that was published today:

<https://hacks.mozilla.org/2015/08/making-and-breaking-the-web-with-css-gradients/>