Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing clean-up on a few wikis, but I usually just get chewed out by the local admins for not discussing every change in detail (which obviously doesn't scale for fixing 200+ wikis). I would love to hear ideas for how to address this problem.
Ryan Kaldari On 3/30/11 4:57 AM, Marcin Cieslak wrote: >>> Aryeh Gregor<[email protected]> wrote: >>> The fact that you don't see the difference in the two screenshots is not >>> reassuring. In one, the search icon is clearly misplaced as it is >>> overlapping the border of the search input, in the other it is not. This is >>> caused solely by the DOCTYPE difference. >> Now I see it, yes. They're cropped very differently, so I didn't spot >> the difference when flipping back and forth. I was looking at the >> boxes' edges, and didn't notice the difference in the position of the >> magnifying glass. Anyway, this is exactly the sort of minor bug where >> it's not worth it to worry too much about whether it breaks for a >> while -- certainly not to the extent of having to budget for the >> change, nor to the extent of reverting a change that's been in place >> for so long. To the extent of reviewing before deployment, sure, >> maybe. Doesn't bother me if we deploy without reviewing for this kind >> of thing, but I can see why you'd prefer to be more careful. > Sorry for bringing this up, I was the one who cropped those screenshots that > way. > Those screetshots are best viewed within the context of: > > http://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/82155#c15527 > > By the way, I am not happy with the "reverted" version either, the search > icon is a bit too high and the box is overlapping the line. > In general, this CSS is probably too fragile and to prone to > font/platform/resolution/zoom factor/whatever problems. > > I really hope that getting proper CSS for HTML5 in *core* is just a matter of > checking few workarounds in Vector and maybe Monobook and that's it. > > However, for successful Wikimedia deployment, there is a different problem: > > For years already I was fighting a happy-go-lucky approach to styling > in MediaWiki:Common.css/Monobook.css as well as in individual templates. > (My battleground is Polish Wikipedia). There are dozens of quick fixes > and workarounds there also for various browsers issues. It is indeed > the problem they haven't been sometimes properly communicated back upstream. > > Actually I was wondering - and we need to discuss this with > plwiki's tech community - to literally throw out all of > MediaWiki:Common.js/Common.css > code and "see what breaks" once Wikimedia moves to HTML5. > Maybe this could be a sort of heads-up message given out to the community > once we are ready to switch over to HTML5? > > We have a huge backlog in converting our JavaScript already > (ResourceLoader for one, removing all the library code we should > get rid of once we have jQuery). Only most rudimentary > fixes to sitewide js has been done so far and maybe some gadgets. > > While I deeply believe we can quickly sort out all the issues with > the MediaWiki codebase. The real problem is with the global > css/js cruft, that major Wikipedias accumulated over years. > I am afraid that's something that WMF developers cannot really handle, > since they didn't put this in there in the first place, but > maybe this is the problem with just few major wikis only? > > Maybe there aresome things that would help, like > unning copies of major wikis on prototype (including the content!) > or something like that. Any suggestions? > > //Marcin > > > > > > > _______________________________________________ > 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
