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). _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
