On 12/31/2015 11:37 AM, Martin Thomson wrote:
> If we intend to continue to support these,
(We do.)
> and particularly if we
> anticipate more prefixed rules in future
(Happily, I don't anticipate too many more of these -- at least, the
space of -webkit-prefixed features is bounded, because implementors &
standards bodies have realized that vendor prefixes are bad for
web-compat, so they aren't being used for new features. The Chrome/Blink
team, at least, have committed to implementing new features behind their
equivalent of about:config prefs instead of vendor prefixes:
https://www.chromium.org/blink#vendor-prefixes )
> I think that it would be
> worthwhile providing developers with a more visible notice regarding
> their status. Something like the deprecation warning we use for DOM
> APIs [1] could be useful. Otherwise, I worry that the warnings will
> go unnoticed.
I'm not sure I agree. We discussed this a bit during a web-compat
session in MozLando, and there are several reasons not to bother with a
warning in this case (and note that these reasons do not apply to the
deprecated DOM API scenario that you brought up):
(1) Dubious effectiveness: The existing web content where these
warnings would be *most* warranted -- content with webkit-prefixed CSS &
no fallback -- is (by definition) *exactly* the web content whose
developers are not bothering to test Firefox. So, any warning that we
add would have little chance of reaching that intended audience of
developers; it'd just add background noise to our users' error consoles.
(2) Dubious usefulness: Given that these prefixed features will now
Just Work in Firefox, and given that we're saying they're de-facto part
of the web & committing to supporting them (and so are all other modern
browsers), then there's no clear benefit/motivation for web developers
to remove these from their sites. So, for web developers that *do* see
these warnings, it's not clear why they should care & address them (and
take time away from fixing other things).
(3) False positives: There are many "legitimate" ways that authors can
use prefixed properties, and if we added a warning, we'd probably need
to exclude those cases. Some examples of "legitimate" use cases, which
would require some careful extra instrumentation to detect:
CSS with standards-based fallback after it:
.box {
display: -webkit-box;
-webkit-box-orient: horizontal;
/* lots more -webkit-box stuff */
display: flex;
flex-direction: row;
/* lots more modern-flexbox stuff */
}
CSS with standards-based fallback in a completely different CSS rule
(not sure how often this happens, but it's conceivable):
.legacyBox {
display: -webkit-box;
}
.modernBox {
display: flex;
}
...
<div class="legacyBox modernBox">
"@supports"-guarded conditions (where the author is explicitly checking
for browser support before using the legacy feature):
@supports (display: -webkit-box) {
.foo { display: -webkit-box }
}
JavaScript that sets the prefixed style and modern style in separate
statements (i.e. separate passes through the CSS parser, so we have no
way of knowing that a standards-based version is coming up):
elem.style.display = "-webkit-box";
elem.style.display = "flex"; // use modern flexbox, if supported
Each of these "legitimate" scenarios would require a different set of
heuristics to skip the warning (and I'm not sure we'd be able to skip
the warning at all, for the 2nd and 4th cases).