Warcraft Wiki talk:Styling

Much of this is taken from Project talk:Village pump. See Schmidt's edit on that page.

The history of this discussion is available in the history of Project talk:Village pump. It was moved in one swoop (ver batim, not removing or adding any text) to this page. Then I refactored it into a manageable document. Schmidt 02:39, 22 June 2006 (EDT)

For reference, these pages look like this in Nostalgia and Monobook:

• Interface Customization as ElusiveByte edited it: nostalgia monobook
• Main Page: nostalgia monobook
• WoWWiki:Main Page Dev 3: nostalgia monobook
• Project:Templates: nostalgia monobook

The origin of this project

17 June 2006

Mikk sent Rustak (the premier admin) some CSS patches for him to upload, to make the interface easier to read.

18 June 2006

user:ElusiveByte removed formatting from Interface Customization [1] due to not looking good with Nostalgia skin. Explanation:

The proper markup is much more important than the style. I made sure the default rendering of the markup looks fine in other skins. It currently looks horrible in Nostalgia, which I use because I have a hard time reading the default skin. If you want the links to look pretty, until such time that you are willing to spend the effort to use *class* definitions from the skin stylesheets to create the desired style, no style is better. Even if you have to author the custom classes for whatever skin you use. It's you who wishes to add the "style"; you should do the work. You should not do it half-assedly then make those who use other skins suffer. Usablity is much more important that style. - ElusiveByte.

Later the explanation was restated:

Kirkburn, I did a poor job of curbing my frustration when I wrote that. I appologize to all. Just so everyone understands, I removed the custom, hard-coded colors from that page, and explained in my summary how in-line styles hurt users of other skins. When I came back later, the author of the in-line styles had reverted my change with no address to the real problem. I got frustrated and wrote what you see above. I don't see that it was all that insulting. Had I left out "half-assedly", it would have been much more professional, though.

I stand by my general statement: If you want custom colors for certain layout elements (borders, div backgrounds, etc), those colors should be defined in classes in the css file of the skin of your choice. Then, if users of other skins wish to implement your classes in the css file for their skin, they will do that work. Using inline styles for colors forces every viewer of that page, regardless of what skin they have selected, to see those colors. That is not a very friendly practice. It makes it very hard for me to read with my desired skin.

So you see, when I made the page readable for everyone (but less colorful), and the original author — [the original author was Mikk, but Tarog was the one who did it] — simply reverted my change, I took that as an offense myself. My comment originally appeared on that specific page's discussion page. Taken out of context of that discussion, yes, it sounds harsh, so I wrote all of this to explain my position. ElusiveByte 18:49, 21 June 2006 (EDT)

This was the first complaint that reached Schmidt's eyes about general formatting. He had expressed a similar concern some time back, but with no answer. [2]

21 June 2006

Schmidt got the idea to start a CSS project whereby we can assemble the code that would benefit us all and Rustak could copy it and upload it to a CSS file if he so desires, until he sets up the wiki so that we can edit it straight from the interface here. This code would take full advantage of classes and allow all other skins to port each class as desired, use the same classes, or drop classes (which would render any container classes as such as just a plain container).

The ongoing discussion was moved to this discussion page as described at the top of this page in one edit [3]. See above for the link for the edit on the other side.

---

Ongoing discussion and general questions

Order of battle

Right now, I don't suppose I would be averse to taking a task here in this project – I mean beyond what I've already been doing. But my goal is to first get the wowwiki skin completely classed first. Why? Because short of 100%, it looks like one person uses another skin. That aside, still the far and away vast majority use the default skin. So, what needs to happen?

We need:

• a list of templates that call wacky colors
• go ahead and add their contents to a relevant class at Project:Styling/wowwiki.css
• someone to go through special:random on a different skin to see what formatting other than colors is a hinderance to legibility

We might want to go from there, assemble the code, and simplify it however we can. However you guys want to format it is fine by me. We can just say <nowiki> and <pre> at the beginning, and end the tags at the bottom, just so we can get good readable code. I can definitely go through to see how we can best render stuff. We should decide as soon as possible what we want for Main Page, but I guess that's still outstanding and out of our reach, unless someone is willing to make an executive decision. Maybe I'll ask Rustak sometime about that, to see if I have that liberty.

If anyone thinks of any other tasks that need to be done, by all means, post here. By doing so, you're not volunteering, but just noting that something else needs to be done. If you are willing to do whatever task, let us know so we can work together in a reasonable fashion. Schmidt 18:57, 22 June 2006 (EDT)

Horrendous-looking page, with all the examples

This page is looking horrendous. Anyone got any ideas how we can split this thing up? I'd like the examples to stay intact so that we can refer to them so that everyone can get a glimpse of what CSS can do, but beyond that, we don't need them glaring in our faces. If anyone has any bright idea, execute it.

Colored boxes

A lot of the problem is simply colors. I don't see us escaping layout parameters in templates completely, but all color info in them has to go. I suggest we set up a number of color classes, like roughly so (examples suitable for wowwiki skin, but I need to double check the actual color balances):

• .box-red { background: #301818; border: #703030 1px solid; }
• .box-blue { background: #181830; border: #283870 1px solid; }

Now, if we want bands as displayed today, we'd simply do something along the lines of

{| class="box-red" style="border-left: none; border-right: none; more layout parameters"
  stuff here along with {{makemewide}}
|}

On a sidenote I suck a little on the cooler points of CSS. Is it possible to pull multiple classes into an object without defining several elements? It _might_ be a good idea (but imo not strictly necessary) to have a class that defines e.g. margins for bands and such, in case we want to vary them over skins. (Though I can't see why right now)

--Mikk 11:20, 22 June 2006 (EDT)

Oh, class="class1 class2". I r the sux :-)   --Mikk 11:39, 22 June 2006 (EDT)

One reason why you'd want to use classes to define margins is just to simplify code.

div class="fat tall happy"

sure beats

div class="happy" style="{{fatcss}} {{tallcss}}"

if you get my drift. Obviously you don't want to make a class for every little thing, but if it's going to be used on several pages, it's better to class it. Especially when remembering the situation with the other skins. Schmidt 12:21, 22 June 2006 (EDT)

Colored inline texts

You're absolutely right that colored inline texts need to be in the CSS. We're using pretty much the same colors as WoW right now, which works well in-game with its dark backgrounds, and in the WoWWiki skin, but they're pretty much unreadable with bright backgrounds. They need to be tweaked to be a LOT brighter in bright skins. --Mikk 11:34, 22 June 2006 (EDT)

Having common files for dark and bright skins?

Viewing the problem more from a 10,000-foot view, I think we can separate the color problem into two areas for all the skins we're currently using:

• Dark background skins
• Bright background skins

I'm thinking we can move 95% of the color info to just two files that get included from each of the skins. --Mikk 11:37, 22 June 2006 (EDT)

Yes, I agree, for the coloring aspect of formatting. Also consider placement of elements. You know we have float-right stuff, and they might not look good on other skins. I haven't checked either way, but it would have to be determined. Schmidt 12:03, 22 June 2006 (EDT)

Images

I don't know how much we need to bother ourselves with this, but some of the images just don't work with bright backgrounds. Some of them even break with anything other than #000000. Check out the images in e.g. {{guild}} and {{player}}, for example.

Can anyone think of a way to pull different images based on skin? Or some parameter defined in the skin? --Mikk 13:05, 22 June 2006 (EDT)

Yes, very possible, but tricky. It would involve (in those cases) giving a cell a background-image, and the cell would have to be sized sufficiently (not necessarily exactly, though). It is doable, but possibly more work than we're interested in. Schmidt 13:25, 22 June 2006 (EDT)

Aaaaahhhh cool, didn't think of that one. Nice one. And yeah we can probably just ignore it for the first run of fixing stuff. Nice to put on a future to-do list though imo! --Mikk 13:29, 22 June 2006 (EDT)

Colour codes

Please can we stick to using six digit colour codes - as in, #001122, rather than #012. It's frustrating to keep having to change between the two, when six digit codes are far more frequently used :) -- Kirkburn 18:24, 22 June 2006 (EDT)

Do browsers mess up when both are present? I don't give two hoots about whether we use 3 or 6 digits, but I started out on 3 because it was simpler, and so I'm used to it. I wasn't aware that any browsers had any issues with it. I guess we can stick with 6. Fine by me! Schmidt 18:57, 22 June 2006 (EDT)

Darktable

I have no idea where to put this or who to address this to. I have a request for the darktable class, but I know nothing about CSS. I would like to be able to just use the class and not worry about any formatting, and from the discussion that seems best for everyone. However, I have been making very large tables and the darktable class doesn't show any divisions between rows/columns. Is there some way we could modify this class or create a different class that is the same only which as the bgcolor="#303030" for the rows? See Thousand Needles quests for an example of what I mean. If there is a class out there already that will do this, let me know and I will start using that and get rid of those bgcolors. All I really need is some divider between rows and columns, because for such a huge table the plain darktable class is rather difficult to read. --Jiyambi t || c 02:04, 23 August 2007 (UTC)

It might help to know what table you're wanting to modify. Lacking that, my recommendation is simply to say class="darktable" cellspacing="2" for example, to make sure there is some spacing in between them. The dividers won't show up unless you add a different background color for the rows or the cells. I'm afraid that doesn't help a lot, but it might do something for you. Again, it would help to know what table you want to modify. Schmidt 04:40, 23 August 2007 (UTC)

The table at Thousand Needles quests is what I am trying to modify, and I am currently using that method. I was just told not to use the bgcolor because it messes up things on other skins, but that table classes were okay. Here is an example of what that sort of table looks like without the bgcolors: Teldrassil quests. It turned out not to be so bad, so this isn't a big deal. I do prefer the Thousand Needles quests though. --Jiyambi t || c 05:52, 23 August 2007 (UTC)

Ok, good that you don't want to use bgcolor. Then class each row or cell according to the different color that you think is good, and then describe that class in mediawiki:wowwiki.css. Personally I've been making modifications to mediawiki:common.css, but the changes there have been related to class colors and such. If they get redefined later, I can migrate the old definitions to wowwiki.css later. But the formatting you want to do is rather isolated to wowwiki.css I think. And you might want to pick a fairly obvious class, and in wowwiki.css, maybe even include a reference to the page that is using it. It might help for future definitions and so on. tbh, I'm not sure whether non-admins can edit the CSS. If you can't, tell me on this talk page what class you're going to be using and how to define it, and I'll make the change. (Personally I prefer the Teldrassil quests.) Schmidt 08:17, 25 August 2007 (UTC)

Thanks for the response, Schmidt. I think for now things will be fine as they are, I have begun modifying every table I see to use the darktable class (like the one on the Teldrassil quests page), without any bgcolors. So no new styling will be needed at the moment. However, thanks very much for the info, and if I come across something that does require different styling, I will follow your advice (and probably come here and ask more questions :P ) -Jiyambi t || c 22:26, 25 August 2007 (UTC)

Demos and clarification

Prescribing and assigning classes

You can say <div class="foo bar"> and it would try to find both the ".foo" and ".bar" statements individually, and would apply both sets of descriptions (or prescriptions) to the div. Obviously there's opportunity for overlap. I'm not sure what happens there, but we could test it or just avoid it. I think that answers your question there, but let me give a demo quick.

In the CSS file, as an example:

.vote { text-align: center; margin: 1ex auto; width: 40em; }
.red { background-color: #c33; color: #9ff; }

In the text:

<div class="vote red">We're sorry. Your vote is failed. Thanks for playing.</div>

Would wind up rendered as if you had this instead:

<div style="text-align: center; margin: 1ex auto; width: 40em; background-color: #c33; color: #9ff;">We're sorry. Your vote has failed. Thanks for playing.</div>

We're sorry. Your vote has failed. Thanks for playing.

It would really be undesirable to name a class red, though, because not all skins will necessarily want to use red, so it would be a misnomer then. It is better to name a class something like "affirmative" and "negative" such as I stated on the project page. That said, just because .vote and .red are defined (in this example) on a given stylesheet doesn't mean that all other stylesheets will even have that class. For each of the class specifications (<div class="X Y"</div>) no class definition is found in the stylesheet, it simply acts as if there was no class specification for that element. The browser will then render it as though it would render anything else of that element. (DIV as block, SPAN as inline, with normal text formatting, etc., as though the class wasn't even there, in some respects.)

Template usage

We would still use templates. For instance, think of the classification span.tab that I have on Project:Styling/wowwiki.css. We would still use stuff like {{articletab}}, but in the new scheme of things, it would be written differently.

As it is now:

<span style="border-left:1px solid gray; border-top:1px solid gray; border-right:1px solid gray; font-size:8pt; padding:2px 8px 0px 8px;">article</span>

As it would become:

<span class="tab">article</span>

And as I said before, we would have different formatting schemes for each skin, and if a skin didn't have class .tab, then it would render it simply as normal text. And there's nothing wrong with that. But of course, we could also write all the CSS pages so that they all have the same classes, so that on each page they're all distinguished but in a favorable way.

Table formatting

One other fine point of CSS:

table { .... } // styles the table itself
table * { .... } // styles every child of all table elements, such as cells

Why do you want to do this? You have TH, TR, TD, etc. In order for it to look decent, you can do this. This way you can make the frame of the table white, or black, or whatever color you like, and then make each cell's background another color. This makes it look neat and professional. See Project:Known vandals and the source code, to see an example. Making use CSS classes would reduce code size immensely.

On the other hand, you may prefer this:

table { .... } // table itself
th { .... } // table header (in wiki code, that's whenever you use ! to begin a cell)
td { .... } // table cell definition (in wiki code, that's when you use the pipe character)

Along with whatever else you can think of that belongs here.

Specific examples

Sounds to me like we have sound theories, but I figure some examples might help, so here goes:

(Ohbtw, the "Nostalgia" skin is an exeception to all these rules, I think. It really wants a minimum of formatting. Possibly all box/bandish things there should just be a modicum of margin + border.)

--Mikk 12:39, 22 June 2006 (EDT)

Bands

dark.css

 warning { background: #301818; border: 1px solid #703030; }

wowwiki.css

 band { border-left: none; border-right: none; margin: 1ex 3em; }

{{band-warning}}

 <table class="warning band">......{{makemewide}}</table>

Yes, {{makemewide}} will enforce wideness in all skins. I just do not see a way to work around that without crashing in under floats. =(

Or perhaps we just want to start out with having both "warning" and "band" in dark/bright.css. It can always be overridden in skins if anyone wants to?

I suggest the following bands:

• warning (probably render different shades of red in all skins)
• notice (turquoise in wowwiki skin? others?)
• info (like infoline today, pretty moderate. probably a very pale color in bright skins)

--Mikk 12:39, 22 June 2006 (EDT)

A stub

wowwiki.css

(should be identical to our template CSS code)

.stub { width: 70%; margin: 0.2em 1em 2em 1em; border: 1px #222222 solid; background: #444444; color: white; }
.stub .explanation { font-size: smaller; font-family: Tahoma, sans-serif; } // taken straight from {{stub/Explanationcss}}

I don't think you can do .stub .explanation, but we could think of something anyways, such as .stubexplanation or something more manageable. Schmidt 13:53, 22 June 2006 (EDT)

Oh? That's how it's done for toc headings. Check out .toc h2 in the stylesheet for instance. (Granted, the 2nd one isn't a named class but I'm pretty sure I've done this with two named classes elsewhere) --Mikk 04:17, 24 June 2006 (EDT)

LIB MR ducks! I guess it does work. pfft. Schmidt 08:26, 24 June 2006 (EDT)

demo.css

(just an example showing that these stylesheets can be quite different – originality is in want)

.stub { width: 80%; margin: .5ex; border: 2px #fff outset; background: #000; color: #ffcc99; } // black background, orangish text
.stub .explanation { font-size: larger; font-family: Humanst512, sans-serif; } // a different font

code

{| class="stub"
 |-
 | [[Image:Stub.gif|stub]]
 | This article or section was tagged as an '''Accuracy stub''' because someone wants the accuracy of this article
 checked and/or sources cited. <div class="explanation">
 * You might want to cross reference information from a WoW database such as [[Allakhazam]]
 [http://wow.allakhazam.com] or [[Goblin Workshop]] [http://goblinworkshop.com/], [[Thottbot]] [http://thottbot.com/], 
 or an official [[Blizzard]] source such as the [http://www.worldofwarcraft.com World of Warcraft Community Site].
 * You can [[Project:Find or fix a stub|help expand it]] (correct problems or cite sources) by clicking {{edittab}} above.</div>
 |}

result (demo.css)

This article or section was tagged as an Accuracy stub because someone wants the accuracy of this article checked and/or sources cited. You might want to cross reference information from a WoW database such as Allakhazam [4] or Goblin Workshop [5], Thottbot [6], or an official [Blizzard] source such as the World of Warcraft Community Site. You can help expand it (correct problems or cite sources) by clicking  Edit  above.

The main page

Probably just start out with differentiating bright from dark. Example for dark here (fake colors):

mainpage-table { max-width: something; }
mainpage-table h1 { font-family: Verdana, sans-serif; font-size: x-large; text-align:center; }
mainpage-table h2 { font-family: Verdana, sans-serif; font-size: x-large; }
mainpage-h1 { border-top: red 1px; border-bottom: dark red 3px; background: very dark red; }
mainpage-s1 { background: very dark red, slightly different from h1 }
mainpage-h2 { border-top: blue 1px; border-bottom: dark blue 3px; background: very dark blue }
mainpage-s2
mainpage-h3
etc..

<h1>Welcome to WoWWiki</h1>
<table class="mainpage-table"><tr><td class="mainpage-h1"><h2>Heading Here</h1></td><tr>
<tr><td style="mainpage-s1">content here...</tr><tr>

... or something like that. I don't quite remember the design elements.

A navigation box

This isn't the prettiest of examples, but it might show some more things to look for, in formatting.

wowwiki.css

.navbox { float:right; text-align: center; font-size: 85%; 
          font-family: Tahoma, sans-serif; background-color: #282828; 
          margin: 0em 0em 1em 2em; padding: 1ex; border: 1px solid #000000; }
          // taken straight out of {{listboxformat (float:right; text-align: center; margin: 0em 0em 1em 2em; padding: 1ex;)}}

.navboxtitle { border-bottom:1px solid; }

demo.css

.navbox { background-color: #693; margin: 1ex auto; padding: 1ex;
          border-top: 1px solid #cf9; border-bottom: 1px solid #cf9; }
.navboxtitle { display: inline; }

code

{| class="navbox"
 |
 <div class="navboxtitle">[[Gems]]</div>
 [[Shadowgem]]<br />
 [[Malachite]]<br />
 .....
 |}
 This is the rest of the article's text. 

result

Gems  [Shadowgem]  [Malachite] .....

This is the rest of the article's text.

Misc

Heads-up re: IE7

The wowwiki stylesheet is pretty badly broken for IE7. Or perhaps I should say that IE7 is badly broken. Either way evil things happen to the toolbars where they end up underneath graphics and become unclickable. I've alerted Rustak that we need stylesheet editing access yesterday. --Mikk 03:46, 6 July 2006 (EDT)

I'd like to take time to confirm that the wowwiki stylesheets are still broken for IE7. -- Zespri 16:08, 14 August 2006 (EDT)

Row templates

When it comes to numbers, left alignment makes it hard to read (Especially since the headers are centered.)--DruidJ 17:47, 21 November 2006 (EST)

Content Overflow

Currently, wowwiki.css, does not definite a min-width. so everything is at 100%. Problem is, this results in the site shrinkigng with the browser window, along with every block element no specified a fixed width, yet the content will overflow and spill out of site's layout. This is a result of the fact the site is, correctly, using div's for the layout, not tables, but ends up looking like a horrible jumbled mess and unreadable. Setting a min-width to the body would be fine in most cases, but because this is dynamic content, and the layout is floated, it's not desirable or that effective. Therefore, it really needs to have everything floated down to the level of dynamic content, so that the site will wrap (and thus scroll) to fit it's article content at smaller resolutions, while being the full width of the browser at all other times. You'd probably have to mess around with the floats in practice, but theorectically, #content, #bodyContent, #contentSub, and #wikiPreview all need to be set with float: left, with all block elements added by users, defaulting to float: left too, which can manaually be changed by users inline if needed. Plus, a clearing element at the end of user content as default would probably be needed. Or there's the quick fix.. min-width: 80em or something smilar between 60em and 90em, which is going to be merely a guess based safety net. As you may have gathered, non-table layouts are not helpful to dynamic content as css relies so much on explicit (which need to be known or predicted) widths being specified to keep content from overflowing, except when floating every single element on the site that will contain dynamic content. Sometimes i think microsoft should have worked on the css spec instead.. ¬_¬ -- Zeal Vurte 02:22, 18 December 2006 (EST)

Lists

I've noticed the list indentations (left margins) between ordered and unordered lists are inconsitant and rather annoyingly i might add. Can we get this changed so they match, or is there a reason for it?
Also, floating something left next to a list does not respect margins or padding on the list (not even the list items), resulting in the float overlapping/underlapping the bullets points. It's a known issue (in all browsers) i've not seen resolved yet or suggestions made for workarounds given that could be implemented. --Zeal (talk - contr - web) 13:26, 23 December 2006 (EST)

Alright. I most likely noticed this before too, and if I did, it also annoyed me. Tor the sake of testing to make sure whatever happens works, here goes:

1. test
2. test
   1. test
3. test

test

test? Schmidt 03:50, 11 August 2007 (UTC)

• forgot to test this
  • test?

test?

• test?

1. la de da

1. lameness
   1. more of the same

I know it's a little late to respond now, but this looks better, right? Schmidt 03:59, 11 August 2007 (UTC)