Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.
// request.cf · coarse context
A page that knows where it met you.
Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.
This article is part of WikiProject Formula One, an attempt to improve and standardize articles related to Formula One, including drivers, teams and constructors, events and history. Feel free to join the project and help with any of the tasks or consult the project page for further information.
Latest comment: 8 days ago21 comments4 people in discussion
Can the format of the calendar table be edited so that the overall column/table widths are not fixed, and it is therefore significantly easier to read on smaller or mobile devices. The formula e page achieves this nicely. Wiki wikied (talk) 18:50, 20 July 2026 (UTC)Reply
Actually the Formula E wiki page contains 5 columns to this pages 4. This page contains the round, the name, the circuit (incl city) and the date. The formula e page also contains the country, although the circuit name seems a shorter form.
Regardless though, this isn't the point of the question. If I goto the formula e page on a mobile device, the table resizes depending on my device - including if I'm looking at the table in portrait or landscape. This means that the overall table is no wider than my screen as the reader, and each row has a height that is dynamic, and the texts wraps within each cell as needed.
This is a much better viewing experience for anyone on a smaller device as the user doesn't need to scroll left and right to read a single row.
For anyone used to the current layout who doesn't have this issue (assuming they visit on a standard laptop/PC with a much larger screen size than a mobile device), then this wouldn't change as making the table dynamic would still render 1 line per row for those devices, and would only change (to assist) those on smaller devices and make it easier to read and more accessible. Wiki wikied (talk) 07:59, 23 July 2026 (UTC)Reply
The number of columns in a table is obviously irrelevant, it is the contents of the cells that are important, and the Formula E table benefits from containing substantially less information. But I understand that's not your concern. As for what method of display is more readable/accessible, that is ultimately a matter of preference, and incidentally I prefer the status quo. I don't have anything further to comment on that formatting choice. 5225C(talk•contributions) 10:22, 23 July 2026 (UTC)Reply
It is not a matter of preference, it is a matter of accessibility. And I do not think (and I have argued this many times before) that no wrapping literally everything is an accessibility improvment. I do not see why you are so against allowing cells to wrap around multiple rows to make reading the width of the table easier. SSSB (talk) 10:53, 23 July 2026 (UTC)Reply
Use Proportional Sizing, Rather than Absolute Sizing
The rule that applies to layout tables also applies to data tables. Let the browser window determine the width of the table whenever possible, to reduce the horizontal scrolling required of those with low vision. If cell widths need to be defined, use relative values, such a percentages, rather than pixel values. Defined cell heights should generally be avoided so the cell can expand downward to accommodate its content - something especially useful for users with low vision that may enlarge text content.
And we don’t use any fixed values for heights and widths whatsoever. The font size is defined through a percentage and the width of the columns is automatically scaled by the browser window to the widest entry of each column. Tvx1 13:50, 26 July 2026 (UTC)Reply
Forcing it to appear on one line means that readers have to constantly scroll back and forward to read the text which makes it more difficult to process such text effectively. You might think it a minor issue but to some people it makes a genuine difference. And I have frankly had enough of some editors on this wikiproject putting personal aesthetics choices (some of which aren't very aesthetic in my opinion anyway) over practicality. Do I think we should remove all nowraps, no. (that would generate cells where each line contains one word). But right now we use nowraps excessively. Not just in the calendar table but also in the constructor championship table an the general results table (constructor names for example can be very long and there is no benefit in forcing it into one line). We should sacrifice so-called aesthetics for the benefit of greater accessibility. I have done a mock up of a more acceptable example of the calendar table at User:SSSB/sandbox#Test which I think works much better. Please take your phone out and judge. SSSB (talk) 09:47, 26 July 2026 (UTC)Reply
Sorry, but no your example is no improvement in any way. The base width of the table is such that scrolling is always necessary, which means there is no benefit in allowing wrapping. The decision to apply nowrap everywhere was a carefully weighted one achieved through multiple discussions and was not done for aesthetics but because we determined that wrapping often hampered readability.Tvx1 13:21, 26 July 2026 (UTC)Reply
Excessive wrapping does hamper readability. But so does excessive nowrapping. We have gone from one extreme to the other whereas we need a sensible middle ground. My example does eliminate scrolling on some devices and in all cases it reduces scrolling significantly. By extension readability is also improved. SSSB (talk) 13:28, 26 July 2026 (UTC)Reply
No, your example is no improvement on readability whatsoever. I have a mobile device with a rather large screen and it still leaves me with siginicant scrolling. I can’t image there being many devices where it actually eliminates it or even significantly reduces it. It results in everything happening that this project decided years ago that should be avoided, like circuit names being randomly split in random places and term Grand Prix also being randomly being split in half. I also strongly disagree with your notion that scrolling automatically reduces readability. You are making much more of an evil out of it than it is. Tvx1 13:44, 26 July 2026 (UTC)Reply
"everything happening that this project decided years ago that should be avoided"? WP:Consensus can change. And what's wrong with circuit names or "Grand Prix" being split in half. We wouldn't nowrap these terms in running prose, so I see no reason to do so here. I'm also not making an "evil" out of anything. I am merely arguing that excessive nowraps are hampering readability. My proposal narrows the table (on relevant tables) by apporximatly 30-40% (calculated by counting characters from left to right). I would call that a significant scrolling reduction. This will be more pronouced on narrower screens (as they currently have to scroll further). Out of interest, do you think my propsal makes readability worse, or just no improvement? SSSB (talk) 12:06, 27 July 2026 (UTC)Reply
And I’m arguing that excessive nowraps don’t hamper readability. You keep falsely assuming that scrolling is the only argument to determine readability. Which is wrong. Your comparison with prose also doesn’t make sense. Terms being split on the end of a line in running prose is not an issue because you naturally expect a split there while reading. Likewise each row in a table is one line and thus you don’t multiple splits on that same line. Having to read down up down up down and up again on one and the same line is the worst thing with regards to readability. So the last thing we should do is to reintroduce random splits bases on screen size.
And thus I maintain that your example makes readability far worse. In some cells each word is squashed onto another line even on my screen and I have a rather large one. That is just no acceptable. Tvx1 11:24, 1 August 2026 (UTC)Reply
"Each word is squashed onto another line" it shouldn't be, because I specifically added nowraps to prevent one-word-per-line cells. We clearly have different ideas of what is best for readability. SSSB (talk) 12:34, 1 August 2026 (UTC)Reply
@Tvx1 in response to your view that you "can’t image there being many devices where it actually eliminates it or even significantly reduces it", please see some screenshots. This is how Wiki renders automatically on my device - a rather standard sized mobile phone with a 6.2" display.
To me, the difference is clear and obvious and, handled correctly, I believe the display could be made very clear without need to scroll on smaller devices whilst making no difference to users on larger displays (PCs, laptop, etc).
nb. When I say without need to scroll on smaller, I mean left and right to simply try and read 1 line after another. It may need to scroll down to read top to bottom, but this is standard as users read through and, imo, very unlikely to result in the continued scrolling that is currently needed when accessing this page on mobile devices
Screenshot dated 20260731 of Wikipedia page for 2026 F1 season, specifically focussing on calendar section - unable to see whole of table on mobile device
Screenshot dated 20260731 of Wikipedia page for 2025/26 FormulaE season, specifically focussing on calendar section - able to see whole of table on mobile deviceWiki wikied (talk) 18:02, 31 July 2026 (UTC)Reply
Could you please stop comparing our calendar with a Formula E one. They are different tables with a different amount of content and will always look different. My comments dealt with SSSB’s sandbox example of a "better" version of our F1 calendar, which I maintain isn’t better at all.
And it’s great that the FE table looks good (which I don't even agree with) on your screen, but that is only your screen. Your screen is not everyone’s screen. Add to that that calendar content varies every season it’s just pure random luck whether a wrapping table fits well on a particular screen.
You just make scrolling into a problem that it really isn't at all. And by the way, the desktop view exists on mobile devices as well! Tvx1 11:09, 1 August 2026 (UTC)Reply
Your screenshots just show the scrolling must now be vertical rather than horizontal. I have a hard time taking the notion that this is a real problem seriously. It's obviously a mere stylistic preference and I repeat my preference for the status quo. 5225C(talk•contributions) 11:36, 1 August 2026 (UTC)Reply
ok. As we can't get past this personal preference discussion, I have reviewed Wikipedia guidance on the topic.
Setting no widths is preferred wherever possible. This is because the browser can adjust table content to suit the browser window, device size, portrait view, landscape view, zoom settings, user-end font size choices, and other constraints...
Test tables in narrower browser windows. Test in both desktop and mobile views (on cell phones in portrait orientation). See the mobile or desktop view link at the bottom of this Wikipedia page. Use a cell phone to get the true mobile view... Wiki wikied (talk) 12:21, 1 August 2026 (UTC)Reply
Latest comment: 13 days ago2 comments2 people in discussion
Please re-insert the cancelled GPs and mark them as cancelled. Also, that "Bahrain GP" in Singapore needs to be named after fact, not fiction. --~2026-36827-05 (talk) 13:57, 26 July 2026 (UTC)Reply
On the first point, I am willing to have a discussion on this (but you need to provide a rational) but it is this way based on standing practice and consensus established in previous seasons. On your second point, I don't understand your objection. The "fact" is that it is called the "Bahrain Grand Prix". Calling it the Malaysian Grand Prix would be the fiction. SSSB (talk) 12:08, 27 July 2026 (UTC)Reply
As far as I can tell, the Bahrain Grand Prix has been reinstated but will be hosted in Malaysia, perhaps retaining the Bahrain Grand Prix name. At the time of writing, this does not seem official so it seems like someone has jumped the gun a bit. -- Scjessey (talk) 21:56, 27 July 2026 (UTC)Reply
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?
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.
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)Reply
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)Reply
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)Reply
Latest comment: 2 days ago2 comments2 people in discussion
The problem of violating international rules and showing Ukrainian Crimea as russian has still persisted over the years. I feel like if a certain Cherkash user wants to use F1 Wikipedia to push his poltical war supporting views, he should be banned from editing materials about the compretitions. RMN120501 (talk) 15:27, 7 August 2026 (UTC)Reply
Not done for now: please establish a consensus for this alteration before posting an edit request. See the discussion above this edit request. Umby 🌕🐶 (talk) 01:02, 29 July 2026 (UTC)
