Forum:Oasis Tables

Forums: Index > Rin's Travel Agency > Archive > Oasis Tables

		DrakeyC - Crossing the distant night...Wandering the desert sea...The gods' voices are mirages... TALK - 21:52, October 10, 2011 (UTC)
		This grew out of a Dissidia discussion on the IRC. Basically, as we all know anon users and some of our registered users view the Wiki in the Oasis skin, which is noticeably thinner. Thus, many of our tables are distorted, especially if they have a lot of information present. For example, my Monobook friends probably think Magic Materia looks fine, Oasis users, not so much. I think we need to rework our tables so they display properly in Oasis. The way I see it, there are two ways to go about this - simply organize tables in such a way that when Oasis scrunches them up they still look alright. Or, we can use fixed widths so that our tables are sized and appear in Monobook the same way they appear in Oasis. Either way there's a lot of work to be done, it's a matter of deciding which we prefer. Or, and I strongly discourage this way of thinking but it's your opinions, we can decide this is a non-issue and leave things as they are. So, thoughts and opinions please.

http://i790.photobucket.com/albums/yy181/ScatheMote/AnotherSmug.png

		ScatheMote - 21:58, October 10, 2011 (UTC)
		I believe we need to organize our tables that they look good in Oasis first before they can look good Monobook. If they don't look that good in Monobook but look good in Oasis, that's okay. The majority of the people looking at the wiki view it in Oasis, so making it look good there should be a priority. The Magic Materia page without a doubt needs to be reworked completely. We might need to start scanning pages to see what has been scrunched up because of the fixed width.

Template:HenryA Oasis's width is 643px. Tables should be designed for this.

Whenever I do a table that looks decent on Oasis's 100% width with plenty of space, I change its width to 643px so it doesn't look ridiculously wide on Monobook. We should aim to do this for all tables. If we can't make a table look anything but cramped on Oasis, then keep using 100% but make sure it at least doesn't break Oasis. 79.69.204.43 22:01, October 10, 2011 (UTC)

		DrakeyC - Crossing the distant night...Wandering the desert sea...The gods' voices are mirages... TALK - 22:03, October 10, 2011 (UTC)
		JBed, we can modify our Monobook CSS so when a table is set to "100%" width, it go to 643 px? That would greatly simplify the process for sure.

There's no quick way to make all our 100% tables 643px (unless Bluestar can prove me wrong). There is a way to make ALL our tables 100%--which would include infoboxes and everything. We might also be able to change monobook's content-space width to 643px. Although I imagine monobookers would be displeased with that.

I may suggest adding a class called "full" or "full-width" or something which makes the table 643px width, which we'd have to manually add. 79.69.204.43 22:08, October 10, 2011 (UTC)

I can't see any reason to change Monobook's content area's width. We should try to make things look better at a skin, not make them equal. Users should still have the ability to use Monobook's different layout freely for their respective userspace. - 22:13, October 10, 2011 (UTC)

Well, that's the only "quick" method that doesn't require the editing of every page that I can think of ;) 79.69.204.43 22:21, October 10, 2011 (UTC)

This is the breakdown:

1. Monobook will handle tables on modern monitors basically no matter what. People who are playing FF are not going to be on 640x480 screens.
2. Oasis has two areas to work with: the 660px "normal" area, minus margins, and the 1000px full area, also minus margins.
3. Depending on placement, we can shoot for roughly 640 or 980 pixels wide, just as a rough guess (assuming 10-pixel margins on each side). We can play with these numbers for the best look. Fixed width makes it quite easy. Most tables would be in the wider area of the page because of the written content filling the top area occupied by the sidebar.
4. There is no good CSS fix for this other than implementing classes to automatically do each table width in pixels. Oasis sadly takes the whole screen's width when you do percentages, not just the content area. That said, throwing together a "smalltable" and "widetable" class would be easy enough.

I see some pretty easy solutions here, but sadly all table pages will have to be fixed up. Bluestarultor ^BSA 00:43, October 11, 2011 (UTC)

Right. Given that you're the ones who knows coding and Oasis best, I leave it to you Bluesey. What do you think is the best way to tackle this? Doreiku Kuroofangu 00:51, October 11, 2011 (UTC)

Honestly? Just make a couple classes that define the width in pixels and go through the tables cutting out width code and replacing it with the appropriate class codes. For pages of nothing but tables, it's probably best to BS enough of an intro to justify putting everything at the 1000 level below the sidebar for visual consistency. I can whip something up, but an admin will have to implement it and we'll likely be finding more tables with code to replace for months. Bluestarultor ^BSA 01:10, October 11, 2011 (UTC)

Isn't it risky to go wider than Wikia's intended content space, in case they ever decide to use that space for something?Keltainentoukokuu 01:18, October 11, 2011 (UTC)

My view is that they've absolutely refused to use that space for anything, or else it wouldn't be empty for so much of every page. Of all the requests to collapse the sidebar or let us otherwise gain back that space by default, it's fallen on deaf ears. The thing is while they used to have code in place to prevent its use, they've conveniently silently removed it so items can now be explicitly told to go into it. That's tacit approval if I've ever seen any. Bluestarultor ^BSA 01:25, October 11, 2011 (UTC)

They might decide to lift all of our Christmas spirits by making snow flakes fall on the side of the articles with a jingle bells midi on loop that you can't turn off just the day after you finish fixing all the tables. ;) ...hey maybe I should put this to the Wikia suggestion box... just wait for it!Keltainentoukokuu 01:28, October 11, 2011 (UTC)

The point is aside from possible expansions of the bar, I find it unlikely they're going to do much to that area. In general wikis don't have as long of articles as we do. You have to admit some of ours are just plain insane. For smaller pages the bar doesn't matter as much, but we're a large wiki with a ton of content. The fact is they've gone out of their way to remove coding that used to prevent the use of that area.

Although something just occurred to me. Tables are one of the few things I use custom CSS for to allow them to be expanded out into that area. Other people see collapsed tables. That's not to say that we might not be able to get away with implementing my CSS wiki-wide, but it's a consideration. In any case 660 pixels minus margins is simply not large enough to house our information. Bluestarultor ^BSA 01:43, October 11, 2011 (UTC)

They have added a "pop out" function where a table too big for the 660 area will expand on a press of a button. Do you get that with your custom setup too?Keltainentoukokuu 02:07, October 11, 2011 (UTC)

I noticed this earlier, but the feature seems unreliable - it flat doesn't appear for me on the Magic Materia or other pages, and while it appears on our Dissidia pages it only appears for one of the two tabbed tables. Doreiku Kuroofangu 02:10, October 11, 2011 (UTC)

EDIT CONFLICT: @Kelt: I know what they implemented and it was essentially a way to prevent people from putting tables into that space when people were balking at things. What I implemented basically undid all that, pushing the available table width out into the full 1000 pixels and removing the buttons and pop-out functionality. I just got so used to having table be "normal" that I forgot I'd changed anything. Now I understand JBed's confusion when I "fixed" some FF13 stuff. >_>; Bluestarultor ^BSA 02:13, October 11, 2011 (UTC)

So then, we are proceeding on the idea of tables being sized so they appear good under both skins, or under the idea that their size is set to appear as it will under Oasis? Doreiku Kuroofangu 01:22, October 11, 2011 (UTC)

It'll be a fixed size, but assuming most tables take up nearly the full 1000 pixels, it should look just fine in Monobook. Bluestarultor ^BSA 01:25, October 11, 2011 (UTC)

To combine these two diverging conversations, I'm guessing Wikia isn't going to make an exception even for one of their top 10 on table widths, regardless of coding ability. The tables are just going to be collapsed in most cases on Oasis unless we can get people to join and implement fixes. On the other hand, Monobook doesn't have the same restrictions, so anything we do in there will be how we do it, no questions asked. I have no fix for Drake's bugs, though. That's something we'll have to pester Wikia about fixing. Bluestarultor ^BSA 02:42, October 11, 2011 (UTC)

I might be alone with this opinion but I don't think the pop out feature is terrible. Not the best thing ever, but it does do its job. But like Drake above said a lot of tables don't pop out, they are just squashed. This is because the table still fits as long as you squash it, right? For example to make the Magic Materia table into a popping one you'd have to fix its width larger than 100%.(?)Keltainentoukokuu 03:22, October 11, 2011 (UTC)

I don't know anything specific about the coding discrepancies, but I agree with the idea that we should adjust tables to fit better on Oasis because it gets screwed up more easily than Monobook, and let Monobook adjust to those parameters. 8bit 03:54, October 11, 2011 (UTC)

Well, as a possible solution, we could implement what I proposed with the understanding that most users would see a collapsed table. That would at least keep us consistent and things would look fine in Monobook. There's quite simply very little we can do about many of our tables due to the amount of information we keep in them. Really, Oasis was never designed with information tables in mind and IIRC their solution was for each wiki to "fix" (read "gut") their tables to fit. The pop-out really was to ameliorate the fact that for wikis like us that kind of drastic cutting isn't really possible. We probably can't fix the tables wiki-wide, but we can at least ensure things are the same all over. Sure, it's an extra click, and extra clicks are not ideal, but at least people will come in with the understanding that we have a lot of info and getting to it is only one extra click away. Bluestarultor ^BSA 11:34, October 11, 2011 (UTC)

I'd support making expandable tables, but JBed's not going to agree with this plan. Anyone who wants to see what a collapsed table looks like can check out List of Final Fantasy XIII Weapons. Awful or bearable?Keltainentoukokuu 16:09, October 11, 2011 (UTC)

Ohwaow, you predicted by viewpoint. For me, it's not entirely professional.

There once was a time where VII equipment wasn't in a table. link. Just a thought if we wanted to not have to tackle this kind of thing.

And if we really wanted to, we could add a "monobook" class to display:none in Oasis, then use the "oasis" and "monobook" classes so we don't have to sacrifice monobook if tables still work on it. It would mean including information about each table-row-item item twice however (unless we made a template specific for the page, with all parameters duplicated).

If we must settle for the expandable tables, then we must. But first we must think of non-suck methods of avoiding it wherever we can. 79.69.205.56 16:07, October 12, 2011 (UTC)