Forum:Monobook styling continues

March tweaks
Though those users who still use Monobook might disagree, we haven't forgotten about them. Styling does still continue on that skin, though it is, admittedly, of lower priority than other maintenance issues. Still, in the past week we've:
 * implemented italic titling (through the use of title
 * moved section edit buttons to the left, so they stay with the section titles, rather than bunch up at the bottom of the page
 * removed the massive white borders that used to appear around image thumbnails
 * returned the left-column links to your current Game of Rassilon scores and our chat room (though tinkering still continues on this one; they don't load on every page load, and seem to prefer to show up when you're editing a page)

Users from other wikis may wonder why we're talking about styling Monobook as if it's a new thing. Well, that's because it is. On this wiki, we had only very minimal CSS styling until long after the Oasis/Wikia skin became Wikia's standard. Thus we're having to go back and create something we should've done in 2006. However, because Wikia have by now moved on themselves from Monobook, we're offering Monobook on only an "as is" basis. Some things just won't look as good/the same in Monobook as they do in Oasis. And you'll always be devoid of certain features, like the Game of Rassilon, the ability to fully use blogs.

However, Monobook retains the true advantage of being a much faster skin in which to edit, because it doesn't use (that much) javascript. You may find it enjoyable to edit in the skin, particularly if you have a number of very repetitive, minor edits to perform.

That said, all users are reminded to at least occasionally edit in Wikia so that you can understand what your edits look like to 95% of the users of this site. Monobook is definitely the "second control room" of the site. It is really only meant for editors, because the average user won't — or in the case of un-logged-in or mobile users, can't — switch to it.

Also, please be aware that any community messages are not relayed to the Monobook skin. If you mainly use Monobook, please occasionally switch to Wikia so that you can keep up with community news.

Please feel free to use this thread to note any changes you'd like to see in Monobook. 16:42: Fri 02 Mar 2012


 * Is it at all possible to make it so that images in Monobook aren't forced under the character box in their vertical alignment? It's a bit messy how images do not align with their intended paragraph, but rather are pushed down. In particularly short articles or articles with a very short intro, but pictures towards the top, it can be particularly awkward. NileQT87 talk to me 02:33, March 6, 2012 (UTC)
 * Your request is unclear. What's a "character box"?  Please give concrete examples of the problem.   14:26: Tue 06 Mar 2012
 * For example, if you look at Alistair Gordon Lethbridge-Stewart (and many other pages with pictures), you'll notice that the topmost image in the body of the text (this is only a problem in Monobook) is pushed down level with the character info box on the left-hand side, even though it would better if it were in-line with the text the picture relates to. For example, on the Brig's page the child!Brig comic image and the mustachioed soldiers image are pushed down far into the lower paragraphs because of an image backup, though they wouldn't be if the top picture were allowed to sit in the Early Life section. Do you see what I'm saying? NileQT87 talk to me 00:10, March 7, 2012 (UTC)
 * Thanks for the example. What you're seeing is not a monobook-specific phenomenon.  Well, not exactly, anyway.  The two skins are, in one measurable sense, rendering the pages in exactly the same way.  All pictures in the body of an article are limited by the length (or, if you prefer, height) of the infobox. The topmost position any bodypic can occupy in any article regardless of skin is the bottom of the infobox.  So if you were to take a ruler and measure the vertical distance between the line underneath the article title down to the top of the pic of the Brig as a kid, you'd get the same measurement, regardless of skin (and, indeed, regardless of browser width).  The kid is always the height of the infobox away from the article title.


 * The difference that you're seeing is the fact that the overall body width of an article in monobook is about 300px wider than one in wikia. The article space is wikia is 680px wide, exactly. Consequently, the picture appears in a lower section of text, even though it's the exact same vertical distance from the article title.


 * There's absolutely nothing I or anyone else can do about this. Monobook is just plain wider than Wikia. Text will obviously flow differently.  This is the primary reason why Wikia eliminated all the skins back in 2010, and why they basically avoid talking about Monobook altogether these days.  As I've said many times, Monobook is provided on an as-is basis.  It is impossible to plan for a page to look the same at 680px width as it does at 900px.


 * The other thing about Monobook is that it just deeps increasing in width the wider you open your browser. So if you decide to open your browser across your three, non-mirrored 25" monitors, you're going to run into text flow problems that aren't present on a single, 19" monitor. Wikia doesn't do this.  It stays 680px, period.  You can affect text flow by changing the size of the text, but not by messing with browser widths.  Some people don't like Wikia's inflexibility in this regard, but it does have a definite layout & design advantage.


 * All that said, there are things you can do to make pages work better in both skins, assuming that the average reader isn't going to open her browser on more than one 25" widescreen monitor:
 * Write a decent lead. This is especially true of televised episodes, where there's more of a chance that you'll have a lot of pics.  Some of these pages have a lead that's basically just "PAGENAME was the Xth episode of SERIES# of PROGRAMME."  That's not a lead for a story page.  A lead must establish notability on both in-universe and out-of-universe fronts.  Once you've done that, you'll probably find that your lead, or at least lead+synopsis extends below the infobox.  Once that happens, body pic order will render as intended in both skins. Examples of pages with adequate amounts of text are Planet of Giants — if the article actually had pics in the body, they'd be in the right place — and Snakedance — if the article had plot text, the pic would be in the right place.
 * If you can't fill out most of the variables in an infobox, consider carefully whether it's worth using it. It is not this wiki's policy to require infoboxes on every page.  A good example of a page that's better without an infobox is Argus.  If you tried to use an infobox, it'd make the placement of the two pics impossible.  Well, not impossible, but it would mean that one of the pics would be below the body of text in the wikia skin.  (And remember, even though we're talking mostly about monobook in this thread, wikia must be considered first, in any layout question.)  Basically, an infobox should add to the visual effect of a page.  It should not overwhelmingly dominate it.  Short articles, in particular, should cause the editor to pause and think about whether an infobox makes sense.  If your infobox is longer than your body text (in wikia) then it may be better to go without the infobox.
 * Make the infobox as short as possible. This would generally mean avoiding using a one-line-per-entry structure.  At the Brig, you could squeeze about 20px outta the thing by simply listing his AKAs with simple comma separation.  bp should also, in my view, be avoided in infoboxes (even though that's why it was created).  Bulleted lists take up a lot of vertical space.
 * Be judicious with the AKA field. Don't put anything there that happened on only one occasion.  For the Brig, the first three are fine, but "Captain Munro" doesn't particularly rise to "infobox notability".
 * If you've got more than about three appearances for something, you might want to consider creating a list of appearances page.
 * Always make the first pic on a page with an infobox float left, like is happening at the Brig. This at least will make it visually balance with the pic in the infobox on the right, and it will ensure that the pic is as close to the top of the page as pics are allowed.
 * That said, never, 'ever put a body pic on the left of a list of bulletised points. The bullets will always collide with the pics. (There likely is a CSS workaround for this problem, but it's beyond low on my list of priorities.  If you really want the pic to be on the left, convert the bulletised list into a proper paragraph.)


 * 18:08: Thu 08 Mar 2012


 * Typing the previous, lengthy response up made me consider the operation of monoboook in greater detail. The fact that Monobook is essentially an "infinite width" skin means it requires a different design ethic.  For this reason, I've changed the way that TOCs are handled in monobook versus Wikia.  You should find that this will greatly enhance pic flow in monobook, at a greater variety of browser widths.  The "child Brigadier" pic should now appear in the right section of the example page, in monobook.     07:58: Sat 10 Mar 2012

Restyling finished (April 2012)
Monobook has now been fully restyled. Although the odd maintenance tweak might happen from here on out, it's pretty much the way it's gonna look. If you haven't looked at the wiki in Monobook lately, give it a try! If you edit there every day, make sure that you clear your cache frequently.

I'm really looking for some feedback, though, because some performance issues have been noted by admin on other wikis. If you're having any noticeable lag after clearing your cache please let me know. Be sure to include your browser and browser version in your response. 19:09: Sat 14 Apr 2012


 * Nice job with the skin. It's based on the Spanish Pokemon wiki's MonoBook skin, right? I've been looking at their version jealously for months. Anyway, I've had a look through a few pages and I'm not experiencing any lag in Chrome 18. --Klock101 talk to me 01:03, April 19, 2012 (UTC)