#1791 Support CSS "appearance" unprefixed

Open
opened 4 months ago by Moonchild · 3 comments

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

We currently support -moz-appearance which should become an alias for the unprefixed version, and we need to align our implementation with the spec.

Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching We currently support -moz-appearance which should become an alias for the unprefixed version, and we need to align our implementation with the spec.

I have serious conserns about “aligning spec” of -moz-appearance.

The specific behaviour of the unprefixed spec may badly break our long standing useage of the Mozilla prefixed behavior which is heavily relied upon in the platform, extensions, and themes.

I would be extremely careful because breaking current behavior in this instance would be quite unacceptable. It might be wise to split implementation to only subsume the webkit prefixed version to the non-prefixed spec leaving the Mozilla prefixed version untouched.

This spec seems to be written in the context of extending and standardizing only the webkit prefixed behavior and does not seem to indicate any consideration for the historical behavior of the Mozilla verson upon which we rely on and only strengthens my conserns.

I have serious conserns about "aligning spec" of -moz-appearance. The specific behaviour of the unprefixed spec may badly break our long standing useage of the Mozilla prefixed behavior which is heavily relied upon in the platform, extensions, and themes. I would be extremely careful because breaking current behavior in this instance would be quite unacceptable. It might be wise to split implementation to only subsume the webkit prefixed version to the non-prefixed spec leaving the Mozilla prefixed version untouched. This spec seems to be written in the context of extending and standardizing only the webkit prefixed behavior and does not seem to indicate any consideration for the historical behavior of the Mozilla verson upon which we rely on and only strengthens my conserns.

I guess what it comes down to is whether anything is actually broken by removing the Mozilla prefixed behavior in favor of a non-prefixed implementation that does everything. It seems that from what Tobin is saying, most of the consumers of -moz-appearance are actually internal to the platform.

It seems like aligning -webkit-appearance and appearance should be okay, but it might be worthwhile to test and see what, if anything, would actually be broken by changing -moz-appearance behavior. It’s possible that information could inform whether we go forward with aligning both of these immediately, align only the -webkit-appearance prefix, or have some kind of delay after which we align them after giving extension and theme authors time to adjust their stuff.

There are two basic ways of looking at this that I can see... either that the -moz-appearance API should be kept as more of an internal UXP thing that is potentially allowed for extensions and themes but isn’t really meant for use on websites. The other is that requiring extensions and themes to follow modern web standards including the new spec for appearance is just part of modernizing the browser. I can understand both perspectives, honestly.

What I think we can all agree on though is that we would need to gather information on the impact on themes and extensions as to removing the current implementation of -moz-appearance, and that our three basic options will be to remove it immediately, remove it after a delay for those supporting extensions to keep up, or simply keep it and ensure websites use the non-prefixed implementation.

I guess what it comes down to is whether anything is actually broken by removing the Mozilla prefixed behavior in favor of a non-prefixed implementation that does everything. It seems that from what Tobin is saying, most of the consumers of -moz-appearance are actually internal to the platform. It seems like aligning -webkit-appearance and appearance should be okay, but it might be worthwhile to test and see what, if anything, would actually be broken by changing -moz-appearance behavior. It's possible that information could inform whether we go forward with aligning both of these immediately, align only the -webkit-appearance prefix, or have some kind of delay after which we align them after giving extension and theme authors time to adjust their stuff. There are two basic ways of looking at this that I can see... either that the -moz-appearance API should be kept as more of an internal UXP thing that is potentially allowed for extensions and themes but isn't really meant for use on websites. The other is that requiring extensions and themes to follow modern web standards including the new spec for appearance is just part of modernizing the browser. I can understand both perspectives, honestly. What I think we can all agree on though is that we would need to gather information on the impact on themes and extensions as to removing the current implementation of -moz-appearance, and that our three basic options will be to remove it immediately, remove it after a delay for those supporting extensions to keep up, or simply keep it and ensure websites use the non-prefixed implementation.

I’ve read the spec in detail since I created this issue and there actually isn’t a direct concern since it explicitly allows for implementation specific values (yes I did see the specific mention of the -webkit prefix that “must” be supported -- which is exactly why we ran into compat issues before I enabled them... and yes it did make me roll my eyes :P)

But duplicating this into a limited version for content and current for the platform has advantages (as discussed), not in the least a strict separation of key values that should be chrome-only (as in the UI, not Google’s browser).

I've read the spec in detail since I created this issue and there actually isn't a direct concern since it explicitly allows for implementation specific values (yes I did see the specific mention of the `-webkit` prefix that "must" be supported -- which is exactly why we ran into compat issues before I enabled them... and yes it did make me roll my eyes :P) But duplicating this into a limited version for content and current for the platform has advantages (as discussed), not in the least a strict separation of key values that should be chrome-only (as in the UI, not Google's browser).
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
3 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.