Much of this is taken from WoWWiki talk:Village pump. See Schmidt's edit on that page.
The history of this discussion is available in the history of WoWWiki 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
- WoWWiki: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
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. Template:Tlink and Template:Tlink, 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)
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 CSS file:
.vote { /* whatever format all vote-classed elements will have, such as */ text-align: center; margin: 1ex auto; }
.red { /* whatever format all red-classed elements will have, such as */ background-color: #c33; color: #999; }
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="margin-top: 1ex auto; background-color: #c33; color: #999;">We're sorry. Your vote has failed. Thanks for playing.</div>
(As a side note, I don't understand why the band goes all across the screen, seeing that the margin is auto for left and right.)
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 it 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 WoWWiki:Styling/wowwiki.css. We would still use stuff like Template:Tlink, 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 WoWWiki: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; }
- Template:Tlink
<table class="warning band">......{{makemewide}}</table>
Yes, Template:Tlink 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 Template:Tlink
- 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)
- 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 [[WoWWiki: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.
|
Probably just start out with differentiating bright from dark. Example for dark here (fake colors):
mainpage-heading { 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 }
etc..
--Mikk 12:39, 22 June 2006 (EDT)
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 Template:Tlink
.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
This is the rest of the article's text.