Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Eric Shepherd (Sheppy)]

Those notes should also be useful for the docs team if we need to document
this stuff before it makes it into a spec.

On Wed, Aug 15, 2018 at 6:18 PM Mats Palmgren  wrote:

> On 8/14/18 12:52 AM, Jonathan Watt wrote:
> > On 08/08/2018 21:08, Boris Zbarsky wrote:
> >> Are we writing down something that could get turned into a spec?
> >
> > I've got a bunch of messy notes that I hope will be of some use for
> that, but
> > no, so far I have not attempted to create draft spec text to replace the
> text in
> > CSS UI 4.
>
> It'd be awesome if you could write this down somewhere while you
> have the details somewhat fresh in your mind.  I'd be happy to
> contribute what I know about this too.
>
> Those notes would be an excellent starting point for a discussion
> with other vendors about speccing this property, which I believe
> is necessary if we're going to converge UAs to something that
> is "compatible".
>
>
> /Mats
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Mats Palmgren]

On 8/14/18 12:52 AM, Jonathan Watt wrote:

On 08/08/2018 21:08, Boris Zbarsky wrote:

Are we writing down something that could get turned into a spec?


I've got a bunch of messy notes that I hope will be of some use for that, but
no, so far I have not attempted to create draft spec text to replace the text in
CSS UI 4.


It'd be awesome if you could write this down somewhere while you
have the details somewhat fresh in your mind.  I'd be happy to
contribute what I know about this too.

Those notes would be an excellent starting point for a discussion
with other vendors about speccing this property, which I believe
is necessary if we're going to converge UAs to something that
is "compatible".


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Jonathan Watt]

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

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Mats Palmgren]

The plan to ship -webkit-appearance looks good to me, fwiw.

On 8/14/18 12:46 AM, Jonathan Watt wrote:
> On 08/08/2018 16:31, Mike Taylor wrote:
>> On 8/7/18 5:16 PM, Jonathan Watt wrote:
>>> 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.
>>
>>   From the "Possible ways forward" from that link, I think option 5
>> makes the most sense. We can always spec this in the Compat Standard,
>> if the issue is never resolved.
>
> That's the option that I think makes most sense too, ...

I fully agree that speccing -webkit-appearance is the way forward.
I doubt it's possible to spec the rendering in detail, but it should
be possible to spec at least the list of valid values and what each
value does on various HTML elements in loose terms to the degree that
any differences between UAs is unlikely to cause any major web-compat
issues.

Having a spec for it, even if it's vague, is good since it prevents
UAs from introducing new values without going through the normal
CSSWG process.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Jonathan Watt]

On 08/08/2018 21:08, Boris Zbarsky wrote:
> On 8/7/18 6:16 PM, Jonathan Watt wrote:
>> 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.
> 
> Are we writing down something that could get turned into a spec?

I've got a bunch of messy notes that I hope will be of some use for that, but
no, so far I have not attempted to create draft spec text to replace the text in
CSS UI 4. To be frank the behavior of '-webkit-appearance' in Chrome/Safari is
so inconsistent and messy that would be a ton of work. I think it would make
most sense to start by trying to get Google to remove some of their infrequently
used values from the Web to reduce the amount of spec work that's needed. It
would also help a great deal to restrict the elements that individual
'-webkit-appearance' values can be applied to, since spec'ing all the weird and
wonderful edge case permutations would be a waste of time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Jonathan Watt]

Hi Mike,

On 08/08/2018 16:31, Mike Taylor wrote:
> Hi Jonathan,
> 
> On 8/7/18 5: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.
> 
>  From the "Possible ways forward" from that link, I think option 5 makes 
> the most sense. We can always spec this in the Compat Standard, if the 
> issue is never resolved.

That's the option that I think makes most sense too, although I'd like to see if
we can convince Google to remove some of their infrequently used values from the
Web. In that case it seems like there would be some value in supporting a new
value to allow resetting the property.

>> 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.
> 
> This is very cool. Thanks for fixing sites for our users! We'll keep an 
> eye out for weird regressions.

Much appreciated, thank you. :)

Jonathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Boris Zbarsky]

On 8/7/18 6:16 PM, Jonathan Watt wrote:

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.


Are we writing down something that could get turned into a spec?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Mike Taylor]

Hi Jonathan,

On 8/7/18 5: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.


From the "Possible ways forward" from that link, I think option 5 makes 
the most sense. We can always spec this in the Compat Standard, if the 
issue is never resolved.



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.


This is very cool. Thanks for fixing sites for our users! We'll keep an 
eye out for weird regressions.


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Chris Peterson]

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 

Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Jonathan Watt]

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