Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec -moz-linear-gradent / -moz-radial-gradient, if you want #111

Open
dholbert opened this issue Dec 19, 2018 · 4 comments
Open

spec -moz-linear-gradent / -moz-radial-gradient, if you want #111

dholbert opened this issue Dec 19, 2018 · 4 comments

Comments

@dholbert
Copy link

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1337655#c53 , we've discovered that the web seems to depend on Firefox-flavored browsers (as determined by UA sniffing) supporting legacy -moz prefixed gradient functions. (So far, -moz-linear-gradient in every case I think, but perhaps the other syntaxes (radial, repeating-linear/repeating-radial as well.)

Some sites do UA sniffing and then send Firefox only this prefixed syntax, with no fallback (including large properties like Facebook (in the past), Google properties like gmail (in the past) and blogger, and frameworks/deployments like Eclipse RAP and Zimbra.)

I'm not sure if this is worth speccing, since it doesn't need to impact other browsers' behavior. (The situation is different from e.g. -webkit prefixed gradients, where a fraction of the web just serves those up to all browsers with no fallback.) But @gsnedders requested a github issue for this, so here you go. :)

@gsnedders
Copy link
Member

I'm not sure if this is worth speccing, since it doesn't need to impact other browsers' behavior. (The situation is different from e.g. -webkit prefixed gradients, where a fraction of the web just serves those up to all browsers with no fallback.) But @gsnedders requested a github issue for this, so here you go. :)

I think there are two options here:

  • Have everyone support the -moz- prefixed functions (ugly, but better)
  • Tie this to the navigator compatibility mode, and require it for the Gecko value (IMO less good, given it preserves inconsistencies between browsers)

@dholbert
Copy link
Author

dholbert commented Dec 19, 2018

I think there are two options here:

* Have everyone support the `-moz-` prefixed functions (ugly, but better)

I don't think other engines have much incentive to do this, and I can't see a very strong practical case for them to do that.

* Tie this to the [navigator compatibility mode](https://html.spec.whatwg.org/multipage/system-state.html#concept-navigator-compatibility-mode), and require it for the Gecko value (IMO less good, given it preserves inconsistencies between browsers)

That makes more sense to me, and matches the state of the web better.

In other words, I think it's accurate to model this (i.e. support for -moz prefixed gradients) as a Gecko-specific quirk/bug, which web content has to accommodate Gecko having. (In practice, that accommodation is trivial on the part of web developers -- just don't use these gradient functions with completely broken/unwanted values, or else your site may look broken in specifically Gecko when it honors your unwanted gradient where other engines do not. :) )

@miketaylr
Copy link
Member

Tie this to the navigator compatibility mode, and require it for the Gecko value (IMO less good, given it preserves inconsistencies between browsers)

This would also work generally for the -webkit- prefixed things that we don't have strong evidence for needing in Gecko, e.g. webkit prefixed fullscreen.

@gsnedders
Copy link
Member

I have a very strong preference of avoiding things forking based on that unless we absolutely have to (i.e., mutual incompatibility being a requirement of the platform); I'd much rather have browsers be interoperable unless we absolutely cannot avoid it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants