On Wed, Feb 10, 2010 at 8:03 PM, Trevor Parscal tparscal@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.