This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the
GFDL, version 1.3 or later.
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Just because the term 'byte sex' can redirect here doesn't mean this article should discuss it in the first paragraph. This is a bit of obscure historical jargon which is no longer in current use. At best it belongs in a footnote. –
jacobolus(t)18:18, 9 January 2023 (UTC)reply
For all practical purposes the term is extinct, most younger practitioners will not recognize it, linux.bytesex.org notwithstanding, and we are
WP:NOTDICT, so the lead is a bad place for this synonym (I have no objections against the redirect, and, most likely, some anchor in the text). I agree that even now the term is
WP:UNDUE that high in the article, unless the section is expanded to cover much more widespread terms: "network byte order" is currently relegated to mid-article, "host order" is even lower and has no coherent definition whatsoever.
Dimawik (
talk)
05:28, 11 January 2023 (UTC)reply
Regarding the
removal of "bit endianness": the term is easy to find in the literature (e.g.,
[1], a book by Springer). The deleted text about the error-correcting codes was also factually correct (I expect it to be hard to find a source for the latter, though). I happen to like the new text more, and think that the error correction minutiae are out of scope here altogether, but, probably, it is worth adding back the "bit endianness" term somewhere in the text (not in the section header)? Pinging @
Kvng:Dimawik (
talk)
03:58, 25 April 2023 (UTC)reply
Bit endianness is less of a problem, but still exists. Some hardware has the ability to address bytes. Even when it doesn't, hardware descriptions don't always number bits the same way. Yes it happens at a lower level, but for those working at that level, it is important.
Gah4 (
talk)
05:06, 25 April 2023 (UTC)reply
Yes, anyone who tried to code
bit fields in a
portable way knows the problem well. The issue here is a terminological one: should we mention the term "bit endianness" or be happy with a more popular "bit order"?
Dimawik (
talk)
07:25, 25 April 2023 (UTC)reply
Thanks for the comments. We do have a
Bit endianness redirect (which I broke) so I should restore that (with a ref). There is
Dimawik's question about preferred terminology here. Any opinions?
The "harm" is massing up both wikitext and article text with large paragraphs which by definition simply repeat what is in the article. A citation should point the reader to the relevant source. Unless it is lost to time, including the actual content here is overkill. There may occasionally be grounds for this but that should be the exception.
BOLDSYN refers to the article's lead, and very very very very very very obviously does not justify bolding the phrase "big" 75% of the way through this article.
Any table content not intelligible with a screen reader is harmful, and the meaning of these tables can (as demonstrated) be perfectly encapsulated in text form without causing readability issues to unsighted readers.
Disambiguation belongs in the article headers. Occasionally a similar but distinct topic might deserve some coverage in the body, but this was overkill for what is basically a dissimilar concept that happens to occasionally be known by a similar name.
If there are good, reliable sources for NUXI then so be it. Removing content which is sourced solely to Eric Raymond's Jargon File, which is pretty much the definition of an unreliable source (it is a self-published work which pretends to be authoritative, and has legions of examples of pushing ESR's own opinions) should not be controversial.
Using uncited material to verify a fact is the very definition of original research. The vast majority of readers are not coders, and using code examples is therefore one of the worst ways to provide evidence for a given statement.
Lastly, WP:DEMOLISH refers to the notion that articles should not be subject to the same rigorous standards as established articles during their creation. This article is fully 21 years old, making it more than mature enough to finally receive some serious editing (which by necessity will involve removing pieces of it).
The mantra that redirected terms must be bolded has metastasised into something it was never meant to be. If a term is unique and commonplace, then it should be bolded in the lead. It is categorically not necessary to treat article subsections as if they were mini-leads and to apply this all over again. And the subject of whether or not various minor synonyms deserved placement in the lead was already settled in previous discussion. So if a random search term happens to have a redirect to an anchor in an article, there is no mandate to bold it. Never was.
I am aware that the subject might benefit from a graphical demonstration, but it is very important to be sensitive on this front. Readers might not be using desktop browsers. They might be using screen readers. The article might be in audiobook format. Or any number of other issues. This is why we try to avoid presenting material in images or tables if there are alternative options. This article previously swung too far in the opposite direction. That's been holding it back.
With regards to NUXI,
this (not a reliable source, but still) does claim it predates Raymond. Though to be quite honest, any source from that period would almost certainly be more valuable for general discussion of this article's content than specifically for one synonym.
Chris Cunningham (user:thumperward) (
talk)
03:46, 11 December 2023 (UTC)reply
So where do we stand? To me it looks like we're at 0 for 6 toward resolution of these issues. Hopefully we'll get some comments from other editors to help us through this. ~
Kvng (
talk)
14:55, 11 December 2023 (UTC)reply
Wow! I just discovered what a major mess the article, or at least its intro, has become. A lot of rework or restoration is needed. Here I'll limit my comments to the items raised at the top of this section:
cite quotes are almost always pointless. The quote deletion is not a major issue, but I think this short quote should be restored. If the reader isn't interested, she can ignore it, otherwise it is a useful presentation that shows the nature of the invention of the term, often saving the annoyance of dealing with the whole of the source.
ascii art is a bad way of representing anything, and the text should be clear enough already: This section needs a diagram as for many readers it quickly makes clear the confused nature of the mixed- or middle-endian form; for those readers, prose is a barrier to understanding. For consistency, if nothing else, an SVG like half of the (to be restored) File:32bit-Endianess.svg would be desirable, but unless such appears, the table-based diagram is needed here. However, the table-based form should have the title/caption "Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11" removed from the table and instead be given as a prose introduction preceding the diagram provided by the table.
likewise. text does a perfectly good job here. Text can do an adequate job with this, and I think removal of these diagrams is warranted. This whole subject is peripheral to endianness, as it has only to do with treating multiple characters within an integer (or at least non-string) data type. I believe this section doesn't deserve significant space. The text that was substituted does not yet clearly explain the nature of the relationship of text in integers vs native strings.
just link this. No, the link is inadequate because the linked article doesn't cover the described aspects nearly as well as the text that was removed, nor does it try to make the relationship to endianness apparent. The "article"
Bit order is just a redirect to
Bit numbering, which is almost entirely concerned with labeling of bits (with numbers) rather than physical ordering of bits as in serial transmission.
more jargon file crap. I believe the NUXI Problem deserves mention, and the pre-change text seems appropriate.
cite needed, not code. A citation is needed, but at least until present I think the code is of interest and perhaps useful to the reader.
Amusingly I've just had a comment posted on my own talk saying that
the reorg was overdue, so obviously this is polarising. Nevertheless, the notion that it's more of a mess now than previously just doesn't stand up to any scrutiny.
That quote adds practically no value. Not only does it basically just reiterate what was just said in the text, it is irrelevant to this subject. It does not matter in the slightest what "big-endian" happened to mean in Gulliver's Travels because the term only transferred over as a homage and not due to any actual similarities in the notions being discussed.
I'm not opposed to a single re-bolding of the specific terms "big-endian" and "little-endian" in the introduction sentence if it satisfies all parties.
I'd be happy for this particular niche matter to be removed entirely, but felt that retaining a brief summary sans overbearing tables was a reasonable compromise for now.
When dealing with bits rather than bytes, this subject is simplified to "one end or the other" and is deeply banal. The only reason it warrants a full article to itself at byte-level is due to the complications that introduces.
Again, happy for it to be re-added if sourced to something less notoriously unreliable and prone to making up its own terms.
I will categorically state that there is no overlap between the set of people who can read Verilog and the set of people who are going to gain actual value from reading an article on endianness. Code examples are massively overused on Wikipedia and frequently pulled directly from the heads of their authors. We don't accept that sort of content for other topics. This is implementational trivia and its only hope of remaining here at all is with a secondary source.
Reading that talk page posting, I wouldn't put
Barometz in your column on the issues we're discussing here.
Barometz does appear to oppose your removal at least one of the diagrams.
R. S. Shaw seems to be a bit disparaging but I have not voiced complaints about reorganization. Your edits here are a mixed bag so there are certainly things to appreciate about them. ~
Kvng (
talk)
14:17, 14 December 2023 (UTC)reply
And as I've replied there, if restoring one of the images stops people complaining about the lack of diagrams without having to re-add ASCII art, so be it. It's not a matter of a binary yes/no on these changes: it's a case of where we go from here.
Chris Cunningham (user:thumperward) (
talk)
18:20, 15 December 2023 (UTC)reply
It would be nice if we could come to a consensus rather than starting an
WP:RFC and muscling through it. You seemed pretty immovable on 11 December. Are you coming around at all? ~
Kvng (
talk)
23:39, 15 December 2023 (UTC)reply
You raised a half-dozen points, all of which were individually trivial. This doesn't need an RFC. It needs for you to discuss said points individually instead of raising them as "should we revert all this user's edits".
Chris Cunningham (user:thumperward) (
talk)
03:44, 18 December 2023 (UTC)reply
You and I did one round of discussion and it doesn't look like either of us moved.
R. S. Shaw and
Barometz joined the discussion, didn't appear to be too impressed with your edits and suggested some potential compromises and you begrudgingly offered that we could restore a diagram a small amount of boldface. It doesn't feel like we're headed toward consensus with the current participants. What other ideas do you have besides an RFC? ~
Kvng (
talk)
04:14, 19 December 2023 (UTC)reply
What we normally do on Wikipedia is find common ground and then edit the article accordingly, which is much more productive than endlessly talking around things. To that effect I've made the two requested changes that there is consensus on (bolding BE and LE in the lead, and re-adding a diagram). Now, will you discuss your remaining concerns?
Chris Cunningham (user:thumperward) (
talk)
15:35, 19 December 2023 (UTC)reply
Done, but only on the understanding that this is a matter of diplomacy. That this article is chock-full of unsourced, tangential distractions which are not actually key to the subject matter is still a core concern, and I expect that whole section to be substantially edited in future.
Chris Cunningham (user:thumperward) (
talk)
00:34, 20 December 2023 (UTC)reply
Thanks and sorry for the delay. Let's try point #3 again. I say text and tables/diagrams together are good to support different comprehension styles and provide visual anchors for readers. You say only text is required and tables/diagrams create and
WP:ACCESSIBILITY issue. Am I missing anything?
What specifically is the accessibility issue you're concerned about? I have reviewed
WP:ACCESSIBILITY and see some concerns about large tables, font size, coloring; I don't see that any of that applies here. There is
WP:DTAB which explains how to make tables accessible. I believe the tables you removed already follow that and if not, we should be able to correct them without removing them. ~
Kvng (
talk)
16:37, 23 December 2023 (UTC)reply
I'm pretty sure that's referring to layout hacks like using a table with invisible cell boundaries to adjust text position. ~
Kvng (
talk)
12:58, 11 January 2024 (UTC)reply
Nothing in the wording of the guideline suggests this. In the absence of such qualifiers, the most obvious solution would be to follow what is actually written. There is no contradictory guideline suggesting that using ASCII markup for diagrams is acceptable.
Chris Cunningham (user:thumperward) (
talk)
23:21, 30 January 2024 (UTC)reply
The section you link to is titled Layout tables and starts with Avoid using tables for visual positioning of non-tabular content. I don't think you have much to stand on. As for your claim that we can't know what is intended, I think a discussion at
Wikipedia talk:Manual of Style/Accessibility would clarify things pretty quickly. ~
Kvng (
talk)
00:33, 31 January 2024 (UTC)reply
Then... start one?
MOS:LTAB only mentions data tables and layout tables (and has lots of strong wording discouraging the latter) for a reason: using tables to draw diagrams is not acceptable. See also the omission of this use in
MOS:TABLES. I'm entirely confident that "don't use tables for drawing squares" is the consensus already; the burden of proof there is for the person who has no more to go on than gainsaying.
Chris Cunningham (user:thumperward) (
talk)
15:33, 1 February 2024 (UTC)reply
Alright,
done. ETA: I'm away from computers for the next few days and may not be able to check in or respond to anything until next week. ~
Kvng (
talk)
15:59, 1 February 2024 (UTC)reply
That this has consensus is an egregious lie. This has worsened this article for the sake of an editor considering himself to have won a dispute. I've utterly no interest in cooporating with the furtherance of that petty little war, and will ensure that eventually this is rolled back.
Chris Cunningham (user:thumperward) (
talk)
23:34, 17 February 2024 (UTC)reply
Editors in the discussion have been willing to accept the version I presented with column and row headings. No one has expressed support for the original version without headings that was re-introduced.
isaacl (
talk)
00:17, 18 February 2024 (UTC)reply
@
Isaacl, A simple revert is not the intended final state but it is the place to start and I didn't see any objections when I proposed this approach. ~
Kvng (
talk)
01:15, 18 February 2024 (UTC)reply
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the
GFDL, version 1.3 or later.
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Just because the term 'byte sex' can redirect here doesn't mean this article should discuss it in the first paragraph. This is a bit of obscure historical jargon which is no longer in current use. At best it belongs in a footnote. –
jacobolus(t)18:18, 9 January 2023 (UTC)reply
For all practical purposes the term is extinct, most younger practitioners will not recognize it, linux.bytesex.org notwithstanding, and we are
WP:NOTDICT, so the lead is a bad place for this synonym (I have no objections against the redirect, and, most likely, some anchor in the text). I agree that even now the term is
WP:UNDUE that high in the article, unless the section is expanded to cover much more widespread terms: "network byte order" is currently relegated to mid-article, "host order" is even lower and has no coherent definition whatsoever.
Dimawik (
talk)
05:28, 11 January 2023 (UTC)reply
Regarding the
removal of "bit endianness": the term is easy to find in the literature (e.g.,
[1], a book by Springer). The deleted text about the error-correcting codes was also factually correct (I expect it to be hard to find a source for the latter, though). I happen to like the new text more, and think that the error correction minutiae are out of scope here altogether, but, probably, it is worth adding back the "bit endianness" term somewhere in the text (not in the section header)? Pinging @
Kvng:Dimawik (
talk)
03:58, 25 April 2023 (UTC)reply
Bit endianness is less of a problem, but still exists. Some hardware has the ability to address bytes. Even when it doesn't, hardware descriptions don't always number bits the same way. Yes it happens at a lower level, but for those working at that level, it is important.
Gah4 (
talk)
05:06, 25 April 2023 (UTC)reply
Yes, anyone who tried to code
bit fields in a
portable way knows the problem well. The issue here is a terminological one: should we mention the term "bit endianness" or be happy with a more popular "bit order"?
Dimawik (
talk)
07:25, 25 April 2023 (UTC)reply
Thanks for the comments. We do have a
Bit endianness redirect (which I broke) so I should restore that (with a ref). There is
Dimawik's question about preferred terminology here. Any opinions?
The "harm" is massing up both wikitext and article text with large paragraphs which by definition simply repeat what is in the article. A citation should point the reader to the relevant source. Unless it is lost to time, including the actual content here is overkill. There may occasionally be grounds for this but that should be the exception.
BOLDSYN refers to the article's lead, and very very very very very very obviously does not justify bolding the phrase "big" 75% of the way through this article.
Any table content not intelligible with a screen reader is harmful, and the meaning of these tables can (as demonstrated) be perfectly encapsulated in text form without causing readability issues to unsighted readers.
Disambiguation belongs in the article headers. Occasionally a similar but distinct topic might deserve some coverage in the body, but this was overkill for what is basically a dissimilar concept that happens to occasionally be known by a similar name.
If there are good, reliable sources for NUXI then so be it. Removing content which is sourced solely to Eric Raymond's Jargon File, which is pretty much the definition of an unreliable source (it is a self-published work which pretends to be authoritative, and has legions of examples of pushing ESR's own opinions) should not be controversial.
Using uncited material to verify a fact is the very definition of original research. The vast majority of readers are not coders, and using code examples is therefore one of the worst ways to provide evidence for a given statement.
Lastly, WP:DEMOLISH refers to the notion that articles should not be subject to the same rigorous standards as established articles during their creation. This article is fully 21 years old, making it more than mature enough to finally receive some serious editing (which by necessity will involve removing pieces of it).
The mantra that redirected terms must be bolded has metastasised into something it was never meant to be. If a term is unique and commonplace, then it should be bolded in the lead. It is categorically not necessary to treat article subsections as if they were mini-leads and to apply this all over again. And the subject of whether or not various minor synonyms deserved placement in the lead was already settled in previous discussion. So if a random search term happens to have a redirect to an anchor in an article, there is no mandate to bold it. Never was.
I am aware that the subject might benefit from a graphical demonstration, but it is very important to be sensitive on this front. Readers might not be using desktop browsers. They might be using screen readers. The article might be in audiobook format. Or any number of other issues. This is why we try to avoid presenting material in images or tables if there are alternative options. This article previously swung too far in the opposite direction. That's been holding it back.
With regards to NUXI,
this (not a reliable source, but still) does claim it predates Raymond. Though to be quite honest, any source from that period would almost certainly be more valuable for general discussion of this article's content than specifically for one synonym.
Chris Cunningham (user:thumperward) (
talk)
03:46, 11 December 2023 (UTC)reply
So where do we stand? To me it looks like we're at 0 for 6 toward resolution of these issues. Hopefully we'll get some comments from other editors to help us through this. ~
Kvng (
talk)
14:55, 11 December 2023 (UTC)reply
Wow! I just discovered what a major mess the article, or at least its intro, has become. A lot of rework or restoration is needed. Here I'll limit my comments to the items raised at the top of this section:
cite quotes are almost always pointless. The quote deletion is not a major issue, but I think this short quote should be restored. If the reader isn't interested, she can ignore it, otherwise it is a useful presentation that shows the nature of the invention of the term, often saving the annoyance of dealing with the whole of the source.
ascii art is a bad way of representing anything, and the text should be clear enough already: This section needs a diagram as for many readers it quickly makes clear the confused nature of the mixed- or middle-endian form; for those readers, prose is a barrier to understanding. For consistency, if nothing else, an SVG like half of the (to be restored) File:32bit-Endianess.svg would be desirable, but unless such appears, the table-based diagram is needed here. However, the table-based form should have the title/caption "Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11" removed from the table and instead be given as a prose introduction preceding the diagram provided by the table.
likewise. text does a perfectly good job here. Text can do an adequate job with this, and I think removal of these diagrams is warranted. This whole subject is peripheral to endianness, as it has only to do with treating multiple characters within an integer (or at least non-string) data type. I believe this section doesn't deserve significant space. The text that was substituted does not yet clearly explain the nature of the relationship of text in integers vs native strings.
just link this. No, the link is inadequate because the linked article doesn't cover the described aspects nearly as well as the text that was removed, nor does it try to make the relationship to endianness apparent. The "article"
Bit order is just a redirect to
Bit numbering, which is almost entirely concerned with labeling of bits (with numbers) rather than physical ordering of bits as in serial transmission.
more jargon file crap. I believe the NUXI Problem deserves mention, and the pre-change text seems appropriate.
cite needed, not code. A citation is needed, but at least until present I think the code is of interest and perhaps useful to the reader.
Amusingly I've just had a comment posted on my own talk saying that
the reorg was overdue, so obviously this is polarising. Nevertheless, the notion that it's more of a mess now than previously just doesn't stand up to any scrutiny.
That quote adds practically no value. Not only does it basically just reiterate what was just said in the text, it is irrelevant to this subject. It does not matter in the slightest what "big-endian" happened to mean in Gulliver's Travels because the term only transferred over as a homage and not due to any actual similarities in the notions being discussed.
I'm not opposed to a single re-bolding of the specific terms "big-endian" and "little-endian" in the introduction sentence if it satisfies all parties.
I'd be happy for this particular niche matter to be removed entirely, but felt that retaining a brief summary sans overbearing tables was a reasonable compromise for now.
When dealing with bits rather than bytes, this subject is simplified to "one end or the other" and is deeply banal. The only reason it warrants a full article to itself at byte-level is due to the complications that introduces.
Again, happy for it to be re-added if sourced to something less notoriously unreliable and prone to making up its own terms.
I will categorically state that there is no overlap between the set of people who can read Verilog and the set of people who are going to gain actual value from reading an article on endianness. Code examples are massively overused on Wikipedia and frequently pulled directly from the heads of their authors. We don't accept that sort of content for other topics. This is implementational trivia and its only hope of remaining here at all is with a secondary source.
Reading that talk page posting, I wouldn't put
Barometz in your column on the issues we're discussing here.
Barometz does appear to oppose your removal at least one of the diagrams.
R. S. Shaw seems to be a bit disparaging but I have not voiced complaints about reorganization. Your edits here are a mixed bag so there are certainly things to appreciate about them. ~
Kvng (
talk)
14:17, 14 December 2023 (UTC)reply
And as I've replied there, if restoring one of the images stops people complaining about the lack of diagrams without having to re-add ASCII art, so be it. It's not a matter of a binary yes/no on these changes: it's a case of where we go from here.
Chris Cunningham (user:thumperward) (
talk)
18:20, 15 December 2023 (UTC)reply
It would be nice if we could come to a consensus rather than starting an
WP:RFC and muscling through it. You seemed pretty immovable on 11 December. Are you coming around at all? ~
Kvng (
talk)
23:39, 15 December 2023 (UTC)reply
You raised a half-dozen points, all of which were individually trivial. This doesn't need an RFC. It needs for you to discuss said points individually instead of raising them as "should we revert all this user's edits".
Chris Cunningham (user:thumperward) (
talk)
03:44, 18 December 2023 (UTC)reply
You and I did one round of discussion and it doesn't look like either of us moved.
R. S. Shaw and
Barometz joined the discussion, didn't appear to be too impressed with your edits and suggested some potential compromises and you begrudgingly offered that we could restore a diagram a small amount of boldface. It doesn't feel like we're headed toward consensus with the current participants. What other ideas do you have besides an RFC? ~
Kvng (
talk)
04:14, 19 December 2023 (UTC)reply
What we normally do on Wikipedia is find common ground and then edit the article accordingly, which is much more productive than endlessly talking around things. To that effect I've made the two requested changes that there is consensus on (bolding BE and LE in the lead, and re-adding a diagram). Now, will you discuss your remaining concerns?
Chris Cunningham (user:thumperward) (
talk)
15:35, 19 December 2023 (UTC)reply
Done, but only on the understanding that this is a matter of diplomacy. That this article is chock-full of unsourced, tangential distractions which are not actually key to the subject matter is still a core concern, and I expect that whole section to be substantially edited in future.
Chris Cunningham (user:thumperward) (
talk)
00:34, 20 December 2023 (UTC)reply
Thanks and sorry for the delay. Let's try point #3 again. I say text and tables/diagrams together are good to support different comprehension styles and provide visual anchors for readers. You say only text is required and tables/diagrams create and
WP:ACCESSIBILITY issue. Am I missing anything?
What specifically is the accessibility issue you're concerned about? I have reviewed
WP:ACCESSIBILITY and see some concerns about large tables, font size, coloring; I don't see that any of that applies here. There is
WP:DTAB which explains how to make tables accessible. I believe the tables you removed already follow that and if not, we should be able to correct them without removing them. ~
Kvng (
talk)
16:37, 23 December 2023 (UTC)reply
I'm pretty sure that's referring to layout hacks like using a table with invisible cell boundaries to adjust text position. ~
Kvng (
talk)
12:58, 11 January 2024 (UTC)reply
Nothing in the wording of the guideline suggests this. In the absence of such qualifiers, the most obvious solution would be to follow what is actually written. There is no contradictory guideline suggesting that using ASCII markup for diagrams is acceptable.
Chris Cunningham (user:thumperward) (
talk)
23:21, 30 January 2024 (UTC)reply
The section you link to is titled Layout tables and starts with Avoid using tables for visual positioning of non-tabular content. I don't think you have much to stand on. As for your claim that we can't know what is intended, I think a discussion at
Wikipedia talk:Manual of Style/Accessibility would clarify things pretty quickly. ~
Kvng (
talk)
00:33, 31 January 2024 (UTC)reply
Then... start one?
MOS:LTAB only mentions data tables and layout tables (and has lots of strong wording discouraging the latter) for a reason: using tables to draw diagrams is not acceptable. See also the omission of this use in
MOS:TABLES. I'm entirely confident that "don't use tables for drawing squares" is the consensus already; the burden of proof there is for the person who has no more to go on than gainsaying.
Chris Cunningham (user:thumperward) (
talk)
15:33, 1 February 2024 (UTC)reply
Alright,
done. ETA: I'm away from computers for the next few days and may not be able to check in or respond to anything until next week. ~
Kvng (
talk)
15:59, 1 February 2024 (UTC)reply
That this has consensus is an egregious lie. This has worsened this article for the sake of an editor considering himself to have won a dispute. I've utterly no interest in cooporating with the furtherance of that petty little war, and will ensure that eventually this is rolled back.
Chris Cunningham (user:thumperward) (
talk)
23:34, 17 February 2024 (UTC)reply
Editors in the discussion have been willing to accept the version I presented with column and row headings. No one has expressed support for the original version without headings that was re-introduced.
isaacl (
talk)
00:17, 18 February 2024 (UTC)reply
@
Isaacl, A simple revert is not the intended final state but it is the place to start and I didn't see any objections when I proposed this approach. ~
Kvng (
talk)
01:15, 18 February 2024 (UTC)reply