WikiProject iconBaseball Project‑class
WikiProject iconThis page is within the scope of WikiProject Baseball, a collaborative effort to improve the coverage of baseball on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
ProjectThis page does not require a rating on Wikipedia's content assessment scale.

RfC on integrating non-AL & NL leagues into MLB season page infoboxes

edit

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)Reply

Discussion

edit

RfC on league leaders tables

edit

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). Spesh531(talk, contrib., ext.) 15:13, 28 May 2024 (UTC)Reply

Discussion

edit
  • 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)Reply

Just to point out, there is no such thing as "official" baseball history

edit

Executive Summary: Nobody gets to say that their "official" versions of historical events carry extra weight, baseball games and seasons are historical events, and using the term "official" in any of these discussions is not helpful and instead just muddies the issue. (And if there was a source of baseball history which we would consider "official" it's arguably the Hall of Fame rather than MLB.)

Detailed Exposition:

I'm not saying this about any particular case, I am not against the Negro Leagues being considered major leagues or anything like that (I haven't studied the matter). I just wanted to point out that what MLB says about that doesn't mean much of anything and should be pretty much ignored.

MBL is a business organization, run for profit (or the profit of its members). It makes the schedules, sets the rules, negotiates the labor contracts, and like that. It is not an academic institution, nor is it run by baseball experts, historians, enthusiasts, or, for all I know, people who even care all that much about baseball per se. It can say that its statistics are "official", but so could I or SABR or anybody.

MLB does employ the Elias Sports Bureau, which is also a for-profit company, which provides the statistics used on MLB's website. Elias does employ historians and statisticians, but their methods are entirely secret, and they are generally despised for various reasons including trying to claim ownership of historical facts (i.e., baseball statistics) and insisting that statistics other than their own should be discounted (I don't know if they still do this).

But, there is no such thing as "official" statistics for historical events, that we have to pay any mind to. If the Official History of the Napoleonic Wars published by the French Government says there were 25,000 French Casualties at Waterloo, we are not obligated to say "Welp, that's the official number, so we have to go with that regardless" or even not just blow it off, and so forth. Baseball history is history. We don't have to pay any attention to MLB or Exxon-Mobile or any other organization when reporting history, and in fact often look at information provided by interested parties with some skepticism.

And MLB is an interested party. Their actions are designed to put fannies in seats and in front of TVs. (This can include benign actions of course and actions to make them look good because they are good, and they are interested in the long-term viability of the business of baseball I'm sure. But they are an interested party,)

Case in point, MLB still says that Ty Cobb's lifetime batting average is .367. MLB holds by that number for political reasons (to gruntle the boomers pretty much) and basically said so. Elias is the actual provider of that number, and since their methods are secret, I assume that their method here was "Well, that is the number the client wants, so that is the number the client gets". This does not give me confidence in anything else they say.

I presume that MLB has said the Negro Leagues are major leagues for political reasons: for public relations in being nice and up-to-date and against racism. That doesn't mean their decision was wrong (it quite probably wasn't). It doesn't mean that the people at MLB aren't personally ethical and against racism.

But it was a business decision, not made because Elias studied the matter in great depth using advanced techniques or whatever, reported to MLB that Negro Leagues were of major-league quality, ans MLB said "Welp, whether or not this causes us hassles and controversies and maybe boycotts in the South or whatever, the truth is the truth and that comes before mere business".

What SABR and Baseball Reference and similar entities and the Hall of Fame (which is not an arm of MLB) and individual baseball experts and historians say, that is what matters. I think they are on the bandwagon for allowing the Negro Leagues as major leagues, and that is fine. We should go with what they say, yes, if there's a clear consensus among them. Herostratus (talk) 06:55, 6 June 2024 (UTC)Reply

ok Agent VodelloOK, Let's Party, Darling! 15:03, 6 June 2024 (UTC)Reply
I've decided that what I say is what matters... to heck with all those people. lol. Spanneraol (talk) 15:18, 6 June 2024 (UTC)Reply
[[Dude, there's no need to laugh at me, sheesh. You could have said nothing. Herostratus (talk) 03:12, 13 June 2024 (UTC)Reply
The WP:BESTSOURCES policy says:

In principle, all articles should be based on reliable, independent, published sources with a reputation for fact-checking and accuracy

Bagumba (talk) 00:31, 7 June 2024 (UTC)Reply
Right, and MLB is not independent, right? Technically, that would put into question whether we should use anything they say at all, at least without tagging. I'm not advocating that for practical reasons, but I don't think we should necessarily take everything they say at face value. Herostratus (talk) 03:12, 13 June 2024 (UTC)Reply
We should go with what they say, yes, if there's a clear consensus among them: Even if they don't come to a consensus, their views should be reflected based on WP:WEIGHT. —Bagumba (talk) 00:36, 7 June 2024 (UTC)Reply
Before MLB.com was updated to include Negro Leagues stats, some people used the argument "why would we consider the Negro Leagues stats as part of MLB history when MLB.com itself doesn't even do that?" That argument is now gone. Taking it a step further, is there any major sources, primary or secondary (something that is continually updated, not a reference book from before 2020) that doesn't include the 7 major Negro Leaguers alongside the American, National, and other major leagues. Jhn31 (talk) 16:02, 15 June 2024 (UTC)Reply
"MLB.com itself". That is argument from authority. We don't do that, and no Wikiproject is supposed to do that. We do not use "the Pope himself said so" when deciding whether or not to state as a fact that St Bernadette's body remains incorrrupt. Tho at least the Pope cares about the matter. So ideally we would just blow off people who use the argument from authority.
Of course many of the Negro Leagues were major-league quality. Why do I believe that? One strong reason is because SABR says so, on the basis of extensive research of pretty much academic quality. here, here etc.
Of course we are going to include them as major leagues now. The question is, what about the stats? The stats aren't complete. Baseball Register is including them it seems, and Baseball Register is a good source and that is an important data point. There is a good argument for not including them tho: they're incomplete. That matters. I want to see what SABR and the Hall of Fame have to say about that. Tetelo Vargas is reported to have hit .471 in 1943 which would be the new record. It's not so much that that is in only 30 games, 121 at bats. It's more that he didn't actually hit .471 because we don't have a complete record. Maybe in the missing games he hit better than .471, or maybe worse. Who knows? Nobody. Since he didn't actually hit .471, we should not state "he hit .471" to the reader. We could hedge that ("incomplete stats") and I guess we will, but really the Negro League stats -- not the Negro League teams and players themselves -- are just not in the same category as when we have complete stats.
It's a terrible shame. Of course the way America has treated African-American people from the slave trade forward is a world-historical crime, a terrible one and one of the worst in all history maybe. Of course we want to make up for that as much as we can. But we can't say things that aren't true. I would like to see what SABR has to say about all this. Not what Commissioner Rob Manfred, a businessman and lawyer whose remit is running an profitable enterprise and probably doesn't care all that much about baseball on the field or its history and certainly isn't going to study the matter. I don't care what he says about anything, and people just shouldn't. Herostratus (talk) 04:48, 16 June 2024 (UTC)Reply

Ty Cobb -- change back to .367?

edit

Yeah OK.WP:WEIGHT, "what I say is what matters", I hear you. So...

Right now, we give Ty Cobb's batting average as .366. At time editors have written that it is .367. but we don't go with that.

But MLB gives Ty Cobb's batting average as .367. It's discussed at length -- essentially by me; that's me all over, oh well -- at Talk:Ty Cobb#It's time and past time to fix the batting average thing and Talk:Ty Cobb#RfC: What should we give as Ty Cobb's lifetime batting average?. I'm not asking anyone to read all that. It's there if you like. So, if MBL has some WP:WEIGHT, or maybe a lot if you consider them official, should we revisit this? There's a number of ways we could present the info, like say:

  1. Ty Cobb's batting average was .366.
  2. Ty Cobb's batting average was .367.
  3. Some sources give give Ty Cobb's batting average as .366, some as .367.
  4. According to Major League Baseball, Ty Cobb's batting average was .367. Many non-official sources claim that it is .366. [N.B. I say "many" but not "all" because some books say .367. -ed]

If you say #1, that'd be an exception to giving any WP:WEIGHT to MLB. Is it impossible that there could be other exceptions to giving them any weight? Just saying. Herostratus (talk) 03:12, 13 June 2024 (UTC)Reply

I'm fairly certain that the horse is dead, and a third bite at the apple will be fruitless. Feel free to reply with your own maxims/puns as you desire, but I doubt the community has any appetite for revisiting this matter yet again. LEPRICAVARK (talk) 04:54, 13 June 2024 (UTC)Reply
Yes I agree, as long as we are not going to be like "We give weight to MLB.com on historical matters, except when we don't want to" (like here). That's not excellent. Herostratus (talk) 04:48, 16 June 2024 (UTC)Reply

Template:MLB standings look a bit broken now

edit

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. Spesh531(talk, contrib., ext.) 14:45, 14 June 2024 (UTC)Reply

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)Reply
Upon further reflection, it should be possible to wrap the American League and National League sections with a <div> 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)Reply
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 Template:MLB standings/testcases § Testing sandbox template: standings on MLB season page using flexbox layout. 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)Reply
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)Reply
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)Reply
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)Reply
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. Spesh531(talk, contrib., ext.) 05:44, 15 June 2024 (UTC)Reply
Please feel free to add more testcases! I've made some updates. isaacl (talk) 07:00, 15 June 2024 (UTC)Reply
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. Spesh531(talk, contrib., ext.) 14:34, 20 June 2024 (UTC)Reply
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)Reply
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! Spesh531(talk, contrib., ext.) 15:55, 21 June 2024 (UTC)Reply
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)Reply
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 {{nbnd}} ("‍–‍") 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. Spesh531(talk, contrib., ext.) 15:24, 26 June 2024 (UTC)Reply
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. Spesh531(talk, contrib., ext.) 15:40, 26 June 2024 (UTC)Reply
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. Spesh531(talk, contrib., ext.) 15:57, 26 June 2024 (UTC)Reply
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)Reply
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)Reply
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 {{nbnd}}. 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. Spesh531(talk, contrib., ext.) 17:06, 26 June 2024 (UTC)Reply

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" | [[Win (baseball)|W]]
  ! width="24" | [[Loss (baseball)|L]]
  ! width="35" | [[Winning percentage|Pct.]]
  ! width="27" | [[Games behind|GB]]
  ! width="39" | [[Home (sports)|Home]]
  ! width="39" | [[Road (sports)|Road]]


  ! width="245" | Team
  ! width="24" | [[Win (baseball)| W ]]
  ! width="24" | [[Loss (baseball)| L ]]
  ! width="35" | [[Winning percentage|Pct.]]
  ! width="27" | [[Games behind| GB ]]
  ! width="39" | [[Home (sports)|Home]]
  ! width="39" | [[Road (sports)|Road]]

Basically, the "W" and "GB" each have an instance of &nbsp; before and after it, while "L" has &numsp;, since "L" is narrower than "W".

Within the brackets, it would look like this: "Win (baseball)|&nbsp;W&nbsp;", "Loss (baseball)|&numsp;L&numsp;", and "Games behind|&nbsp;GB&nbsp;". (I hate trying to show examples of html text as it would look in an edit!) Spesh531(talk, contrib., ext.) 17:41, 26 June 2024 (UTC)Reply

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)Reply
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)Reply
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. Spesh531(talk, contrib., ext.) 18:25, 26 June 2024 (UTC)Reply
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)Reply
<syntaxhighlight>...</syntaxhighlight> is a good way to show code examples. For example: [[Win (baseball)|&nbsp;W&nbsp;]] (See mw:Extension:SyntaxHighlight for more details.) isaacl (talk) 18:17, 26 June 2024 (UTC)Reply
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! Spesh531(talk, contrib., ext.) 18:26, 26 June 2024 (UTC)Reply

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)Reply

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)Reply

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. Spesh531(talk, contrib., ext.) 23:59, 26 June 2024 (UTC)Reply
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)Reply
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! Spesh531(talk, contrib., ext.) 01:07, 27 June 2024 (UTC)Reply

To summarize, the following changes are being proposed:

  • 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.

Template:MLB standings/testcases § Testing sandbox template: standings on MLB season page using flexbox layout 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. Template:MLB standings/testcases § Testing sandbox template: standings on MLB season page using columns 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)Reply

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! Spesh531(talk, contrib., ext.) 01:30, 4 July 2024 (UTC)Reply
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)Reply
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)Reply
I've updated the MLB standings template with the proposed changes. isaacl (talk) 15:27, 6 July 2024 (UTC)Reply
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? Spesh531(talk, contrib., ext.) 18:28, 7 July 2024 (UTC)Reply
I've noticed why it happens! Whenever a team has triple digit wins or losses, the table gets wider. Spesh531(talk, contrib., ext.) 18:47, 7 July 2024 (UTC)Reply
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)Reply

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

Strike zone and Base on balls opening image crop request

edit

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)Reply

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)Reply

Disruptive IP

edit

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)Reply

Requested move at Talk:Tony Kemp (baseball)#Requested move 8 June 2024

edit
 

There is a requested move discussion at Talk:Tony Kemp (baseball)#Requested move 8 June 2024 that may be of interest to members of this WikiProject. Safari ScribeEdits! Talk! 20:38, 1 July 2024 (UTC)Reply

Merge proposal: Dalton Rogers

edit

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)Reply

Cumulative win-loss record for head-to-head rivals

edit

I have started a discussion at Talk:Major League Baseball rivalries#Relevance of head-to-head win-loss records 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)Reply

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. Spesh531(talk, contrib., ext.) 16:56, 8 July 2024 (UTC)Reply
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)Reply

Adding (or removing?) stats to League leaders sections in season pages

edit

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. Spesh531(talk, contrib., ext.) 17:11, 8 July 2024 (UTC)Reply

Creating pages for Milwaukee Braves, Kansas City Athletics, and Washington Senators (1961–1971)

edit

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).

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. Spesh531(talk, contrib., ext.) 16:04, 11 July 2024 (UTC)Reply

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)Reply
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)Reply
Yep, here's the RFC. Nemov (talk) 17:14, 11 July 2024 (UTC)Reply
A 2022 request for comments discussion resulted in Wikipedia:Naming conventions (sports teams) § North American sports teams 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)Reply
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.
Spesh531(talk, contrib., ext.) 18:02, 11 July 2024 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply

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)Reply