It's a table. As with most supplementary info such as diagrams and graphs, they're better kept right unless the table is very wide- this one isn't. On non cell phones the text flows neatly around the table. On cell phones it's left seeking anyway so makes no difference. GliderMaven (talk) 03:17, 2 December 2020 (UTC)[reply]
The table ist the primary source of this template, so seeing the links in reading direction first before the table itself soen't make any sense. In every publication the additional text is below a table, not left or right. I also checked your statement about the text flow and cannot verify it. On regular sized displays with 1920 pixel width, the table is placed after the written links on the far right side. You didn't ask before your unexplained edit and i ask you to undo it with an explanation. Please be cooperative. --Angerdan (talk) 21:39, 5 December 2020 (UTC)[reply]
Since the primary element is the table, secondary elements should be after the primary one. So i do suggest to keep the spllementary info after the table. When there is no objective argument against this, i'd change it in a few days. --Angerdan (talk) 19:59, 11 December 2020 (UTC)[reply]
Careful here. This template is used by Wi-Fi. I was referring to the entire table appearing in the middle of the Wi-Fi article because you removed the 'floatright' at the top, rather than tucked over to the right of the page. You not only messed up the formatting in Wi-Fi by making the table not be right-seeking, you then managed to mess up again, even worse, by adding the reflist in the included portion. That meant that the references appeared in the middle of the Wi-Fi article rather than at the end. I've fixed that now, but I'm concerned about your editing. Templates are among the most technical parts of editing Wikipedia, and it's easy to create unintended consequences. Please always, always check the articles that transclude templates to make sure, that's twice you clearly haven't done this. GliderMaven (talk) 02:30, 13 January 2021 (UTC)[reply]
I added parenthetical (Wi-Fi n)* tags for Wi-Fi 1, 2, 3 and prefixed the bottom row unbranded explainer with a '*'.
There may be a better convention than '*', but '*' seemed intuitive.
Wi-Fi 3E is mentioned in the bottom row, but is (no longer) mentioned in the Duckwave reference and should be omitted. LarryLACa (talk) 09 November 2021 (UTC)
fix format, cleanup renumber comment
The Wi-Fi Alliance started generation numbering with 11ac as Wi-Fi 5,
allowing for the Alliance versions b/a/g/n as generations 1/2/3/4 which by implication
meant the pre-Alliance, 802.11-1997 (802.11 Legacy) would be Wi-Fi 0, awkward but reflective of the pre-branding origin.
I propose to refrain from using the terms Wi-Fi 3, Wi-Fi 2, Wi-Fi 1, and especially Wi-Fi 0. Wi-Fi Alliance never introduced these terms. If some magazines invents these terms it doesn't mean that such names are widely used or well specified. On the contrary, there may be different, conflicting definitions of what qualifies as Wi-Fi 3 etc. 2001:9E8:4613:A100:819B:AAE0:2254:44B0 (talk) 18:48, 26 June 2024 (UTC)[reply]
Numerous issues caused by an anonymous IP editor. Most of the edits since then have been to correct those. I have reverted back to the last good version. Apologies if your good faith edit was affected. Ng.j (talk) 23:18, 14 September 2023 (UTC)[reply]
The citation provided for Wi-Fi 8/802.11bn frequencies does not mention 42 or 71 GHz. However, the everything RF article cited in the "Maximum link rate" column links to a PAR document, which mentions "carrier frequency operation between 1 and 7.125 GHz and also 42.5 and 71 GHz". It is unclear whether the entire 42.5-71 GHz range would be used, especially considering only parts of the 1-7.125 GHz range are available for Wi-Fi. Keymakery (talk) 22:24, 25 March 2024 (UTC)[reply]
The everything RF article has a similar table which states "2.4/5/6 GHz, mmWave" as Wi-Fi 8's expected frequency bands. Seems like we can replace "42, 71" with "mmWave" and switch the citation to that page? Keymakery (talk) 22:42, 25 March 2024 (UTC)[reply]
It doesn't make sense to blend the lowest data rates for IEEE 802.11 (1 Mb/s), 802.11a (6 Mb/s) etc. with some arbitrary low data rates of later MIMO PHYs. At the lower end of the PHY data rates is the rate that a single client with a single MIMO stream in the smallest channel size may experience. Beginning with IEEE 802.11ax, this minimum data rate has reduced to 400 kb/s because with the introduction of OFDMA channel (resp. Resource Unit) sizes down to 2 MHz are introduced.
Many sources quote early reports about IEEE 802.11be that assumed that 16 MIMO streams would be supported. However, until and including the latest draft (D6.0 as of today) 802.11be is limited to supporting eight streams. This won't change anymore. Thus, the maximum data rate for a single 320 MHz channel is capped at 23 Gb/s. With MLO, multiple channels in multiple bands could be aggregated. However, considering this option would require further clarifications or render the table completely confusing. 2001:9E8:4613:A100:819B:AAE0:2254:44B0 (talk) 17:15, 26 June 2024 (UTC)[reply]
The IEEE 802.11bn PAR explains this project will not support millimeter wave bands. Thus, 60 GHz and 42 GHz bands are not in scope for IEEE 802.11bn. There might be a separate IEEE 802.11 project that could port IEEE 802.11bn in the millimeter wave bands. At this time, this project does not exist and thus, does not have a project name. 2001:9E8:4613:A100:819B:AAE0:2254:44B0 (talk) 17:20, 26 June 2024 (UTC)[reply]