MarioWiki:Proposals

Writing guidelines
None at the moment.

New features
None at the moment.

Remove the dktable-brown class
This is a really minor issue, but something that's been bugging me for a while. Most articles around the wiki relating to the Donkey Kong franchise use a unique brown coloration for their tables (see example). This contrasts with the rest of the wiki, which generally uses white/light gray tables (see example). Apparently, this is something we got as a result of the DK Wiki merge, though I can't find any evidence that it was ever actually used there.

I have two problems with this. First of all, it seems strange to single out Donkey Kong with these. Yoshi doesn't have it, Wario doesn't have it, none of the Mario spin-offs have it, Smash doesn't have it. Because of that, it's kind of jarring, and I don't see why we need a visual indicator like this to separate just one area of the franchise. Second, it just clashes with the aesthetic of the wiki in general (that's why I'm not proposing to fix the first issue just by adding more). We have a pretty clean, Wikipedia-esque look that focuses on whites and grays, with splashes of color used sparingly and when necessary. The alternating browns don't even match the conventions of our other tables, which have the same, consistent coloration for all cells of the same "priority", so to speak.

If this passes, all tables using dktable-brown will be switched to the standard wikitable class used everywhere else on the wiki.

Proposer: Deadline: May 27, 2022, 23:59 GMT

Support

 * 1) Per myself.
 * 2) I like adding color myself to some tables and I'm not opposed to some flair to basic formatting (see Dr. Mario World, Super Mario World, and Yoshi's New Island) but I think the coloration for the dktable is excessive, and I don't think a class specifically designed for a particular series of games is necessary. Wikitable colors for video game articles should at least be consistent with the nav template their series is based off of (ie Mario Party using yellow, Mario RPGs using blue, etc). If we were to color tables, I'd limit it to just the title headers on the top and make sure it matches the nav template color. Super Mario Land is a bit guilty of this so I think we should also establish some sort of standard for wikitable coloration, not just removing the dktable class.
 * 3) Per Waluigi.
 * 4) Per proposal.
 * 5) Yeah, sure.

Oppose

 * 1) - per LGM in the comments. Also, we need to avoid bleeding white from sprites into the backgrounds (Super Mario Land being the exception since in-game "white" is transparency). This is a good thing we have going, for consistency make more like it, not get rid of the one we do have so far.
 * 2) - Per Doc
 * 3) - Per Doc too, I really don't get what's wrong with DK-related templates being brown. Some Yoshi articles have green templates, Dr. Mario World has that too, I don't really see what's wrong with the DK ones personally. It just gives more color to the articles and it's nice.
 * 4) Honestly, the more I look at it, the more I feel like I am not bothered by it. The browns look fine, it's not an eyesore like this.
 * 5) There are times I feel that it couldn't hurt to have a little flair to certain designs for articles. I fear that if this is done, people would criticize us for becoming "too boring" like with the Lubba situation.

Comments
I don't mind the series styling, but what do you think about how some Yoshi's Island tables are handled? See Yoshi's New Island and Super Mario World 2: Yoshi's Island. Dr. Mario World does the same. Are you saying we should remove styling all together or just remove that particular CSS class? Why not just change the css class to both avoid repetitive styling text in the wiki and also change the colors a bit to fit the aesthetic of the wiki? I'm no css expert, but what are the advantages of these styling classes? 16:31, May 20, 2022 (EDT)
 * One immediate advantage I can think of is that you don't need to manually input colors every time you make a table: just insert "raytraceclass" and you'll get the colors you want. 16:37, May 20, 2022 (EDT)
 * Didn't realize it was done there too. I don't care for the Yoshi table styling either for similar reasons, though I don't dislike it as much as the DK one. Maybe it's because the lightest green there is actually pretty subtle, while all the browns on the DK table stand out? Dr. Mario World's is fine but seems a bit unnecessary, but then again I've never played the game so the coloration could very well make more sense there. Personally I'd just prefer to do away with the styling altogether and leave it for cases where it's actually warranted by what's in-game (i.e. characters being associated with specific colors), but if it's going to stay I wouldn't mind either toning things down a bit or doing something closer to what's done with Dr. Mario World. -- 16:41, May 20, 2022 (EDT)
 * The color in Dr. Mario World's table is based on the nav template colors we currently employ for series articles. 16:44, May 20, 2022 (EDT)
 * Ahh that makes a lot more sense. That's not a bad idea, though the way the colors are picked for the navboxes in the first place is pretty arbitrary, so I don't know. -- 16:48, May 20, 2022 (EDT)
 * (edit conflict) The table colors match the navigation templates, which I think is a neat touch (though I'd personally choose another color for Dr. Mario series rather than... sewage yellow, see Navigation templates). I do think probably the headers should be restricted to the color, but it really depends on the context; I don't find the world tables that bad; also the alternating colored row do help guide the eyes around the table. As for what color is determined, I'm seeing a rainbow pattern, with series grouped with each other with appropriate color (Peach is Pink, Mario is red, Wario is purple, Luigi is dark green, Yoshi is light green, DK is brown), and maybe the other colors were up for grabs, with the yellows and blues being the most arbitrary ones. Buuut, that's another topic.  16:54, May 20, 2022 (EDT)

I do find it useful for Donkey Kong Land since so many sprites use white (which bleeds into the background), but I am just a tad miffed that this is being run when I am in the process of an extremely lengthy splitting process of DK games. Doc von Schmeltwick (talk) 13:32, May 22, 2022 (EDT)
 * Well I think there's room for discretion in those specific cases, I wouldn't support changing, say, the Costume Mario table either. That's a great example of this, actually, as the coloration is only used where it's absolutely necessary, which I've been saying this whole time re: using colors. The proposal isn't about prohibiting it entirely anyway, it only affects a single class (though would likely set a precedent). I don't think every single Donkey Kong-related table across the wiki needs to be fully colored in contrast with everything else just because of some sprites. (Not sure what the DKC splits have to do with this though, it'll most likely just be a very simple bot process.) -- 13:55, May 22, 2022 (EDT)
 * Some subheaders needed specifically colored in. But as LGM said, the banding helps to guide the eyes regardless. Doc von Schmeltwick (talk) 14:04, May 22, 2022 (EDT)
 * Yeah, but as Waluigi Time said, I don't think the proposal forbids styling but more of just discontinues using the css class. Though my concern is that maybe we can redesign the css class instead; our wiki already practices some sort of series-consistent styling with example articles, so why not introduce new classes to make it easier? 14:39, May 22, 2022 (EDT)
 * That's about what I'm thinking. Doc von Schmeltwick (talk) 15:09, May 22, 2022 (EDT)

Phase out "in-game model" images
Right now, pretty much across the entire wiki we have two types of model images. "In-game models", which are actually just screenshots of the game with the backgrounds edited out to focus solely on the model, and "data-rendered models", which are assets ripped from the game and rendered in a 3D modeling program. For an example of what I mean, see Gallery:New Super Mario Bros. Wii, which shows both types.

The problem with these "in-game models" is that, again, they're not ripped models, just screenshots of those models in action. This can create multiple problems, particularly with lighting, where two different images of what is otherwise the exact same model can appear different just because of the screenshots they were taken from, or you can have "models" that have an underwater filter over them. Also, while not necessarily a problem inherent to the images themselves, a lot of these tend to be low-quality, and I've noticed 3DS games being a particularly egregious offender. Up until now we've kept them around to show what these subjects look like in-game, but by their very nature, they don't do anything that gameplay screenshots don't do already.

Therefore, what I'd like to do is phase out these kinds of images in favor of data-rendered models (which is a clunky name that we won't need anymore if we do this, woohoo!). Note that I said phase out, and not completely remove or outright forbid. This is meant to be more of a guideline to encourage going forward than a hard and fast rule, because I admit, sometimes there's a good reason for a cropped image of a subject, and we need some wiggle room to accommodate that. In a table of enemies appearing in a game, for example, you're going to want to have a clear image of the subject. That's perfectly fine, but let's not be falsely passing off these cropped screenshots as actual models.

Proposer: Deadline: June 1, 2022, 23:59 GMT

Support

 * 1) Down with them!
 * 2) If I could think of another reason why this proposal is a good idea, it's Yoshi's Story. That game squashes, scales, and wriggles it's sprites so much that these "in-game models" would actually worsen their quality. Let's phase them out before someone turns Bumblebee into an incomprehensible pile of pixels, please.

Oppose

 * 1) - Per my comments. Also, variety is the spice of life.

Comments
Same can be said of sprites, though, and some games/systems are difficult to rip from anyways. In-game is useful for showing native res anyway. Story is actually a good argument against this, since unless you are specifically and deliberately scaling too a screenshot (like some of my PM64 animation uploads), the result will likely look very untrue to how the game actually has it. Doc von Schmeltwick (talk) 19:33, May 25, 2022 (EDT)
 * The same really can't be said of sprites. Sprite rips generally look the same as they do in-game, sure, but the issue with in-game model images isn't purely that they're redundant with screenshots - it's that they're redundant with screenshots and cause several issues that can be fixed by a better alternative. And just because something is difficult to do doesn't mean we should be doing it poorly, but I'm curious of how much an issue this actually is. We have proper ripped models from N64, Gamecube, DS, Wii, 3DS, Wii U, and Switch games on the wiki, and the Models Resource has them in spades. I'm also confused why you think native res is important when it comes to models, because unlike sprites, you're not really getting native res from an in-game screenshot anyway (barring 2.5D games, I suppose), since "native res" of the model can be vastly different depending on how close or far away you are from it. A screenshot of a Goomba in Mario's first-person mode in Galaxy and a screenshot of that same Goomba from the other end of the platform are both native res, after all. How do you address the other inaccuracy issues that "in-game models" cause that I pointed out? I'm not saying we need to get rid of them entirely, they have their place, but we don't need to rely on them as heavily as we do when there's so many issues and better alternatives, and we certainly don't need to pass them off as models when they're just glorified screenshots. -- 20:07, May 25, 2022 (EDT)


 * If the point was to show an image true to how the game actually has it, a simple cropped screenshot would suffice. If the point was to show the model as it is, a "data-rendered" model image would suffice. "in-game models" are stuck in-between those two other groups while not fitting in either. It doesn't truly represent how the game shows the model due to the context of environment, lighting, effects, etc, lost when removing the background, and it doesn't truly represent how the models actually look due to also keeping native resolution and possible warping effects from the games as well.


 * That said, while I personally believe "data-rendered" models should be used in place of "in-game" models whenever possible, your point about some games being difficult to extract models from is very valid. I am torn on this as I'd prefer superfluous "in-game" renders to be removed (or at least have their backgrounds and original context returned) whenever a "data-rendered" equivalent already exists (See: Dry Bones here and here). LadySophie17 (talk) 20:17, May 25, 2022 (EDT)
 * I should point out that, while I'd prefer not having images like these at all for games that are hard to rip models from, generally this is more about replacing in-game model images in cases where the replacement either already exists on the wiki or is fairly easy to get (i.e. via Models Resource). I don't have any plans to go around purging images without replacements. -- 20:24, May 25, 2022 (EDT)

Change Monobook's background image to the one used on our Vector skin
For nearly a decade now, we've been using this background with the text "Super Mario Wiki" as our default background for Monobook, and subsequently the rest of the wiki. However, as our wiki continues to change, it can be argued that our look should change to better represent the Super Mario franchise, as we have done with our logo. Our Vector skin, for its part, has been using this nice background with various Mario-related symbols. As such I would like to suggest making the Vector background the default background for the Monobook skin.

Proposer: Deadline: May 27, 2022, 23:59 GMT

Support

 * 1) Per proposal
 * 2) Today the wiki background, tomorrow the editing field! Per proposal.
 * 3) Per proposal.
 * 4) Per proposal.
 * 5) That proposals background is just a mishmash of logos and crap. Can we change that too? [[File:SM3DW BF Loading Bowser Jr.gif]]
 * 6) Sure!
 * 7) Sure feels more in line with what one would expect from a wiki themed around a certain franchise. On Bazooka Mario's note, the source editing background feels dated as well, and should likely be changed to 2D vector art.
 * 8) Per proposal.

Make tables, templates, and other areas in the mainspace compliant with WCAG 2.1
Going off from Waluigi Time's proposal to remove the dktable-brown class, I've noticed that there are currently plenty of tables, templates, and other areas within our mainspace that have glaring accessibility issues in accordance to the Web Content Accessibility Guidlines (WCAG) from the World Wide Web Consortium. For this instance, WCAG is split with two levels: AA and AAA. WCAG Level AA mandates a contrast ratio of at least 4.5:1 for normal text, 3:1 for larger text, and 3:1 for any graphical object and interface. WCAG Level AAA is also recommended, with a contrast ratio mandate of 7:1 for normal text, and 4.5:1 for larger text (it is still 3:1 for graphical objects and user interface components per WCAG 2.1).

When looking at our articles, some of these tables or templates with colors are below this contrast ratio mandate. For instance, these table headers fail with a contrast ratio of 1.88:1 (calculations done on this website). Then as Bazooka Mario pointed out, there are tables on the Yoshi's New Island page with headers that also fail with a low contrast ratio. We also have Template:AppealOutcome, and the "amended" category shown in the last example is hard to read with a contrast ratio of 1.33:1.

These are the type of issues we need to address. We can either go with Level AA, as with a lower ratio requirement it means we can still have access to plenty of colors. We can also decide to go with Level AAA, but it would mean we would be a lot strict with what colors to choose from and many tables or template could lose stylizations as a result. This will not be an easy task to make, as we would need to go through each mainspace article and fix this problem up. But I do hope that we are able to make our text more easier to read if this proposal passes.

Note though, I do not want this applied to anywhere other than the mainspace and templates. Other namespaces can be decided on its own, but I think it's more important to address this for the articles that our readers will look at.

Proposer: Deadline: May 29, 2022, 23:59 GMT

WCAG Level AAA

 * 1) Second option, though it mean we have less colors to work with in general.

WCAG Level AA

 * 1) Preferred option since it means we can keep much of our stylization, but still be accessible for readers.
 * 2) I think getting things AA-compliant makes the most sense at this point in time. Transitioning to AAA-compliance could always be done later on an as-needed basis.
 * 3) Per Mario4Ever.

Do nothing

 * Eh, I don't really see the problem with those examples. They all look fine and readable (except the aforementioned last warning amended thing that yellow needs to be fixed), and I'd rather us not have to check if every new color we try to add is acceptable to an arbitrary contrast limit. It just seems like a bit of an unnecessary hassle.

Comments
Somethingone: People with more issues with seeing contrast may not, however. 14:41, May 22, 2022 (EDT)

I'd say this should be a guideline for userspace as well, as I've seen several talk pages that are difficult to read. 14:56, May 22, 2022 (EDT)
 * I agree. Some user's talk pages are known to be a nightmare to read in some instances. 15:00, May 22, 2022 (EDT)

Miscellaneous
None at the moment.