Wikipedia talk:WikiProject Baseball

RfC on integrating non-AL & NL leagues into MLB season page infoboxes
How should non-AL & NL leagues (namely late 19th century major leagues, 1914–1915 Federal League, and seven 1920–1948 Negro Major Leagues) be integrated (as previously agreed, in regards to the Federal League) into MLB season page infoboxes? Is my attempt a good solution or should it be different? Spesh531(talk, contrib., ext.) 15:09, 28 May 2024 (UTC)

Discussion

 * This is far too open ended. This question assumes that the information should be integrated. Why should they be integrated? What's the harm in the status quo? How will this change serve as an improvement? Nemov (talk) 15:16, 28 May 2024 (UTC)
 * There has been a previous agreement to integrate the Federal League into the 1914 & 1915 MLB season pages, but little specifics were actually agreed upon. The question that "information should be integrated" was already agreed on. The how has not been discussed. Spesh531(talk, contrib., ext.) 15:23, 28 May 2024 (UTC)
 * It would be convenient to link to past agreements. —Bagumba (talk) 15:34, 28 May 2024 (UTC)
 * Link referencing the past agreement added to the original question! <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:38, 28 May 2024 (UTC)
 * That discussion didn't mention the infobox or am I missing something? Nemov (talk) 15:41, 28 May 2024 (UTC)
 * That's the exact problem! That discussion was concluded with "Consensus is to include the Federal League records in the respective MLB season articles". However, the how was never addressed. There are several changes that would need to be made to integrate the page to include the Federal League. The current format is the result of edits I've made, but these edits were never discussed before I made the changes. This was how page was formatted before I made edits to the infobox. The purpose of this RfC is to address the integration of the Federal League (and by extension, other major leagues) into the existing season page infoboxes. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:50, 28 May 2024 (UTC)
 * I question whether we need runners-up, and I would put the 2 World Serieses at the bottom, but overall this seems like the right approach. Jhn31 (talk) 22:28, 28 May 2024 (UTC)
 * We shouldn't make the infoboxes complicated. Best to stick with listing only the AL & NL. GoodDay (talk) 22:38, 28 May 2024 (UTC)

RfC on league leaders tables
Should the League leaders tables be formatted differently? Some users have suggested changing the tables to be more compact, so I have four different ideas as to how they could be formatted. (1, 2, 3, 4). <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:13, 28 May 2024 (UTC)

Discussion

 * I recommend withdrawing this RFC until there's something more concrete for editors to comment on... should they be formatted differently? I don't know. If you have two examples to compare against that would be easier to digest than searching through 4 examples. Nemov (talk) 15:18, 28 May 2024 (UTC)
 * I didn't want to put the ideas here as they take up a lot of space (and are all on the same page), but I will put them here if that is the better option. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:24, 28 May 2024 (UTC)
 * It's usually more effective to give an overview of what you perceive as the problem and your proposed solution. And if you can't narrow down from four options, describe what is the conflict that you want input on.—Bagumba (talk) 15:30, 28 May 2024 (UTC)
 * Previous discussions had some users commenting that the tables should be more compact, so that's where this RfC is stemming from. I've changed the original RfC question to specify why I've submitted this RfC. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:36, 28 May 2024 (UTC)
 * This is too much, too fast. GoodDay (talk) 22:41, 28 May 2024 (UTC)
 * What's not too much, too fast? <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 17:14, 29 May 2024 (UTC)
 * I like #4 for compactness, but there could be further discussion on which specific stats should be included. Jhn31 (talk) 01:34, 29 May 2024 (UTC)
 * It may be worth it to compare the 1923 season stat table proposals. with the 2024 season stat table proposals. I'm personally feeling #4 as well, as it doesn't lead to the seasons with more than two leagues (1914–1915, 1920–1948) to have multiple tables taking up a lot of space. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 17:17, 29 May 2024 (UTC)
 * 4 should be fine long as it doesn't become even wider. 2 as a second choice. CurryCity (talk) 23:53, 31 May 2024 (UTC)


 * So uh... Wikipedia's new larger standard font size may lead to some changed opinions. For 1923: (1, 2, 3, 4) and For 2024: (1, 2, 3, 4). You two  previously made your opinions, what do you think now? I still personally think #4 is preferable (there's not many season with 4 columns, only for 1923–1929, 1932, & 1937–1948). Maybe we should consider formatting the font to be at 95% or 90%?<b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 14:59, 14 June 2024 (UTC)
 * Prefer the compact table of #4 and am pretty indifferent on the font size. Jhn31 (talk) 15:56, 15 June 2024 (UTC)
 * Let's go with 4 then since readers can adjust the font and other styles now. CurryCity (talk) 09:22, 17 June 2024 (UTC)


 * I think the league leaders table is just fine the way it currently is. I believe the saying “if it ain’t broke…” is appropriate here.  Leave it alone is my vote.  Pewtey (talk) 21:54, 9 July 2024 (UTC)

Template:MLB standings look a bit broken now
So it seems Wikipedia is updating their default formatting again, this time by increasing the font size. Now, even less content fits horizontally. This text size increase has lead to all instances of the Template:MLB standings to be twice as tall, due to the Home and Road columns taking up two lines now. The best example of this can be seen with the current season.

This is only in regards to the current table format. There's many other formats built into this template via Module:MLB standings that would need adjusting:

There's a few ways we can go about this. We could shrink the font in the table by adding "font-size: 90%;" in the style header. We could do some minor adjustments to the columns: decrease the width for the team names (and let that be the column that may end up on two lines *cough* Los Angels Angels of Anaheim *cough*), rendering the percentage somehow so there is no leading 0 before the decimal. To avoid the two-line team, we may want to slightly increase the width of the table. Here's two examples with the 2021 NL West with the division winning 2014 Los Angeles Angels of Anaheim (it's with these teams that we see 3 digit wins and losses, a long name as a division winner, and a games back stat with "½").

Increasing width from 535em to 550em, removing leading 0 from %, and adjusting width % for each column:

Status quo but simply applying 90% font size:

I'm sure there's other ways to remedy this but I at least want to get this discussion going. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 14:45, 14 June 2024 (UTC)
 * I think the best approach to respect the readers' choices for font size/zoom level is to stop displaying two tables side-by-side and display them one below the other. The table can then be made a bit wider to better accommodate variation in font size. isaacl (talk) 15:09, 14 June 2024 (UTC)
 * Upon further reflection, it should be possible to wrap the American League and National League sections with a  element that uses CSS flexbox layout so that the sections will be next to each other if there is space, and wrap below if there is not. I'll have to experiment a bit. isaacl (talk) 15:16, 14 June 2024 (UTC)
 * I added testcases for displaying the league standings next to each other. I made changes in the sandbox to increase the width of the division standings table and adjust the column width allocations, and used CSS flexbox layout at . For me, though, they only go side-by-side with the settings set to small font, wide display, and a 100% zoom level.(Note it also depends on browser window width.) isaacl (talk) 16:13, 14 June 2024 (UTC)
 * You guys would know better than I do, does the reduced font size version adhere to MOS:SMALLFONT? It looks less than 85% to my naked eye. – Muboshgu (talk) 16:30, 14 June 2024 (UTC)
 * I have no clue on the size issue but we can probably remove the "of Anaheim" from the Angels since the season page doesn't use that name anymore and it was always kinda funky. Spanneraol (talk) 17:57, 14 June 2024 (UTC)
 * It's still present on season pages when that name was in use by the franchise. I put it in the testcase so the longest name can be tested. isaacl (talk) 20:18, 14 June 2024 (UTC)
 * In terms of widest or longest, you may also want to test the templates with the seeding indicator (1) or if a team is ½ a game back. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 05:44, 15 June 2024 (UTC)
 * Please feel free to add more testcases! I've made some updates. isaacl (talk) 07:00, 15 June 2024 (UTC)
 * I've been thinking of other options but I think the flexbox layout is the way to go! More specifically, almost exactly as you have it on this section of the testcase page. The minor adjustments I'd do are seen here in my sandbox page.
 * Those minor adjustments would involve either formatting the percentages without the leading 0 and/or widen the table just enough so "(2) Los Angeles Angels of Anaheim" fits on one line in the "Standard" text size. Wikipedia's "Standard" width will (at least on a 1080p monitor) always force the tables to not be side-by-side, but at least the "Small" & "Standard" text size with the "Wide" width will keep the standings side-by-side. I've made the Home and Away columns wider so that the Win/Loss doesn't wrap around into two lines when the text is set to "Large". It should be noted that, on a 1080p monitor, the widest these tables can be so that they are side-by-side in Wikipedia's "Wide" width is 614em. Admittedly, the Home and Road columns are awkwardly wide when the text is "Small" but it needs to be so that when text is "Large" it doesn't wrap around.
 * Also, any other side-by-side formatting (that involve the col-start/2/end templates) forces the tables to go past the designated "Standard" width and overlaps the Appearance sidebar. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 14:34, 20 June 2024 (UTC)
 * I'm not sure what's different on your sandbox page, so I'll walk through the changes I made to the sandbox template, and perhaps you can walkthrough what is different?
 * Division table:
 * increased width from 535em to 555em
 * reduced percentage allocated to team name from 50% to 48%
 * increased percentage allocated to home and road records from 10% to 11%
 * Win-loss only table (used for division leaders table):
 * increased width from 390em to 405em
 * Wild card table:
 * increased width from 390em to 405em
 * The "V·T·E" links bump up against the headings at larger font sizes, which is why I started testing width increases for all tables. They're still not wide enough at present; more tweaking or a different adjustment may be needed. It's possible to write code to strip the leading 0 from the percentage, but personally I'd prefer to get by without writing more code if possible.
 * Forcing a side-by-side display was always a bit of an accessibility issue (it creates left-right scrolling for me, as I browse at a slightly enlarged zoom level), so I think using flexbox layout is preferable. Changing all of the season pages, though, needs some willing volunteers (I think it should be feasible to use AWB to semi-automate the changes).
 * I'm not clear on your use case with "other side-by-side formatting". Can you add a testcase using the sandbox template with the flexbox layout to provide an example? isaacl (talk) 19:32, 20 June 2024 (UTC)
 * Regarding "other side-by-side formatting", I'm not sure if there are other methods to have two tables side-by-side aside from the current (col-start/col-2/col-end) templates and flexbox, that's why I said "other"... so I guess ignore that.
 * I've only tested changes on the division table, not the win-loss or wild card table. I have two versions of proposed changes (which keeps percentage as "0.123"). One is so that, even in large text, everything fits on one line. The other allows team names in large text to be in two lines. Both versions resolve the issue of the Home and Road records taking up two lines.
 * Version that keeps everything on one line, even if text is set to Large:
 * increased width from 535em to 700em
 * increased percentage allocated to team name from 50% to 52%
 * decreased percentage allocated to Win, Loss, & Games Behind from 7% to 6%
 * decreased percentage allocated to Win% from 9% to 8%
 * increased percentage allocated to Home and Road records from 10% to 11%
 * Version that allows team names to fit on two lines when text is set to Large:
 * increased width from 535em to 614em
 * decreased percentage allocated to team name from 50% to 45%
 * decreased percentage allocated to Win & Loss from 7% to 6%
 * increased percentage allocated to Games Behind from 7% to 8%
 * increased percentage allocated to Home and Road records from 10% to 13%
 * In the context of Wikipedia's "Large" text appearance:
 * By making the table wide enough so everything in a row fits on one line, the table must be increased to at least 700em (this would eliminate the purpose of wrapping tables to be side-by-side, whether by flexbox or 2-column layout, even if the Width setting is set to "Wide", as the table is simply too wide to wrap).
 * By allowing the team name to be in two lines (while still being on one line when the text appearance is set to "Small" or "Standard"), the table must be increased to at most 614em to allow the table to wrap in the "Wide" width. (These tables will never fit in Wikipedia's "Standard" width side-by-side unless team names and home/road records take up multiple lines).
 * I'm focusing on the fact that if the table is only increased to 555em, the Home and Road records don't fit on one line and effectively double the height of the table. Also, making the tables as wide as I'm proposing should eliminate the V·T·E overlapping with the Division name.
 * Also, I've been (slowly) adding more information (schedule section/table of teams, stadiums, & managers/map showing team locations/etc.) to every MLB season page going back to 1901 (currently finished 1901–1936), so I'll gladly volunteer to apply the flexbox format (unless of course AWB can do the job!) I hope I've cleared any confusion! <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:55, 21 June 2024 (UTC)
 * I've changed the sandbox version of the module to specify a width of 614em for the division table and the column percentages you listed. There is still overlap with the template navbar for the American Association and Players' League standings tables. (There's overlap too when the full American/National League division names are used, but I believe none of the current MLB standings templates use the full names.) Thus a wider size would be needed to accommodate those uses. On a side note, I don't get a side-by-side layout with any combination of font size/page width settings; I'm guessing your screen width is larger than mine. isaacl (talk) 00:16, 22 June 2024 (UTC)
 * My screen is 1080p (which is 1920 pixels wide). It seems anything that's at least 1440 pixels wide or smaller negates any use of the Standard or Wide widths. Formatting the standings to be side-by-side via flexbox would only benefit those with a higher screen resolution. I can't test for anything between 1440 pixels and 1600 pixels, but I know there's a difference at 1600. Regarding the current 535em tables, they'd only go side-by-side via flexbox with a display resolution of 1680 pixels or more.
 * I highly recommend that any instance of the endash "–" be replaced with the template ("") immediately. This would prevent the Home and Road columns from populating multiple lines, in the same way "& n b s p ;" (with no spaces) does. (I now need to test the width % of each column again and adjust percentages... I wish I knew about this before!)
 * It may be that the side-by-side formatting just ends up being a luxury for those with wider monitors. Much depends on whether we want team names to strictly appear on one line, or allow for the team names to appear on multiple lines.
 * Regarding the V·T·E, what if we added a line above everything for the name of the division/league? An example of what I'm talking about can be seen here (an added bonus could be color coding American League and National League with red and blue, respectively, as well). The V·T·E would fill the box where the division/league name used to be. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:24, 26 June 2024 (UTC)
 * Also, perhaps we don't necessarily need the tables to be a defined em width? The tables could be formatted so instead of the table at large being defined, the columns themselves could be defined (as is the case with the NFL standings templates). That way, the changing text size doesn't create unnecessarily wide boxes. Basically, if the text is smaller, the box is narrower. If the text is larger, the box is wider. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:40, 26 June 2024 (UTC)
 * This is the change I'm talking about, changing the table from table defined by an overall table-width to a table where columns define the width. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 15:57, 26 June 2024 (UTC)
 * From an accessibility point of view, not specifying a width is best. I think it would mean forgoing a side-by-side display (I don't think it can be done with CSS alone unless a width is specified, and Javascript is overkill for this purpose and so wouldn't get approved). For that reason I hadn't floated that idea before (I didn't want to get into an argument with those who might prefer that layout). With the introduction of the readability tools to Wikipedia, though, I agree that getting rid of the fixed width should be considered. It would also mean that the division tables and the individual columns may have different overall widths when stacked on top of each other, unless the tables were set to fill the full available width. isaacl (talk) 16:15, 26 June 2024 (UTC)
 * I changed the sandbox module by removing the table widths, and added a test case without any columns or flexbox layout. The flexbox layout test case still allows for side-by-side layout, but there's no attempt to avoid line breaks within the cells, as the browser will squeeze the columns narrower as needed to try to fit the tables next to each other. And it seems the squeezing still happens even if the second block of tables has to overflow to below the first block. So I think the new testcase is the better approach if removing the table widths. isaacl (talk) 16:28, 26 June 2024 (UTC)
 * If we allow squeezing to happen, ideally, we only want it affecting the team name column (hence my desire to replace all instances of "–" with the template . The output is the same ("") but it forces the "####" to stay on one line.
 * I'm in the middle of testing different column widths here to try and minimize table widths as much as possible without making the table needlessly wider.
 * Also! I know I wrote a lot in my previous comment but how do you feel about adding the header row on top of the table? That would resolve the V·T·E overlap. Alternatively (and I can't format it correctly), have the V·T·E in the top row with the division/league name, and have it so "Team" is the column header. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 17:06, 26 June 2024 (UTC)

I think I found a near-solution to the differing column widths. This will result in tables that are only 1 or 2 pixels off in Small or Standard text and up to 4 pixels off in Large text. The GB column will be the same, regardless of if there is "½" or not. ! width="245" | Team ! width="24" | W ! width="24" | L ! width="35" | Pct. ! width="27" | GB ! width="39" | Home ! width="39" | Road ! width="245" | Team ! width="24" | W ! width="24" | &numsp;L&numsp; ! width="35" | Pct. ! width="27" | GB ! width="39" | Home ! width="39" | Road Basically, the "W" and "GB" each have an instance of  before and after it, while "L" has , since "L" is narrower than "W".

Within the brackets, it would look like this: "Win (baseball)| W ", "Loss (baseball)| L ", and "Games behind| GB ". (I hate trying to show examples of html text as it would look in an edit!) <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 17:41, 26 June 2024 (UTC)


 * With table markup, I think the only choices are to specify the cell width in some manner, or let the browser's layout algorithm do its work. (If something like grid or flexbox layout was used instead of the table, more control can be asserted on what is allowed to shrink/grow, but I think that would be too obscure to allow for easy maintenance.)
 * I'm not a fan of having a cell span the entire width of the table, due to semantics: it would essentially be a caption, and so I would prefer using a table caption for better accessibility. I can try mocking something up later with a table caption. (I do not like changing the default background colour, as it means viewability and colour contrast has to be considered across different skins and dark mode.) isaacl (talk) 17:52, 26 June 2024 (UTC)
 * Regarding the last example, if the table width is going to be allowed to expand as necessary, then we shouldn't specify fixed column widths. Pixel-perfect layout isn't a goal to strive for with a responsive design. isaacl (talk) 17:56, 26 June 2024 (UTC)
 * But it is possible to set slight restrictions within the bounds of a responsive design, no? Here are two examples. One which features the NFL-division style header (here) and one which maintains the current MLB format (here). Regardless of the change in text size, each division table both grows with the text size, and also maintains a near-consistent column width. The cell-spanning-the-entire-width to me, is a decent solution to resolve the V·T·E overlap. Alternatively, in keeping the current table format, instead of spelling out "National League" or "American Association", their abbreviations "NL" or "AA" are simply used.
 * Also, regarding the visibility with the red and blue colored headers (not that I'm necessarily in favor of this either), the colors (as well as the colorless darker gray that outputs by using ! instead of | in the tables) don't change with dark mode. Regarding other skins? Outside of Custom CSS or Custom JavaScript skins, the color contrast remains consistent with the current Vector default skin and all other options that are selectable in Special:Preferences. However, I didn't check different browsers. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 18:25, 26 June 2024 (UTC)
 * Specifying the width in (CSS) pixels for every column isn't a slight restriction. It locks down the widths just as much as specifying the width of the entire table and allocating percentages to each column. Using a font-related unit is also more amenable to handling changes in font size.
 * Regarding dealing with other skins and dark mode: the appearance of the cells against the main background should be considered. I'd rather just use the skin/dark mode defaults that have been tested. isaacl (talk) 21:15, 26 June 2024 (UTC)
 * <syntaxhighlight ></syntaxhighlight> is a good way to show code examples. For example:  (See mw:Extension:SyntaxHighlight for more details.) isaacl (talk) 18:17, 26 June 2024 (UTC)
 * Thanks! I was trying to get it to appear in the proofreading format I had above, but I lost my patience in trying to get it to work! <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 18:26, 26 June 2024 (UTC)

I've changed the sandbox module to use table captions and to put zero-width joiner characters around the en-dashes in order to prevent line breaks. You can see the results on the testcases page. isaacl (talk) 21:32, 26 June 2024 (UTC)

I changed the testcase using flexbox layout to provide additional guidance on how the two blocks of tables can be expanded/shrunk to fit the available space (now that the table is no longer a fixed width). It now shows a side-by-side layout at narrow window widths than before. (Note increasing the font size effectively narrows the window; with the change, a side-by-side layout appears with the text size set to large and the width set to wide.) isaacl (talk) 22:05, 26 June 2024 (UTC)


 * The headers as you have it are great, especially with the V·T·E no longer being able to overlap. I think the rest looks great, aside from Large text (at least on 1920 pixel width), but that's by virtue of teams taking multiple lines of space. It's unavoidable if the goal is to always have two columns. I adjusted the percentages slightly (the Home and Road are now 10% each and Teams 51%. Previously this was 13% each and 45%, numbers I had used before I knew there was a way to code the endash to restrict breaks).
 * Is there a way for there to be no breaks between the seeding # and team name? That's part of the problem with the large text. On 1080p at least, with Large text and Standard width, for example, the AL East looks like this (unlike here, it is centered in the table):
 * (1)
 * Baltimore
 * Orioles
 * (4)
 * Tampa
 * Bay
 * Rays
 * (6)
 * Toronto
 * Blue
 * Jays
 * If there were no break, the table could be a bit shorter and the AL & NL columns' hieght would be aligned a little better.
 * (Side note: I wish I knew what I was looking at with the module. I'd spend the extended amount of time to write the code myself to get rid of that leading 0 if it meant the Team text could have just a little more room! Maybe I'll spend some time to figure it out).
 * Aside from what I mentioned, I think this may be the way to go. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 23:59, 26 June 2024 (UTC)
 * I changed the space to a non-breaking space, so the text should not break at that point.
 * Part of my not wanting to write more code than necessary is that I'm not sure if there are any other editors interested in baseball who know Lua, so I didn't want to make the code more complicated if it wasn't needed. However, I see I already convert the percentage to a string for formatting, so I guess what's a little more string manipulation... I've coded a change in the sandbox module. (The other part is that it doesn't seem like it should be necessary to strip out "0" to deal with a table layout that is much, much wider than a single character. :-) isaacl (talk) 00:24, 27 June 2024 (UTC)
 * Looks like you beat me to it (by a lot... I was still trying to find what I was looking for here xD ) That's much better! I personally think this could be the version. Thanks for hearing out some of my ideas and allowing me to (basically) badger you to update the Module! <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 01:07, 27 June 2024 (UTC)
 * Part of my not wanting to write more code than necessary is that I'm not sure if there are any other editors interested in baseball who know Lua, so I didn't want to make the code more complicated if it wasn't needed. However, I see I already convert the percentage to a string for formatting, so I guess what's a little more string manipulation... I've coded a change in the sandbox module. (The other part is that it doesn't seem like it should be necessary to strip out "0" to deal with a table layout that is much, much wider than a single character. :-) isaacl (talk) 00:24, 27 June 2024 (UTC)
 * Looks like you beat me to it (by a lot... I was still trying to find what I was looking for here xD ) That's much better! I personally think this could be the version. Thanks for hearing out some of my ideas and allowing me to (basically) badger you to update the Module! <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 01:07, 27 June 2024 (UTC)

To summarize, the following changes are being proposed: has an example of the MLB season page layout. Feedback is welcome! If there aren't any objections, I will update the MLB standings template, and Spesh531 has volunteered to update the MLB season pages. shows how the tables will appear after the MLB standings template has been updated, but before a given MLB season page is modified as proposed. isaacl (talk) 14:17, 2 July 2024 (UTC)
 * Table widths in MLB standing tables (division, division leaders, and wild card teams) are no longer fixed in width. The percentages allocated to the columns are tweaked based on trial-and-error testing. This allows the browser to shrink the width of the table as needed to keep it from being wider than the main content area.
 * The table title is moved out of the heading of the first column and to the table caption (along with the mini template navigation bar). This provides better accessibility for those using assistive technologies, and gives adequate space to fit the title with an adjacent template navigation bar.
 * The markup on MLB season pages used to display the standings for the American and National Leagues is modified to no longer enforce a two-column layout. Two columns will be used if the browser is able to lay them out within the available space, given the browser window width and other display choices configured by the reader (both Wikipedia settings, and browser settings). This respects the reader's configuration while still supporting a side-by-side layout if there is space.


 * As I said above, it looks good to me! Simply waiting for the MLB standings template to update and I'll make the changes on all of the season pages! <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 01:30, 4 July 2024 (UTC)
 * I'm considering making a template for the flexbox portion of the markup, so if something needs to be adjusted, it can be done in one place rather than having to edit all the season pages again. (It would probably be something like Flexbox but with a Lua implementation similar to Flex columns to allow for an arbitrary number of blocks.) I'm still struggling with how to describe the intent of the template conceptually and how reusable the template should be, though even if it's just used on MLB season pages, that would be plenty of uses. The standings template can still be updated in the near future (I'm still waiting to see if anyone else comments). isaacl (talk) 04:12, 5 July 2024 (UTC)
 * There were some limitations with implementing it in Lua, so I changed the usage to be similar to col-float/col-float-break/col-float-end. I've updated the test case to use the new template I created, flexbox wrap. isaacl (talk) 05:43, 6 July 2024 (UTC)
 * I've [//en.wikipedia.org/w/index.php?title=Module:MLB_standings&diff=prev&oldid=1232960964 updated the MLB standings template] with the proposed changes. isaacl (talk) 15:27, 6 July 2024 (UTC)
 * I'm working through the seasons now. I won't have time to finish today. I do have one question: is there a reason why, such as in 1956 Major League Baseball season, the American League and National League standings are of a different width? <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 18:28, 7 July 2024 (UTC)
 * I've noticed why it happens! Whenever a team has triple digit wins or losses, the table gets wider. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 18:47, 7 July 2024 (UTC)
 * Thanks for your diligent work! Yes, the consequence of getting rid of fixed-width tables is that when the contents of a cell gets wider, the cell and thus the whole table gets wider, provided there is enough horizontal space for the browser to lay out the table cells without needing to introduce line breaks. Using percentages for the cell widths means the Wins and Losses columns in a given table will stay the same size even if just one of them has to expand to fit their contents. Once the browser does have to shrink the cell widths to fit them in the available space, then the relationships between the column widths can change from the specified values. isaacl (talk) 03:20, 8 July 2024 (UTC)

FWIW - Would adding a GP (games played) column, be unnecessary? GoodDay (talk) 21:01, 7 July 2024 (UTC)

Strike zone and Base on balls opening image crop request
Was going to create and redirect "Low and away" to Strike zone ( 'Strike Zone' probably should be uppercased, no?, which is now taken by the name of a Star Trek novel and, come to think of it, I'm going to boldly go and change the name and redirect uppercase to the now lowercase Strike zone to see if it sticks). A request, can someone here who is good at cropping images tackle the opening image at Strike zone and Base on balls and separate the strike zone data from the advertisement for Goodyear? Thanks. This would also enlarge the important page-pertinent details. Randy Kryn (talk) 02:58, 26 June 2024 (UTC)
 * Also created 'High and inside' and redirected it to 'Strike zone'. Moved the uppercased page to Strike Zone (book) and redirected Strike Zone to Strike zone. Randy Kryn (talk) 03:26, 26 June 2024 (UTC)

Disruptive IP
Just a heads up: there is a disruptive IP address editor who is reformatting pages of Hall of Famers in a way which is unhelpful at best. They give no explanation for their edits either and have been at it for a few weeks now. Just keep a lookout and report them if possible. Omnis Scientia (talk) 12:54, 26 June 2024 (UTC)

Requested move at Talk:Tony Kemp (baseball)
There is a requested move discussion at Talk:Tony Kemp (baseball) that may be of interest to members of this WikiProject. Safari Scribe <sup style="font-family: Times New Roman; color: #006400;">Edits! Talk! 20:38, 1 July 2024 (UTC)

Merge proposal: Dalton Rogers
I have proposed that article Dalton Rogers be merged into Boston Red Sox minor league players. I initially made a WP:BOLD merger, but another editor objected. Editors are welcome to offer comment here. Dmoore5556 (talk) 21:08, 2 July 2024 (UTC)

Cumulative win-loss record for head-to-head rivals
I have started a discussion at Talk:Major League Baseball rivalries regarding a recent set of changes that introduced the cumulative head-to-head win-loss records for pairs of rivals, over the entire history of the teams. Feedback is welcome. isaacl (talk) 00:31, 5 July 2024 (UTC)


 * I had previously added them to each section due to it already existing on the Angels-Athletics section, and I was trying to keep some consistency from section to section, though I'm indifferent regarding keeping or removing the head-to-head records. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 16:56, 8 July 2024 (UTC)
 * To briefly summarize what I said on the Major League Baseball rivalries talk page, I think fans talk about pennant races and playoff series wins when they talk about rivalries. I don't think cumulative head-to-head win-loss records for the regular season and for the playoffs really captures what fans are thinking about with rivalries, even if these are numbers that broadcasters like to trot out. Thus I think the records should be removed from the rivalries article. isaacl (talk) 02:11, 9 July 2024 (UTC)

Adding (or removing?) stats to League leaders sections in season pages
Currently, hitting and pitching leaders tables each have 6 stats each. I'm of the belief that OPS should be added to hitting leaders and less so adamant that WHIP be added to pitching leaders. Why OPS? It seems that most of the league at this point focuses more on OPS than AVG. Why WHIP? Though not as focused on compared to ERA, it portrays a pitchers effectiveness against batters and is typically on even smaller pitching stats tables (such as CBS Sports, which for pitching stats, shows Wins, ERA, Saves, Strikeouts, and WHIP). Plus, adding WHIP would keep both hitting and pitching leaders to show 7 stats each.

I know I read somewhere in the talk page someone had suggested reducing the stats listed. I personally disagree but I wanted to mention it.

Regarding an addition or removal, I'm willing to go through all 124 season pages to update them. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 17:11, 8 July 2024 (UTC)

Creating pages for Milwaukee Braves, Kansas City Athletics, and Washington Senators (1961–1971)
In my sandbox, I have created pages for the Milwaukee Braves, Kansas City Athletics, and Washington Senators (1961–1971). I'd like to copy/paste the content to the redirect pages or move the sandbox page itself to proper articles (with admin support, as I cannot do that myself), but I wanted input from other WikiProject Baseball users before doing any sort of implementation. I've modeled these pages mostly after the Boston Braves article, but most mentioned below follow a similar format.

Mind you, there is heavy precedent for having separate pages for the same franchise but of different locations, such as: Some of these teams existed longer in previous locations (Braves, Giants, Dodgers, Expos) and some existed for only one season (Seattle Pilots).
 * Baltimore Orioles with franchise pages Milwaukee Brewers (1894–1901) and St. Louis Browns
 * Atlanta Braves with franchise page Boston Braves
 * Oakland Athletics with franchise page Philadelphia Athletics
 * San Francisco Giants with franchise page New York Giants (baseball)
 * Los Angeles Dodgers with franchise page Brooklyn Dodgers
 * Minnesota Twins with franchise page Washington Senators (1901–1960)
 * Milwaukee Brewers with franchise page Seattle Pilots
 * Washington Nationals with franchise page Montreal Expos

These three pages would simply complete the set of prior locations of current MLB franchises. Much of the content is largely taken from existing articles (as are stated at the top of each of the three sandbox articles at the moment), but each have been expanded with Infoboxes, and "Legacy", "Notable [Team Name players]", "Uniforms", and "List of [Team Name] seasons" sections. Some areas of the articles have been expanded within the already existing-from-other-articles sections. <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 16:04, 11 July 2024 (UTC)


 * For the Milwaukee Braves I believe the History of the Atlanta Braves article is the best place for covering the franchise history in Milwaukee, especially since the franchise wasn't in Milwaukee for very long. This probably opens up a can of worms but the Boston Braves article pretty much covers the exact same information that's already included in the Atlanta Braves article what's left could be put in the "History of..." article as well. Nemov (talk) 16:49, 11 July 2024 (UTC)
 * I believe there already was an RFC held a few years ago, on how to handle relocated MLB franchises. GoodDay (talk) 17:00, 11 July 2024 (UTC)
 * Yep, here's the RFC. Nemov (talk) 17:14, 11 July 2024 (UTC)
 * A 2022 request for comments discussion resulted in being modified to state that if there is sufficient content, keep an article at the old franchise name. Otherwise, the old name is redirected to either the appropriate section in the new franchise article or the "History of new franchise" article. So it's up to editorial judgement if these former franchises have enough content for an independent article. isaacl (talk) 17:16, 11 July 2024 (UTC)
 * I'm definitely new to the discussion history regarding this topic, but my understanding from reading through the past discussions on this talk page, mainly Archive 41 from 2015 and Archive 47 from 2022 (in which the next section was to the RfC related to sports team names), I get the sense that the initial solution to this reoccurring question was to split each teams history in a previous location to its own (for example) "History of the Boston Braves" page, though in some cases, there weren't any splits (such as with the Milwaukee Braves, as the history was not long/detailed enough to warrant its own page).
 * Then, that decade-ish long consensus had the rug swept out from underneath when the RfC on naming conventions took all of these dedicated "History of [FORMER LOCATION TEAM NAME]" articles and removed the "History of", making it so the 9 of the 12 previous-locations-of-current-franchise pages (excluding the three team iterations that sparked this section) now all had separate articles, when before that wasn't the case. The "history of..." seemed to be a compromise between keeping all team history in the current franchise "History of..." pages and simply breaking off each previous-locations-of-current-franchise pages.
 * I'm coming into this only now (and just read the archives while typing this comment). I made these three sandbox pages because my thinking was "well if these 9 articles mentioned above can exist, why not the other 3? Especially considering a page like Seattle Pilots only covers one season".
 * Personally, I'm of the belief that while the franchises are technically the same, I'd argue simply being in different cities (especially of considerable distance as Boston>Milwaukee>Atlanta or Philadelphia>Kansas City>Oakland) is enough to warrant their own articles (again, see Seattle Pilots). For example, the Milwaukee Brewers and Philadelphia Phillies celebrate other franchises' histories, with the Milwaukee Braves Wall of Honor and Philadelphia Phillies Wall of Fame (which includes many Philadelphia Athletics players), respectively. There's a history of baseball in that location. Though of course, at the same time, these histories are celebrated by the Atlanta Braves and Oakland Athletics franchises, respectively. These two simultaneous views on how to look at these now-relocated teams, to me, warrants their own articles.
 * <b style="color:#3A58AF">Spesh531</b><b style="color:#58AF3A">(talk</b>, <b style="color:#AF3A58">contrib.</b>, <b style="color:#ADADAD">ext.)</b> 18:02, 11 July 2024 (UTC)
 * Based on the RFC, Milwaukee squarely falls into the "not enough history to justify an article" camp. The Atlanta Braves and History of the Atlanta Braves covers that period well. Nemov (talk) 18:28, 11 July 2024 (UTC)
 * I think there should be enough history in thirteen seasons to have a separate article. If editors like Spesh531 are interested in developing more coverage of the Milwaukee Braves, then I think it's reasonable to have a standalone article. (If there is no interest at the moment in expanding coverage, then I'm less opinionated about spinning out the Milwaukee history.) isaacl (talk) 18:41, 11 July 2024 (UTC)
 * Yeah, I too fail to see how one season of the Seattle Pilots and eight seasons in the late 1800s of the early-era Milwaukee Brewers (1894–1901) are both worthy of articles, but thirteen seasons of the Milwaukee Braves, thirteen seasons of the Kansas City Athletics, and eleven seasons of the Washington Senators (1961–1971) somehow are not. If editors are eager and willing to work on developing articles for those three teams, I say go ahead and do it. After all, the history of those three franchises in those three cities would most definitely meet WP:GNG. Ejgreen77 (talk) 22:53, 11 July 2024 (UTC)
 * I do agree if new content laser focused on the Milwaukee Braves is created I wouldn't object. However, a new article simply covering the same exact content found elsewhere it's not necessary. The Boston Braves article could be improved a lot in this regard. Nemov (talk) 13:35, 12 July 2024 (UTC)

The RfC didn't address whether or not an article should exist -- it only covered if it did exist what the title should be. Basically, you shouldn't have a "History of the Brooklyn Dodgers" unless you first have a "Brooklyn Dodgers" article. IMO, Spesh531 could have created these articles per WP:BRD. I always figured someone would eventually fill in the blanks and turn the redirects into articles one of these days. It looks like the 3 redirects all meet the "minor history" requirement so you can probably tag all 3 with Db-g6 and an admin can complete the page move. (You can't copy/paste your Milwaukee article because more than one user has edited the page.) Also since you copied content from the old History article, be sure to give proper attribution by putting copied on the talk pages (see Talk:St. Louis Stars (baseball) & Talk:St. Louis Stars (1937) for copied examples). Rgrds. --BX (talk) 04:52, 12 July 2024 (UTC)