Update on WebKit prefix support in Gecko.

[Mike Taylor]

Howdy dev-platform (cross-posting fx-team for maximum synergy),

A quick update on our progress of implementing the WebKit related deps
of Bug 1170774.

In Bug 1213126 we set layout.css.prefixes.webkit to true by default to
let it ride the trains and see if anything exploded. Not surprisingly,
some stuff blew up.

So since Bug 1238827, we're restricting layout.css.prefixes.webkit=true
to non-Release builds.

(If you want to learn what layout.css.prefixes.webkit enables, check out
Bug 1170789 and its CSS deps. One other DOM interface is behind the pref,

Bug 717722: implement WebKitCSSMatrix

This fixes a ton of mobile sites. The Compat Spec stuff was moved into
the Geometry spec making WebKitCSSMatrix an alias of DOMMatrix (after
changing a few things to make it compatible). Apple and Google have bugs
on file to do this, which is cool.)

The following are things that we discovered we needed to be compatible
with the web once you support some WebKit prefixed stuff since turning
on layout.css.prefixes.webkit.

- Bug 1239799: Add support for "@media (-webkit-transform-3d)" as a
media query for 3d transform support.

Turns out some sites using older versions of Modernizr will only do 3d
transforms if you support this. So now we do, and we've specced it:
https://compat.spec.whatwg.org/#css-media-queries-webkit-transform-3d

- Bug 1236979: send 'webkitTransitionEnd', 'webkitAnimationEnd', etc.
events instead of their standard equivalents, if listeners only exist
for prefixed event name.

Lots of (mapping) sites break if you don't do this. And probably more
things we don't know about. Edge, Safari, and Blink all do this, so now
we do too. (Yes, it's gross and weird.) A PR is in progress to get this
specced in DOM.

- Bug 1241021: Support camel-cased and webkit-cased CSSStyleDeclaration
attributes for getting & setting WebKit prefixed styles

Some sites do things like $(foo).css('-webkit-bar', 'baz'). We found a
lot of image sliders break if you don't support this. In order for that
to work, you have to support setting/getting
elm.style['WebkitTransition'] in addition to elm.style['webkitTransition'].

But wait, there's more.

- Bug 1246796: Add support for elm.style['-webkit-foo'] style CSSOM
getters/setters.

Yeah. Apparently every single browser except us supports this (for their
own prefixes too). Fun.

- Bug 1248444: Allow writing to cross origin style sheets

All non-Gecko browsers will let you write to a 3rd party stylesheet via
insertRule (even though CSSOM says this is a SecurityError). We need to
do some careful research here to make sure we can safely do the same.

- Bug 759568: Implement -webkit-background-clip: text;
- Bug 1247777: Implement -webkit-text-fill-color
- Bug 1248708: Implement -webkit-text-stroke

These three are all related to fancy typography effects that sites use
with -webkit- prefixed gradients. If you support gradients but not
these, you're gonna have a bad time™: https://cloudup.com/cVP9AppLMAv

dholbert has a good proposal to ignore webkit-prefixed gradients if you
find -webkit-background-clip: text in the same rule. That should allow
us to ship enable our webkit support without being blocked on these
three bugs (and without regressing Release's behavior for this
typography gradient clipping). See Bug 1248785 for that.

The following things have been disabled:

- Bug 1249134: disable -webkit-appearance alias for now.

The behavior between -moz-appearance and -webkit-appearance is too
different to be useful. We have
https://github.com/whatwg/compat/issues/6 filed to spec the way
-webkit-appearance is used (and how designers rely on it for fancy
forms), and once we're there we'll be following up with bugs against Gecko.

- Bug 1237720: put "-webkit-min-device-pixel-ratio" behind it's own pref
and disable it.

Supporting this fixed a number of mobile sites, but unfortunately broke
Google Docs on HiDPI devices. :( So it's disabled for now. Maybe it will
come back one day.

Things we've already shipped, or are riding the trains:

- Bug 920734: window.orientation / orientationchange event support (44)
- Bug 264412: element.innerText (45)
- Bug 823483: Percentage max-width does not seem to affect contributions
to intrinsic min-width (46)

Lots and lots of sites are fixed as a result. \o/

If you only use Release or Beta, consider using Nightly Fennec to see a
lot of improvements. And please keep reporting strange bustage you see
in Dev Edition or Nightly Desktop that is fixed by toggling
layout.css.prefixes.webkit to false and needinfo? :miketaylr.

Big thanks to bz, dbaron, dholbert, foolip, hallvors, heycam, karlcow,
wchen, roc, zcorpan, and many others for patches, reviews, spec comments.

(OK, this wasn't such a quick update)

later,

--
Mike Taylor
Web Compat, Mozilla

[Johnny Stenback]

While maybe not super quick, this is a great update. Thanks Mike for
all the hard work you and your team have done on pushing hard on this,
and likewise a big thanks to those who have helped implement the
various aspects of this!

- jst

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

[Daniel Holbert]

On Wednesday, February 17, 2016 at 9:11:43 PM UTC-8, Mike Taylor wrote:
> Howdy dev-platform (cross-posting fx-team for maximum synergy),
>
> A quick update on our progress of implementing the WebKit related deps
> of Bug 1170774.
>
> In Bug 1213126 we set layout.css.prefixes.webkit to true by default to
> let it ride the trains and see if anything exploded. Not surprisingly,
> some stuff blew up.

[...]

> The following things have been disabled:

[...]

> - Bug 1237720: put "-webkit-min-device-pixel-ratio" behind it's own pref
> and disable it.
>
> Supporting this fixed a number of mobile sites, but unfortunately broke
> Google Docs on HiDPI devices. :( So it's disabled for now. Maybe it will
> come back one day.

Update: I'm intending to land a pref-flip to turn this feature (-webkit-min-device-pixel-ratio) back on in https://bugzilla.mozilla.org/show_bug.cgi?id=1444139

The reason we backed it out before was because Google Docs used it in combination with a second feature ("content: <image-url>" on non-pseudoelements) which we did not support -- and their site broke if we enabled support for -webkit-min-device-pixel-ratio without also supporting this other feature.

But now we do support that other feature, as of https://bugzilla.mozilla.org/show_bug.cgi?id=215083 -- hooray! So we should be able to reenable -webkit-min-device-pixel-ratio as well and get a webcompat win on mobile. (see webcompat issues tagged off of https://bugzilla.mozilla.org/show_bug.cgi?id=1176968 )

[Mike Taylor]

Hi Xidorn,

> On Jul 8, 2018, at 8:24 PM, Xidorn Quan <m...@upsuper.org> wrote:
> Hopefully with these properties (and one another controlling scrollbar width or style to fulfill thin scrollbar usecases), WebKit and Blink would be able to unship their current pseudo-elements, so that we wouldn't need to implement them to get web compatible.

I’m skeptical about this approach, given that it requires existing and legacy sites to update their code. But I would be happy to be wrong. ^__^

To date the compat issues we care about (because they break layouts) are about assigning a specific width, or hiding the track entirely (via ::-webkit-scrollbar).

> Platform coverage: Desktop

Why not on mobile?

[Tantek Çelik]

On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor <mi...@mozilla.com> wrote:
> Hi Xidorn,
>
>> On Jul 8, 2018, at 8:24 PM, Xidorn Quan <m...@upsuper.org> wrote:
>> Hopefully with these properties (and one another controlling scrollbar width or style to fulfill thin scrollbar usecases), WebKit and Blink would be able to unship their current pseudo-elements, so that we wouldn't need to implement them to get web compatible.

Thanks Xidorn!

> I’m skeptical about this approach, given that it requires existing and legacy sites to update their code. But I would be happy to be wrong. ^__^

MS Edge disagrees as they have been able to *drop* their legacy
proprietary -ms- prefixed properties for scrollbar coloring (which was
often provided as a back-up in ::-webkit- scrollbar code samples) with
very little impact on apparent bugs / compat from their perspective.

We confirmed this last week at the CSSWG meeting with MS Edge PMs.
Waiting on the official f2f minutes for a citation.

> To date the compat issues we care about (because they break layouts) are about assigning a specific width, or hiding the track entirely (via ::-webkit-scrollbar).

Agree with the use-cases "specific width, or hiding the track
entirely" and the new (not yet implemented) scrollbar-width property
addresses those.

https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width

Also we are getting strong informal signals (reconfirmed as of last
week) that there is high desirability to DROP the mess of
::-webkit-scrollbar-* from existing implementations. This is a when
not if, and is largely waiting on sufficient proof of concept that CSS
Scrollbars solves enough use-cases to get at least some sites to
switch or provide both, which likely depends on us shipping the new
standard properties.

Past evidence (which shows how this has changed to be even more
negative on webkit-scrollbars over the past year) until we get last
week's minutes:

https://lists.w3.org/Archives/Public/www-style/2017May/0010.html
"smfr: It was a mistake to leak to web. We don't really like that
people can style scrollbars. We won't enhance and prefer to deprecate
it."

https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html
"TabAtkins: We would like to drop as much of our weird -webkit- stuff
as possible."
...
"smfr: We're interested only in very limited customization of
scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff.
smfr: we're only interested in coloring, and hiding scrollbars."

Not quite an official intent to deprecate / unship, but clearly that's
the direction things are headed.

>> Platform coverage: Desktop
>
> Why not on mobile?

Requires platform specific code that just hasn't been written (yet)
for mobile platforms.

Do you think this feature requires Desktop+Mobile parity/equivalency
before we ship on Desktop?

Thanks,

Tantek

[Mike Taylor]

Hi Tantek,

> On Jul 9, 2018, at 4:36 PM, Tantek Çelik <tan...@cs.stanford.edu> wrote:
>
> On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor <mi...@mozilla.com> wrote:
>> Hi Xidorn,
>>
>>> On Jul 8, 2018, at 8:24 PM, Xidorn Quan <m...@upsuper.org> wrote:
>>> Hopefully with these properties (and one another controlling scrollbar width or style to fulfill thin scrollbar usecases), WebKit and Blink would be able to unship their current pseudo-elements, so that we wouldn't need to implement them to get web compatible.
>
> Thanks Xidorn!
>
>
>> I’m skeptical about this approach, given that it requires existing and legacy sites to update their code. But I would be happy to be wrong. ^__^
>
> MS Edge disagrees as they have been able to *drop* their legacy
> proprietary -ms- prefixed properties for scrollbar coloring (which was
> often provided as a back-up in ::-webkit- scrollbar code samples) with
> very little impact on apparent bugs / compat from their perspective.
>
> We confirmed this last week at the CSSWG meeting with MS Edge PMs.
> Waiting on the official f2f minutes for a citation.

That’s a very cool signal.

Also positive signals. Typically Apple doesn’t drop support for anything that has shipped, at risk of breaking sites… so we’ll have to see how that evolves going forward.

>
>
>>> Platform coverage: Desktop
>>
>> Why not on mobile?
>
> Requires platform specific code that just hasn't been written (yet)
> for mobile platforms.
>
> Do you think this feature requires Desktop+Mobile parity/equivalency
> before we ship on Desktop?

Thanks.

If we have plans to ship on mobile in the future, I would say no. I was mostly curious if this was considered as a “Desktop”-only feature.

Thanks,

[Xidorn Quan]

On Tue, Jul 10, 2018, at 7:36 AM, Tantek Çelik wrote:
> >> Platform coverage: Desktop
> >
> > Why not on mobile?
>
> Requires platform specific code that just hasn't been written (yet)
> for mobile platforms.

Actually I don't really have a plan to support the rendering part of scrollbar color properties on Android. Do you think we should have it?

I don't see any evidence that scrollbar there is a problem for people on mobile. People may want to hide the scrollbar at the end, but other than that, scrollbar styling probably isn't something highly desired.

- Xidorn

[Mike Taylor]

I don’t have strong feelings — you’re right that we don’t have (known) compat issues related to scrollbar customization on mobile (and normally we don’t even see scrollbars). Unsure how important it is for other use cases, like mobile devices with styluses or mice (I believe we do see scrollbars then). But it seems like guessing at this point, since these properties haven’t shipped and sites don’t rely on them yet.