In theory at least all new checks in the last few years have been specific in this way -- either testing for capabilities or if that's not doable looking for particular versions (like the IE fixes which are tied to known releases of IE, or the Gecko and WebKit fixes which check if they're on a version of the engine prior to the bug fix.)
Definitely keep an eye out and make sure we don't regress on that, everybody! :) -- brion vibber (brion @ wikimedia.org) On Aug 17, 2009, at 7:41, Aryeh Gregor <[email protected]> wrote: > Back in May 2004, Gabriel Wicke was creating a neat new skin called > Monobook. Unlike the old skins, it used good semantic markup with CSS > 2 for style. Gabriel made sure to test in a lot of browsers and made > up files full of extensive fixes for browsers that had problems. > > One such browser was the default KDE browser, Konqueror. Even > relatively web-savvy people have barely heard of it and never used it. > He was nice and checked whether it worked properly in his new skin > anyway. Since it didn't, he committed a quick fix in r3532 to > eliminate some horizontal scrollbars. Then everyone forgot about it, > because nobody uses KHTML. > > It turns out there was a slight problem with his fix. He loaded it > based on this code: > > var is_khtml = (navigator.vendor == 'KDE' || ( document.childNodes && > !document.all && !navigator.taintEnabled )); > > The problem here is pretty straightforward. A bug fix is being > loaded, without checking to see whether the bug exists. The fix is > loaded for all versions of KHTML past, present, and *future*. If the > KHTML devs fixed the bug, then they'd have a bogus stylesheet being > loaded that would mess up their display, and they couldn't do anything > about it. > > Well, nobody much used or uses KHTML. But it just so happens that in > 2003, Apple debuted a new web browser based on a fork of KHTML. And > in 2008, Google debuted another browser based on the same rendering > engine. And if you add them together, they now have 6% market share > or more. And we've still been serving them this broken KHTML fixes > file for something that was fixed eons ago. > > Just recently, in WebKit r47255, they changed their code to better > match other browsers' handling of "almost standards mode". They > removed some quirk that was allowing them to render correctly despite > the bogus CSS we were serving them. And so suddenly they're faced > with the prospect of having to use a site-specific hack ("if path ends > in /KHTMLFixes.css, ignore the file") because we screwed up. See > their bug here: <https://bugs.webkit.org/show_bug.cgi?id=28350> > > I had already killed KHTMLFixes.css in r53141, but it's still in every > MediaWiki release since 1.5. And this isn't the only time this has > happened. A while back someone committed some fixes for Opera RTL. > They loaded the fixes for, yes, Opera version 9 or greater, or some > similar check. When I checked on Opera 9.6, I found that the fix was > degrading display, not improving it. > > Sometimes we need to do browser sniffing of some kind, because > sometimes browsers don't implement standards properly. There are two > ways to do it that are okay: > > 1) Capability testing. If possible, just check directly whether the > browser can do it. This works best with JS functionality, for > instance in getElementsByClassName in wikibits.js: > > if ( typeof( oElm.getElementsByClassName ) == "function" ) { > /* Use a native implementation where possible FF3, Saf3.2, > Opera 9.5 */ > > It can also be used in other cases sometimes. For instance, in r53347 > I made this change: > > - // TODO: better css2 incompatibility detection here > - if(is_opera || is_khtml || > navigator.userAgent.toLowerCase().indexOf('firefox/1')!=-1){ > - return 30; // opera&konqueror & old firefox don't understand > overflow-x, estimate scrollbar width > + // For browsers that don't understand overflow-x, estimate > scrollbar width > + if(typeof document.body.style.overflowX != "string"){ > + return 30; > > Instead of using a hardcoded list of browsers that didn't support > overflow-x, I checked whether the overflowX property existed. This > isn't totally foolproof, but it sure bets assuming that no future > version of Opera or KHTML will support overflow-x. (I'm pretty sure > both already do, in fact.) > > 2) "Version <= X." If it's not reasonable to check capabilities, then > at least allow browser implementers to fix their bugs in future > versions. If you find that all current versions of Firefox do > something or other incorrectly, then don't serve incorrect content to > all versions of Firefox. In that case, during Firefox 3.6 > development, they'll find out that their improvements to standards > compliance cause Wikipedia to break! Instead, serve incorrect content > to Firefox 3.5 or less, and standard markup to all greater versions. > That way, during 3.6 development, they'll find out that their > *failure* to comply with standards causes Wikipedia to break. With > any luck, that will encourage them to fix the problem instead of > punishing them. It's not as good as being able to automatically serve > the right content if they haven't fixed things, but it's better than > serving bad content forever. > > > I tried to remove some browser-sniffing from wikibits.js, but there's > undoubtedly some I missed. Especially with the large amounts of JS > being added recently for usability/new upload/etc., could everyone > *please* check to make sure that there are no broken browser checks > being committed? This kind of thing hurts our users in the long term > (especially third parties who don't upgrade so often), and is really > unfair to browser developers who are trying to improve their standards > compliance. Thanks! > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
