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

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!

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.

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.