On 11/12/06, Sebastian Moleski <sebmol(a)gmail.com> wrote:
On 11/12/06, Simetrical
<Simetrical+wikitech(a)gmail.com> wrote:
On 11/12/06, Brion Vibber <brion(a)pobox.com> wrote:
I've reverted r17507 and r17518 after getting
massive complaints
immediately after they went live in today's site update.
I'd like to ask that people please try to refrain from changing core
styles like this without testing it against the actual site usage; for
instance the prominent main pages of English and German Wikipedia and
their site-specific CSS/JS.
We've gone through this dance enough times in the last few weeks I think
we should all be able to realize that it's kind of disruptive and should
be avoided.
Sorry, sorry . . . it's rather poor of me to constantly forget about
custom styles when most of what I'm committing is UI stuff.
Unfortunately some disruption is inevitable for this kind of stuff,
which I suppose suggests it should be condensed and spaced out to the
extent possible, with ample forewarning every time a batch is going to
be committed. Maybe I should make a branch where this kind of
potentially disruptive stuff can be committed, and then we can let
stuff accumulate there for a couple of months and until we announce
all the changes and merge to trunk? Does that sound like a good idea?
Changes to the layout should be proposed before they are made. They need to
be tested with current wiki dumps on the largest projects so the actual
effects of the changes can be determined. Once that is done, common and skin
custom stylesheets can be adapted. And only after all that's done, they
should be committed.
The current way of doing things is a nightmare from a customer service
position because users will notice that something's wrong, some of them will
ask at the VP or equivalents, and very few will even know what the problem
is or what caused it. So some of those few end up running to IRC to find a
developer who can help fix things by either reverting or explaining. All the
while, discussion continues, often at a level quite beyond what one would
expect based on the triviality of the actual issue. Then accusations are
made that somebody was arbitrarily deciding "major things" without process.
Unfortunately, I'm not making this up. This actually all happened when the
category trees were added and the way category pages were displayed changed.
Ridiculous? Absolutely. Yet ample reason to work so it doesn't happen again.
I don't think it's a good idea to jump through hoops when adding new
features. That's just silly. Clear announcement is necessary when a
change will *break preexisting functionality* such as user
customizations. I don't think discussion or announcement is necessary
for the implementation of
http://bugzilla.wikimedia.org/show_bug.cgi?id=1578, for instance.
On 11/12/06, Luiz Augusto <lugusto(a)gmail.com> wrote:
Not related to this specific change, but since some
weeks ago someone
changed something and now every table displayed in some namespaces in some
wikis is... white.
Examples
http://pt.wikisource.org/wiki/Especial:Newpages
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost
They were like that forever until I bugged the devs to supply a patch,
but that broke other things so I reverted it later. It's due to a
flawed implementation of non-main-namespace coloring that many wikis
have adopted, not a software issue: in Monobook the backgrounds of all
namespaces are white.
Adding the following to MediaWiki:Monobook.css *should* fix it
(filling in the correct color instead of #F8FCFF, which is the color
used by enwiki):
table { background-color: #F8FCFF; }
.ns-0 * table { background-color: white; }