On Wed, Feb 10, 2010 at 8:03 PM, Trevor Parscal <tparscal(a)wikimedia.org> wrote:
Not all changes made in the HTML output of Vector were
made arbitrarily
or gratuitously as is being assumed here.
No one was assuming that. I pointed out several differences that
*are* gratuitous, in that they do not provide any functional
difference that should logically be related to users' skin choice.
Either they're good and should be in all skins, or bad and should be
in no skins, or they're neutral and may as well be in all or none just
for consistency's sake. None of them has any reason to be present in
one skin but not another.
In i18n, you have to be careful about using the same
message key in
multiple places, because as the context changes in each of those places,
the likelyhood of the message being ideal in all situations in all
languages decreases. Similarly, relying on identical HTML structure and
classification for dissimilar skins is a bad practice to keep scripts
and hacks from having to be customized is a fatal mistake.
Why? If the skins can be given identical (or nearly identical) HTML
structure, then give it to them, and the scripts will work. Or some
percentage will break, fine -- but you don't have to deliberately
break all the rest too.
Vector has a distinctly different approach to..
* Navigation structure - the namespaces, variants, views and actions
are all separate lists
The only substantive differences I can spot here at a glance on
localhost are that namespaces are their own list (is this actually
necessary for some reason? surely the gap can be added with CSS
somehow), and there's a "Variants" list which is empty (which is
invalid HTML, incidentally). Plus a lot of stuff has different
classes and id's for, again, no apparent reason.
* Right-to-left compatibility - lists are actually
generated
backwards in RTL modes (look at the personal tools in Monobook in
RTL - it's not in the correct order, and in Vector it is, even on
IE 5.5)
Then why shouldn't all other skins be changed to do this too? This is
a bug in Monobook, and you've only fixed it in Vector rather than in
all affected skins. Why?
* Search - it's not a portal anymore, it's
part of the skin and it's
in the top right which has many incompatibilities with layout
assumptions made for other skins
Such as? The HTML looks virtually identical in any case.
* Footer structure - Links to places and
information like copyright
notices are separate lists and rendered differently
The differences in appearance here look like they could be replicated
in CSS without using different HTML for the two skins, offhand.
These are not "gratuitous" changes in the
UI, and the effects they have
on the resulting HTML output aren't either.
I haven't yet seen any case where a difference in the HTML is actually
necessary to achieve some effect. There might be one or two, I'm
happy to admit that, but there are sure a lot of differences that are
*not* necessary, and those should be fixed.
What happened to column-one and column-content? Well,
Vector doesn't
layout the same way that Monobook does, and given that styles meant for
those IDs were and would continue to be a problem.
What do you mean by this? Anyone who tries applying styles that
affect the layout of one skin, to another skin, is obviously going to
see their styles break one way or another. The problem will not be
helped by changing the id's -- it will break either way. But changing
id's will break scripts unnecessarily, too. And break styles that
would happen to work across skins.
If we want to change id's to more sensible names, then why don't we do
it in Monobook too? The only reason not to is that it would break
scripts and styles -- but switching to Vector as default would do that
anyway. (I don't think we should do this; I think Vector and all
other skins should just use the silly old names for backward
compatibility.)
I took the oportunity
to name them more sensibly, and avoided future issues of people putting
things in global CSS that obviously belonged in Monobook.css.
Can you point to where this is actually a problem? I can point to
very clear evidence that using different classes/ids across different
skins is a problem. On enwiki there's a gadget: "Compatibility
function to run scripts only tested on Monobook on the new Modern
skin. Required for using Twinkle or Friendly (along with many other
scripts) with the Modern skin." Look at the source code:
http://en.wikipedia.org/wiki/MediaWiki:Gadget-modernskin-thunks.js
If that doesn't indicate that changing IDs creates real problems that
can be easily solved by just using the most similar ID in the original
skin, I don't know what does.
Not to mention the lengthy list of skin-related commits that have to
change four files at once because they're changing some HTML output.
If you maintain separate HTML where not strictly necessary, any change
to the similar HTML must be made in all relevant files. This is what
we're trying to *avoid* with a new skin system.
Look at
the revisions to shared.css and you will see allot of things that were
moved to skin-specific CSS files that should have never been in the
global one.
I just looked briefly through every last revision ever made to
shared.css since it was created in January 2007. I found exactly one
that moved code from shared.css to skin-specific CSS:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/30734
Can you point me to all this other stuff that was moved out of
shared.css? On the other hand, there are a *lot* that move code from
skin-specific CSS to shared.css. That was the point of the file, in
fact.
As to the point of the two empty divs, they are
absolutely used, and
they are specifically noprint for good reason. The tags area actually:
<div id="page-base" class="noprint"/>
<div id="head-base" class="noprint"/>
What are they used for? JavaScript? If so, why doesn't the
JavaScript just create them when necessary, as jsMsg does? And what
JavaScript is this that isn't useful for Monobook?
As for the tag: <div id="mw-js-message"
style="display: none;"/> - this
is used for the ajax watch and unwatch functionality and is also present
on Monobook once you use it. The difference is simply that Vector
provides it ahead of time. I didn't do that
If it's better to provide it ahead of time, then all skins should. If
not, not. (And it's not better IMO, it's needless clutter.) Why
should there be any difference between skins here?
Also, Why would you want to print the contents of the
head? The
printable version of Vector has been carefully crafted. If there's a
noprint class somewhere, it's on purpose.
Monobook relies on
.noprint,
div#jump-to-nav,
div.top,
div#column-one,
#colophon,
.editsection,
.toctoggle,
.tochidden,
div#f-poweredbyico,
div#f-copyrightico,
li#viewcount,
li#about,
li#disclaimer,
li#privacy,
#mw-hidden-catlinks {
/* Hides all the elements irrelevant for printing */
display: none;
}
from commonPrint.css. If Vector had used #column-one instead of
#head, it wouldn't need class="noprint" here. (As it is, it could
just add #head to the list and ditch the class. Along with all the
other places it uses class="noprint" -- that's most useful for
user-added content, not interface elements.)
Finally, those comments are useful for debugging
purposes. If they are
offensive, they can be removed - obviously they have no other functional
properties.
It's not a question of whether they should be removed or not. There's
no conceivable way that they're useful in Vector but not in Monobook.
They should be in both or neither.
The same goes for every single thing I pointed out. Some of them are
good changes (like reordering lists for RTL), so those should be in
Monobook too. Some of them are, IMO, bad changes (like adding empty
elements that are only used as script hooks), so they shouldn't be in
Vector either. But there is no reason for a *difference*.
So, I hope that answers some of these questions.
I'm glad to answer more.
My basic questions is: how do you expect us to get rid of all the code
duplication we have now if not by merging as much HTML-generating code
as possible, and thereby also making the generated HTML the same where
possible? The only sensible way for us to proceed is to have all
skins output the same HTML, except where there's a *good* reason for a
*difference*. Not just a good reason to do it one way or another, but
a good reason to do it one way in one skin, *and* a good reason to do
it differently in another skin. Anything else results in duplicated
code and creates headaches for us and scripters alike.