It would be great if the Omnibus List could be returned to drop down boxes instead of this ugly jumbled lists which are not mobile friendly that User:Rizizuns broke. --ICancerous (talk) 03:09, 7 July 2017 (UTC)
The "Main page" link on the sidebar is actually a link to "INVALID-PAGE," which in turn is a redirect to the appropriate Main_Page link. This seems like it should be fine, but it has the unfortunate side effect of leaving "Redirected from INVALID-TITLE" at the top of the main page after you've used the link. It also causes problems with namespaces, which you can see if you visit a page under a different namespace and then click on "Main page."
HTML layout and the
It's months old, but I'm manually reversing one of Holy Spirit of Hell's good-faith edits to the layout of the main page, because it blew out the width of the page beyond the right edge of the viewport. In doing so, I wanted to drop a quick note about dimensions in HTML layout and the
width attribute. (This isn't meant to shame you or call you out, Holy Spirit of Hell, and the whole reason I'm posting this info here, instead of on your talk page or similar, is that I'm sure there are multiple people who could benefit from it.)
Also, let me say that he following is at the very least vastly oversimplified. (Yes, even considering how long it is.) You should really be getting this sort of knowledge from good sources like Mozilla Developer Network (MDN) or even "meh" sources like w3schools, not from me. Hell, I'm sure at least one thing I'm about to say is just plain wrong... I just don't know which one(s)!)
Specifying dimensions for layout elements in HTML is generally fraught with peril. But there are different levels of peril:
- Specifying exact pixel dimensions (e.g.
width="640px") is evil and should be avoided at all costs, it's one of the main things that makes pages lay out improperly in mobile browsers, just for starters. (Image dimensions are somewhat of an exception to this, though even there it's problematic if images are placed at fixed sizes with no regard for how they affect the content layout on different size screens.) Point size dimensions (
width="10pt") fall into the same category, as points are a fixed-size unit that doesn't scale.
- Specifying dimensions in em units (
width="10em") is slightly better, as ems are related to the font size the content is displayed at, so they'll be autoscaled to match the device's base font size (as long as the font size isn't overridden using a pixel or point size!) Still, while these dimensions autoscale to fit the display size, they're frequently not predictable enough to use for layout. There is also the rem unit (
width="10rem") which is relative to the root font size, making it slightly more predictable since it means the same thing everywhere on the page, no matter what font size is set for that content.
- Specifying dimensions in percentages, if one must specify dimensions at all, is best, and for the most part it's how Godwiki is laid out. But it's important to know what those percentages mean.
- A percentage width in HTML is interpreted relative to the width of the element's container.
- For that reason,
width="100%"is by far the most commonly-used dimension in HTML layout, and it simply means "expand to fill all of the horizontal space available to me".
- Percentages less than 100% are used when elements are placed side-by-side within the same container, to adjust how how the available space is allocated among them. Generally, if percentage widths less than 100% are used, they should be specified on multiple elements laid out horizontally, so that they all add up to no more than 100%, and ideally to exactly 100%.
- Percentages greater than 100% tell an element to grow larger than its container, which is almost never what you want to do and will cause all sorts of problems, from elements overlapping to elements sticking out past the edge of the screen. Browsers will try to correct for some of this (by autosizing child elements to smaller than the >100% container size, for example) but at the very least you'll end up with a jorizontal scroll bar for no good reason.)
So, that's why changing two
width="100%" elements to
width="90%" will never look as intended. The percentages still add up to the same (200%). The total width of the elements is nearly the same. (If their containers are different widths it won't be exactly the same, though. Observe: 110% of
660px but 90% of
360px, so the total width increased from 600+400 =
1000px to 660+360 =
1020px.) But instead of two balanced elements, we've now got one element that doesn't fill its container, and leaves wasted space alongside it, and another element that sticks out of its container and disturbs the layout of the surrounding content. The correct way to adjust the width of
width="100%" elements is to find which of their containers define the respective widths (using something other than
width="100%", either smaller percentages or specific units) and adjust those dimensions, while leaving the elements in question set to
width="100%" as, again, that just means "fill my available space".
Oh, and last but far from least:
- Best by far is when we can avoid specifying widths at all, and allow HTML to flow the elements automatically. The width of block elements will automatically expand to fit the content they contain, up to the size of their containers. That's usually what we want.
width="auto"makes this explicit, and specifying it can be useful if explicit widths were set elsewhere that need to be uninherited.
width="auto"is also better than
width="100%"because it accounts for things like padding and margins, whereas setting 100% width can force elements into those spacers (or force those spacers beyond the screen borders) under certain circumstances.
Love the new main page! Thanks Spode
Sorry for the complete lack of wiki experience, but I logged in today and noticed that the main page had been blanked. I reverted to the latest non-blank instance I found, if that is not the proper procedure, please let me know and fix it correctly. My edit doesn't have the random picture set up correctly. Same thing with this edit, I'm brand new at this, any information on the "proper" way to use the talk page would be appreciated. -Function
This wiki needs a lot of work. Most of the articles here are rubbish. There are about 900 articles total, but about 700 are guild pages (most of which are only a few lines long). Another 100 or so have been marked for deletion because they aren't related to the game. That leaves about 100 pages of actual real game content. Moreover, a ton of the articles don't have categories. I've been trying to add categories, but I can't do it alone. Ultimately, we just need people to write articles on game subjects and stop writing guild articles. Wanna see what I've done, click here. I've given up writing summaries of my edits too. -–BlueStapler
The article count on the main page appears to be wrong. Right now, it says there are 961 articles. I think this number is too low. Specifically, there are 874 "Guilds" articles and 164 "Monsters" articles. Those two combined equal 1038 articles (which is obviously more than 961). I also know that articles from those two categories don't overlap because I've looked at nearly all of them. Add in all the other articles that have been categorized and I estimate there are around 2000 articles. -–BlueStapler
What was the purpose of the 2 September 2012 changes? --BlueStapler 11:14, 2 September 2012 (BST)
Why were the "Picture of the Day" and the "You will be logged in automatically . . ." language removed yesterday? Since I didn't see an explanation of why they were removed, I put them back by reverting to the 15 September 2012 version of the page. If they were removed for a purpose, sorry. Feel free to just undo my 29 September 2012 edits. --BlueStapler 03:51, 29 September 2012 (BST)