Talk:2026 Formula One World Championship

Request for Comments: Table wrapping and width formatting for calendar tables

Should fixed cell formatting (e.g., {{nowrap}}) in calendar tables be reduced to allow text wrapping on mobile devices? Wiki wikied (talk) 12:25, 1 August 2026 (UTC)

Should the calendar tables on this page be formatted to allow natural line wrapping on narrower screens, or should fixed formatting (such as {{nowrap}}) be maintained across table cells?

Summary of arguments

• Option A (Allow text wrapping): Proponents note that reducing fixed widths and {{nowrap}} rules aligns with Help:Width of tables, columns, and cells and WP:ACCESSIBILITY (specifically WebAIM guidance on proportional sizing), reducing horizontal scrolling and improving usability on mobile screens in portrait orientation.
• Option B (Maintain fixed formatting / Status quo): Opponents argue that line breaks within short proper nouns (e.g., circuit names or "Grand Prix") reduce legibility, and that horizontal scrolling is preferable to multi-line cell expansion on narrower displays.

Wiki wikied (talk) 12:25, 1 August 2026 (UTC)

Support Option A. Per Help:Width of tables, columns, and cells, tables without rigid width constraints or excessive {{nowrap}} tags adapt far better to varying screen sizes, orientations, and user zoom levels. For mobile users in portrait mode, eliminating horizontal scrolling significantly improves reading comprehension and accessibility, conforming to external guidelines such as WebAIM. While excessive wrapping can be unsightly, a balanced middle ground—removing hard wraps on non-essential text—makes the table far more accessible without sacrificing readability on desktop devices. Wiki wikied (talk) 12:26, 1 August 2026 (UTC)

I think some uses of {nowrap} are necessary in tables, especially on mobile devices, where short names or phrases may otherwise wrap in awkward ways. However, excessive use of {nowrap}, which effectively forces almost everything to remain on the same line, can also create problems.

In my opinion, the issue is much more complex than it may first appear. I would prefer not to support either option, as I have not spent the considerable amount of time needed to weigh all the many factors involved.

What I think could be done is to allow versions with less nowrap formatting to remain in the current article, and only in this article, as proposed by the editors who have raised concerns about the status quo. This would allow us to receive feedback during the season from other editors, including those who may have concerns about excessive wrapping. It would also allow us to see in practice how a different approach could be applied, either in one section or in several sections, and to identify both the benefits and the problems that the change may bring.

To be clear, this change would only be a trial for this season’s article, so that we can see how it works in an ongoing article alongside the discussions taking place here. It would not mean that the existing convention has changed. ΘΘεοχάρης (talk) 22:02, 1 August 2026 (UTC)

@5225C @Tvx1 given the current consensus is moving towards change, albeit with limited overall numbers so far, following this proposal from @ΘΘεοχάρης I suggest we modify the 2025 season calendar so we can see and share the visual and practical differences concerning everyone and display images side by side, contracting 2025 changed calendar with 2026 status quo calendar.

The aim will be to make multiple iterations of the table format that will satisfy the majority.

For each change, we can add an RFC to contrast against the 2026 calendar.

Let me know your view on this so we don't get into a change it/change it back scenario please. Please let me know by Monday 7th. Wiki wikied (talk) 08:12, 31 August 2026 (UTC)

@Wiki wikied I support your position on the nowraps, but I oppose continuing this discussion beyond this RfC. I also don't agree with ΘΘεοχάρης's of trialling nowraps within a single article with the appearent aim of increasing participation. Noone not following this page will be aware that this is a trial run. We need to let someone close this discussion and move on with improving Wikipedia in other areas. SSSB (talk) 08:19, 31 August 2026 (UTC)

@SSSB edit to this page was an error, I meant to change a previous year but somehow reloaded the current page in error prior to hitting edit. Ignore that Wiki wikied (talk) 10:24, 31 August 2026 (UTC)

You don’t apply test edits to any article. Not a current one, not a previous one. We have sandboxes for that. Tvx1 11:59, 31 August 2026 (UTC)

Excuse me? Who gave you the authority to impose deadlines on us? We will reply when we'll see fit. Tvx1 12:01, 31 August 2026 (UTC)

Comment: One way to improve the table would be to remove "Grand Prix" from every cell in the "Grand Prix" column, because it is completely redundant. You could also remove the cities from the "Circuit" column since readers already get a sense of where the event is held from the "Grand Prix" column and then can click on the circuit links for specific information. That would significantly reduce the amount of content in the table without affecting its value. -- Scjessey (talk) 18:07, 2 August 2026 (UTC)

Option B – Per my comments in the above discussion. 5225_C (talk • contributions) 13:03, 4 August 2026 (UTC)

Option B – I don't understand why this is being forced through an RFC (which should be held on the talk page of one relevant article anayway). Why can't some people just take no for an anwser. I have explained the problem more than well enough during the discussion. Removing the nowraps results in the readability of the tables being just a case of random luck based on the particular reader's device's specific screen size. This all boils down to one person's personal dislike for scrolling (which I don't understand). And scrolling isn't even required. You can very easily use the desktop view on whatever device you like, desktop, laptop or mobile.Tvx1 11:58, 18 August 2026 (UTC)

Why can't some people take no for an answer? Because that's not how consensus on Wikipedia works. SSSB (talk) 09:14, 20 August 2026 (UTC)

Dropping the stick is very much part of how Wikipedia works.Tvx1 19:58, 20 August 2026 (UTC)

Two people saying no does not constitute a dead horse. In fact, given this RfC is 50:50, the horse is very much alive. SSSB (talk) 20:02, 20 August 2026 (UTC)

It’s still exactly the same no consensus situation.Tvx1 09:52, 22 August 2026 (UTC)

• Option A I agree that nowraps have their place, but this wikiproject seems to have an insistence on nowraping literally every cell in every table. Some of the other users here are not accurately reflecting the arguements. This is not a "personal dislike for scrolling" (if Tvx1 wants to go down that route I can just misrepresent his arguemnt as a "personal dislike of text wrapping") it is an opinion that horizontal scrolling reduces readability and we can mitigate this by being more pragmatic about how we use no wraps. No wraps should be used to prevent columns in our tables becoming unnecessarily narrow. They should not be used to indiscriminatly force everything onto one line. I also don't think Tvx1's claim that scrolling isn't requried because you can just change to desktop view. To me this feels like an admission that this is a problem. Not only will some readers not know how to switch between mobile and desktop view. The text in desktop view is then too small to read on my mobile phone. We can heavily reduce the scrolling by allowing cells in tables to wrap across multiple lines. Tvx1 doesn't understand the problem with horizontal scrolling. I don't understand the problem with wrapping text on multiple lines. SSSB (talk) 09:34, 20 August 2026 (UTC)

  This very much boils down to a personal dislike for scrolling. Neither of you have provided any proper evidence that scrolling is an actual problem. And you are overstating the issue. You are making much more of a drama out of this than it is. Moreover, your proposals only serve to move the scrolling from horizontal to vertical.

  And if have explained the problem with wrapping more than clearly enough. With random wrapping it’s just down to random coïncidence whether the contents remains readable for a specific reader. There is no way anymore to guarantee a consistent appearance. I won’t keep repeating myself.

  As for your comments regarding the desktop view, changing to it is child’s play and you can zoom in using your fingers.Tvx1 19:56, 20 August 2026 (UTC)

  If I zoom in with my fingers I am still scrolling horizontally so that "solution" isn't a solution at all. It is also only child's play if you know that funcationality exists. I also think that vertically scrolling is beneficial to horizontal scrolling. After all youu scroll vertically to read the article, I don't see the issue with scrolling horizontally to read a table (which depending on the device and the table isn't a guaranteed necessity anyway. As for "random coincidence". It is only random coincidence if you remove the nowraps entirely. I have made very clear that (at least I) intend to keep some nowraps to avoid excessive wrapping.

  I think we are simply going to have to agree to disagree about whether wrapping is problamtic, about whether horizontal scrolling is problamatic and about whether you or I have explained anything clearly enough. SSSB (talk) 20:09, 20 August 2026 (UTC)

  There is no need to zoom so much that it requires you to scroll. And yes you scroll down when reading an article, but not repeatedly down and up again and again to read one segment of text. And the latter is what you get if you squash everything together on a small screen.

  And as I have explained to you again and again, you just cannot guarantee good readability for every reader with just select nowraps. I just doesn’t work. Every device is different. The problem is just as much there as with no nowraps at all. I really don’t know why you refuse to understand that.Tvx1 10:02, 22 August 2026 (UTC)

  For starters, none of our cells contain so much information that you have to scroll up and down to read one segment of text. Our cells do not contain sentences of text, do they. As most it is an team name or curcuit information which can easily be put in two lines and require no scrolling in either direction.

  "There is no need to zoom so much that it requires you to scroll." - this is a bold statement from someone who continues to say that every device is different and every readers expirences Wikipedia differently. Because that might be true for you, but it isn't true for everyone.

  And I don't know why you continue to misrepresent my arguements in your responses. At no point I have I suggested that we can guarantee good readability for all readers. I have not claimed that it will be considered an improvement for all. Although your claim that some nowraps is as bad as no nowraps is ridiculous. No nowraps will cause one word per line cells. Select nowraps will allow cells to be limited to a maximum of 2 or 3 lines of text (realistically 2) instead of just one.

  Will the reduction of nowraps increase vertical scrolling for readers who read by column? Depending on the device and how far we take it: Yes. But right now, readers who read the table buy row have to do significant horizontal scrolling. I think it is a perfectly reasonable compromise to introduce a little vertical scrolling to reduce horizontal scrolling. I really don't understand why you are opposed to a little compromise. SSSB (talk) 12:42, 22 August 2026 (UTC)

  • There's no compromise involved, either the text wraps or it doesn't. There's no middle ground where we're all a little bit happy, either we get what we want or you get what you want. 5225_C (talk • contributions) 13:19, 22 August 2026 (UTC)

    There is a middle ground: the text wraps, but we insert no wraps strategically to avoid excess wrapping. It's not complicated. SSSB (talk) 14:46, 22 August 2026 (UTC)

    • Your "middle ground" sounds a lot like "Option A (Allow text wrapping)", which would be to the exclusion of "Option B (Maintain fixed formatting / Status quo)". 5225_C (talk • contributions) 01:47, 23 August 2026 (UTC)

      Just because you refuse to see this as anything other than black-and-white, it doesn't mean that it is black-and-white. Just because you oppose the compromise as much as the absolute, it doesn't mean that the compromise doesn't exist. We can introduce text wrapping whilst still maintaining a reduced level of fixed formatting. SSSB (talk) 06:17, 23 August 2026 (UTC)

      No we can’t. Strategic no-wrapping DOES NOT WORK! Whether that appears fine for a given reader is utterly random depending on the device size and screen resolution. You cannot guarantee that strategic no-wrapping works for everyone. You can only judge it for yourself on your own personal screen. Why can you not understand this simply thing?? Tvx1 11:10, 31 August 2026 (UTC)

      No, I can't guarantee that it works for everyone. Nor have I made the claim that I can. Nothing will work for everyone becauce some people (like you) don't want wrapping at all and other editors and readers do want wrapping. I have explained that multiple times. Why can you not understand that simple thing? SSSB (talk) 11:22, 31 August 2026 (UTC)

      Why can’t you understand thay your proposal will make things worse. It’s not better than what we have now anyway. I never claimed that the current situation is ideal for everyone, that’s what you claim of your propsal. The current version was achieved through thorough discussion which determined this works best for most of the readers. Tvx1 12:10, 31 August 2026 (UTC)

      Because I don't agree that my proposal will make it worse/not be a general improvement (not necessarily a universal improvement). Since you keep insisting that we provide evidence - why don't provide some for the claim it will be worse? SSSB (talk) 12:32, 31 August 2026 (UTC)

      I have thoroughly explained it to you repeatedly throughout the discussion. You just refuse to listen due to some inexplicible stuborness. Tvx1 14:58, 1 September 2026 (UTC)

• Option A Long time reader, just dipping my toes into editing. Strong support for doing away with excessive nowraps. Let the users browsers handle the scaling properly. When you are viewing most pages online these days, text blocks and tables scale automatically to the size of the screen/browser window. The help page the OP shared is pretty clear: "Nowrap in tables should be avoided. It can cause all kinds of problems in different screen sizes." CartographicGnome (talk) 03:39, 21 August 2026 (UTC)

• Option A: I agree with doing away with the excessive no wraps too. In my experience, horizontal scrolling does reduce readability and, at times, even reader interest as a result. Alternatively the compromise @SSSB suggested whereby we use strategic no wraps is also a good middle ground. MadelynnSienna (talk) 10:57, 23 August 2026 (UTC)

  Can you actually provide any evidence of your claims?Tvx1 11:11, 31 August 2026 (UTC)

  The claim is "in my expirence". What evidence are you looking for exactly? You are also coming across as rather hypocritical, given that you haven't exactly provided any evidence for any of your claims either. SSSB (talk) 11:25, 31 August 2026 (UTC)

  Delving in personal attacks now? The evidence I’m looking for is evidence that reader interest was lost by anyone. And why are you even replying to me here? My question was NOT aimed at you at all! Tvx1 12:13, 31 August 2026 (UTC)

  I said you are coming across as a hypocrite. I didn't actually call you a hypocrite. And if I have a response to your comment I can make it, even if the comment is not directed at me. SSSB (talk) 12:29, 31 August 2026 (UTC)

Support Option A, and I don't support adding "strategic" nowraps.-- Cerebral726 (talk) 13:43, 31 August 2026 (UTC)

Comment: It appears the OP is a single-purpose account aimed only at forcing this change through. Apart from two edits from twenty years ago, all the rest were dealing with this subject. They already had a go at this two years ago and even jumped to Dispute Resolution when they were not getting their way.Tvx1 15:09, 1 September 2026 (UTC)

It also appears OP kept deleting comments opposing his idea on the article Talk Page, even when warned multiple times not to do so. IsaacMDB23 (talk) 15:40, 1 September 2026 (UTC)

One could argue it appears the OP has gone away, done some research into wiki, and is trying to approach the same discussion in the correct manner having had little wiki editing input previously. Although, given the resistance they have experienced in actually debating change and experimenting with potential alternative options, they are unlikely to want to become a wider contributor at this stage. Wiki wikied (talk) 18:38, 5 September 2026 (UTC)

I take a broader view. I think, actually, when you think about it, whether or not you have table wrapping or width formatting in one way or another, or vitriolic responses from single-purpose accounts, ultimately this IS Wikipedia. This Is It. And as is obvious with Wikipedia, it is constructed solely by humans. Not Plagioclase. Therefore, we have to accept that we are all going to die. And that this is all absolutely futile.

If you want to genuinely contribute to something meaningful, perhaps consider contributing to the argument that is in favour of giving Terry-Thomas a fucking infobox. StartingAgainAgain (talk) 01:57, 25 September 2026 (UTC)

Semi-protected edit request on 4 September 2026

Change Pierre Gasly's position in Monaco from 3 to 7. Robinahh (talk) 11:29, 4 September 2026 (UTC)

Reasoning: https://www.fia.com/news/ica-decision-2026-06-07-08-09-hearing-25-08-26-mclaren-and-red-bull-2026-fia-formula-one-world

This might also need to be mentioned in the season summary. Robinahh (talk) 11:32, 4 September 2026 (UTC)

 Done MadelynnSienna (talk) 08:38, 5 September 2026 (UTC)

Already done – 5225_C (talk • contributions) 23:49, 4 September 2026 (UTC)

Semi-protected edit request on 27 September 2026

The introduction sites that the championship is hosting 22 Grands Prix. I feel that this is incorrect as they restablished the Bahrain Grand Prix (taking place in Malaysia). Wikifansmome (talk) 00:22, 27 September 2026 (UTC)

Corrected to 23 gps in the lead. SSSB (talk) 08:29, 27 September 2026 (UTC)

@SSSB thank you Wikifansome (talk) 21:16, 27 September 2026 (UTC)

Semi-protected edit request on 2 October 2026

Change the flag for the Bahrain Grand Prix from the flag of Malaysia to the flag of Bahrain ~2026-52918-65 (talk) 17:04, 2 October 2026 (UTC)

 Not done by WP:WikiProject Formula One consensus, the flag of the host country is used. Not the flag of the Grand Prixs namesake. Despite being named the Bahrain Grand Prix, the host country is Malaysia - hence the Malaysian flag. SSSB (talk) 17:39, 2 October 2026 (UTC)

Suggestions for table: World Drivers' Championship standings

When viewing the drivers' points table on a cell phone, it is difficult to line up the total points with each driver. This is because the driver names column is on the far left, and the points column is on the far right, with 23 race location columns in between. A cell phone isn't wide enough to cover the full width. The most important information on this table is: position #, driver name, and total points -- yet, the points column needs to be hunted for off screen.

Suggestion: Move the points column to be adjacent to the driver names column.

Also, this is the only F1 data platform (compared to Formula 1 website and Google summary) that doesn't list wins and podiums for each driver. This information shows the relative strength of each driver. (Pole count is optional, in my opinion.)

Suggestion: Add "Wins" column and "Podiums" column next to the Points column.

It would also be helpful to list each driver's contracted team name. The only location this information is available is at the top of the Wikipedia page, not convenient for cross referencing. As to not make the table too wide, use a shortened version of the team name (for instance, "ALP" not "Alpine-Mercedes").

Suggestion: Add "Team" name next to driver name.

Suggested column order:

Pos. - Driver - Team - Points - Wins - Podiums - Race 1 - Race 2 - ... - Race 23 ~2026-54783-47 (talk) 04:48, 13 October 2026 (UTC)