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 proposal.
 * 4) 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.
 * 6) It's better to adjust the colors to be less irritating to the eyes than just outright removing the class.
 * 7) Per all.
 * 8) The class can and probably should be improved, but I think we should instead expand the use of classes, if this helps in achieving a quicker coloring of tables to follow some kind of theme (e.g. the series the game belongs to). Within the respect of accessibility guidelines, in my opinion the coloring can make the wiki more engaging to look at and thus to read, while gray might make the text and tables of the pages... true walls the readers crash into!

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)

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.
 * 4) Yeah we need to make sure our wiki is as accessible as possible.
 * 5) Accessibility is important, though I would like to have more color choices available.
 * 6) At least having a starting point in terms of accessibility is important, in my opinion.

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)

Determine when {talk} templates can be removed
Now that we're cleaning up some of our talk templates from inactive and resolved discussions, I feel like I should bring this up to prevent further disagreement.

So basically, I'm proposing for us to decide when a talk page discussion becomes inactive & when we can remove it. I feel like a set time limit that separates "active" from "inactive" would help us in knowing when discussions become inactive, and when they require more talking about.

If there's another time limit anyone wants please let me know.

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

1 year after the last comment

 * 1) Preferred choice

Only when they're resolved (no inactivity time limit)

 * 1) I'd be cool with this too

On a case-by-case basis (do nothing)

 * 1) I don't like the idea of removing discretion in these cases, and would this then apply to all talk page messages? The current removals are more for issues of organization and presentation of the content itself, such as proposals for splits, merges, renames and the like, but I wouldn't want to be removing the template from legitimate questions and requests for information that are still unanswered. The whole point of these removals is to draw more attention to the latter by not having a category clogged with 500 talk pages, after all. Frankly, I don't really think this needs a strict regulation anyway since it's so inconsequential. If a discussion goes inactive and you want to revive it, then revive it, or enact the proposed changes yourself if there's consensus, or just start a proposal.

Miscellaneous
None at the moment.