Help talk:Table/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Line breaks

Note. The first post in this thread was moved from a talk page to here.

Yo, I noticed you just changed two <br /> to <br> at Help:Table. I'm curious as to your reasoning as H:BR seems to indicate that the version with the space and slash is preferred: "While valid forms without the / (such as <br> or <br >) will work properly in the rendered page because modern browsers are forgiving of malformed HTML, they can break several of the available syntax highlighters for wiki code in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided."

I know use of <br> is very common. Anderjef (talk) 16:07, 4 February 2023 (UTC)

Anderjef. Help:Line-break handling is not a Wikipedia guideline or policy.

Please see Help talk:Line-break handling#Let us ignore syntax highlighters that do not accept <br>

Most people in that thread want <br> used. It is a detailed discussion in that thread. With participation from editors, developers, admins, etc.. --Timeshifter (talk) 00:13, 5 February 2023 (UTC)

I believe that the reason for <br /> is XHTML, and that HTML5 has displaced it in the browser world. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:26, 5 February 2023 (UTC)

See also Wikipedia talk:Line breaks usage and the section titled: <br> vs <br />

David Göthberg's reply in that 2006-2008 thread explains things well. He is a programmer. --Timeshifter (talk) 15:29, 9 February 2023 (UTC)

Both forms (HTML and XHTML) are valid Wikitext and I haven't read anywhere that one version must be used. The output to the browser is <br /> even if <br> is published, which is visible through curl or view page source (not inspect). If a gadget doesn't support both, then the gadget should be fixed to support what the MediaWiki software supports. I agree with David Göthberg's points, but its up to the editor to choose which version they wish to remember and use or they can just click the "New line" button. Jroberson108 (talk) 17:41, 9 February 2023 (UTC)

People can use what they want, but it is also OK for other users to change it to the simpler form. Especially on help pages where the KISS principle should operate. Another thing to note is that the space in <br /> allows it to split in half and to wrap in wikitext editing windows. Try it now and see by downsizing your browser window and dragging it wider or narrower until you see it wrap like that. That is bizarre to editors new and old. Please don't use <br />.

David Göthberg noted in 2008: "Also up until recently all documentation listed <br> as the code for forced line breaks. But some months ago some XHTML enthusiasts went around and edited a lot of the help pages to show the <br /> or even the <br/>." --Timeshifter (talk) 20:59, 9 February 2023 (UTC)

I will point out that MOS#Retaining existing styles suggests the existing style be left (even when the MoS supplies "no specific guidance"). That being said, one of Wikipedia's five pillars is Wikipedia has no firm rules, and I tend to find myself leaning toward your position @Timeshifter. Anderjef (talk) 21:48, 9 February 2023 (UTC)

I am only hard core on help pages. :)

Where "there is some substantial reason for the change." --Timeshifter (talk) 21:58, 9 February 2023 (UTC)

I'll add a few more points. Something added in 2008 (15 years ago) isn't a valid argument against it, but actually gives weight for continued support. The point about <br /> wrapping is a none issue since editors that do edit in code/source view expect code/markup to wrap, which plenty does (ex. citations) and we know to look for the ending similar to punctuation that ends a sentence. As for my preference, I'm OK with using either one and won't change the code to suite a personal preference that doesn't even affect the displayed content. If the goal is to reduce options and things editors have to remember (KISS), then I would recommend only allowing <br> and disallowing <br />, which the "New line" button inserts the former even though the latter is outputted to the browser. That would require a vote from the community. In a similar manner of sticking with KISS, I would also recommend requiring double quotes for arguments that only have one value like class="wikitable", which again is what the "Table" button inserts and double quotes are always outputed to the browser even when missing or single quotes are used. This would mean less to remember in regards to when quotes are optional and when they are required. As a programmer, I would think this cleanup of coding standards would have been implemented as the "Publish changes" button is clicked, but the MediaWiki software does it during render and not during save. Wikipedia doesn't follow strict coding standards and probably won't change so many standards are supported. Jroberson108 (talk) 04:32, 10 February 2023 (UTC)

I would recommend getting a vote from the community on a recommended style of code that mimics what the editing software inserts verbatim, which should represent the majority of the use cases and help to stick to an already accepted standard. Also, recommend standards that would lessen what editors would have to remember even if it isn't handled by the editing software. It's obvious that the software inserts spaces for readability, so continue with that recommendation. An editor would have to go out of their way just to change what is inserted by the software. Example:

• <br> is recommended. Using an XHTML tag (ex. <br />) is acceptable.
• == Header text == is recommended. Omitting spaces around the markup (ex. ==Header text==) is acceptable.
• {{cite |title= |last= |first=}} is recommended. Omitting spaces around parameters (ex. {{cite|title=|last=|first=}}) is acceptable.
• class="wikitable" is recommended. Omitting the quotes (ex. class=wikitable) is acceptable except when there are multiple classes, which requires the use of spaces and quotes.
• style="text-align: center;" is recommended. Omitting the space, quotes, and semicolon (ex. style=text-align:center) is acceptable except when there are multiple styles, which requires the use of semicolons and quotes. A space after semicolons (except the last style) and colons is recommended for consistency and readability sakes.

Jroberson108 (talk) 07:05, 10 February 2023 (UTC)

The 2008 argument is not the only one. See the long recent thread:

• Help talk:Line-break handling#Let us ignore syntax highlighters that do not accept <br>

Consider that as our more recent RFC. It got many replies. There is no MOS guideline that says we should be using <br />. I don't think there is any official policy or guideline page that says that.

I especially like this example from David Göthberg in 2008:

Well, let's first ask another question: Which markup should we use for bold text? '''Bold''' <b>Bold</b> <span style="font-weight:bold;">Bold</span> I think we all know that the wikimarkup '''Bold''' is the recommended one. Mainly because it is simpler to use, especially for the majority of editors that don't know HTML and CSS.

In my opinion anything but the standard Mediawiki method '''Bold''' is ridiculous, and I change to it anywhere I see the other versions. I don't want other editors, especially new editors, to start using the other methods. Or thinking that they need to remember such arcane unnecessary coding. That discourages new editors. Wikipedia is successful precisely because it is much simpler than other page editing methods on the web. --Timeshifter (talk) 17:41, 10 February 2023 (UTC)

I've already read that discussion since it was posted on your first reply, which is why I made the comment on fixing the gadget if it doesn't support the same formats that the MediaWiki software supports. Three single quotes for bold (ex. '''Bold text''') is what the MediaWiki editor inserts, so it too should be the recommended format with downgraded allowances for other formats. As David Göthberg mentioned, "we all know [this bold format] is the recommended one", but if you read MOS:BOLD you will see that no one format is recommended. I still recommend what I said in my previous reply on getting consensus to set what the MediaWiki editor inserts as the recommended formats on the help pages so things are more consistent. Make it official. Jroberson108 (talk) 18:43, 10 February 2023 (UTC)

MOS:MARKUP regards wikitext over HTML. Anderjef (talk) 20:20, 10 February 2023 (UTC)

MediaWiki editors change depending on what the developers do. And the developers often put stuff out without consensus of editors as a whole. There are huge fights over this. I use 2010 legacy Vector. It does not have a new line button in the wikitext edit window.

And MOS:MARKUP is official: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly."

MOS:BOLD does not recommend using the arcane bold coding alternatives mentioned by David Göthberg. Its only other bolding options besides '''...''' are <strong>...</strong>, or the template {{strong}}. I don't replace those. --Timeshifter (talk) 23:41, 10 February 2023 (UTC)

Again, no one format is recommended on the bold, newline, and probably many other help pages I mentioned in my examples. If you want more consistancy, then take the next step so it becomes clear on those help pages which one format is preferred and recommended. If not, then it's meaningless to discuss here on a talk page that hardly anyone follows. I'm done repeating myself and discussing unless you want to move forward. Jroberson108 (talk) 04:12, 11 February 2023 (UTC)

The problem with help pages is that like Help:Table they are not Wikipedia policies or guidelines. For example: Help:Line-break handling. The majority of people at the recent discussion there want that <br /> is no longer recommended there. But the regular editors there have yet to change that. I may be bold and do it, but prefer to wait a bit while these other discussions go on here and elsewhere.

I think that MOS:MARKUP is pretty clear. Also, I am less concerned with consistency, and more concerned with simplicity. For example; quotes are not needed except mainly when there are spaces. Once one learns that then it is far simpler to add the simpler version without the quotes. I edit a lot of tables, and find that to be true. But I don't want to force my version of simplicity on others for such a minor thing. If using quotes in all cases is easier for some people then let them continue to do so until they understand the point about spaces. I used to put quotes on everything. --Timeshifter (talk) 07:57, 11 February 2023 (UTC)

Scrolling tables and sticky headers.

Could someone please write basic instructions here on how to make certain rows or columns sticky in scrolling tables? The section currently only refers to articles which have them (but don't actually have horizontally scrolling tables with sticky headers contrary to the claim) and series of discussions which are Chinese to someone who does not have a degree in IT.Tvx1 17:16, 3 April 2023 (UTC)

The problem really is twofold. Firstly, scroll markup is part of the CSS language and not part of Wikitext or any Wikipedia extension. CSS in turn comes under the world wide web HTML5 umbrella. Before you can have a clue what is going on in say Template:COVID-19_pandemic_data/styles2.css you will need a good understanding of CSS and its scrolling model. Secondly, they tend to get tangled up in complicated dicing-and-slicing of pages into transcluded fragments by our editors. The guidelines at MOS:SCROLL appear to be well out of date and of doubtful help. This help page's mantra that nested tables cause accessibility problems is also about 20 years out of date; modern readers cope just fine and floating divs which break normal flow are a far worse nightmare. Any sane edits to the help would almost certainly draw down the angry priests of the last millennium and no consensus for change could be established. The way ahead would be to put together a viable modern solution, test it out on some real-world users of accessibility aids, get feedback from the same users on how crap the squalid old mantras are, and then seek a revised, evidence-based consensus on what to say here. Learning CSS for yourself is probably the less arduous road. — Cheers, Steelpillow (Talk) 18:08, 3 April 2023 (UTC)

Graham87 is an admin, is blind, and uses a screen reader. He said divs work fine for allowing multiple tables, etc. to wrap, and still be accessible. See diff.

See: Help:Table#Side by side tables.

See: Help:Table#Side by side tables and images.

I am all for getting more feedback from more people using screen readers.

About nested tables and accessibility:

https://www.google.com/search?q=nested+tables+and+accessibility

It seems nested tables are not accessible for the most part. I see some search results about how to make them accessible. --Timeshifter (talk) 19:52, 3 April 2023 (UTC)

First, I followed through one of your examples and the layout was just badly designed (nested header cells); using rowspan instead would have rendered the reader's audio output equally baffling. Design a complex table sensibly and both methods of implementation will yield sensible results. Second, don't forget that many web page creators still use headerless tables for page layout, because the code is often far easier to stabilise across disparate rendering devices than the equivalent div styling; I checked nested-table test code with one user and their reader did not even bother to inform them that a table structure was present. On the other hand an alternative implementation with divs and CSS that broke normal flow was rendered unintelligible. The important thing is not which markup you use but how you use it to produce a clean semantic flow in the page code. This is what really helps screen readers to present it intelligibly. For what it's worth, the "nested tables bad" mantra arose back in the last millennium, with early versions of like Microsoft FrontPage and Macromedia (as it then was) Dreamweaver. These tools used nested tables ad nauseam for page layout; they would even dice-and-slice an image and fit the pieces in the table cells! The mantra rightly had to be dinned into the programming community - the authoring tool creators, but wrongly broadened its aim to include the tool users - the page designers and content creators. It was then cemented in place by ignorant repetition and bad examples such as the ones you gave. Now it is carved in stone and you read it on the Internet, so it must be right. Oh, brother! — Cheers, Steelpillow (Talk) 04:45, 4 April 2023 (UTC)

Most of what you discussed is way beyond my skill level. I was only pointing to some very specific Wikipedia problems concerning wrapping of tables and/or images. Those are the sections I linked to, and helped edit, after Graham87 commented on the problem.

I did not write the nested tables sections of Help:Table. And Help:Table is for Wikipedia editors and Wikipedia pages, not other websites, nor for web page design. Wikipedia's design is done by the developers. Feel free to edit the nested table sections. I never use nested tables on Wikipedia. If you know of ways to use them, and have them be accessible to modern screen readers, then please edit that section. --Timeshifter (talk) 05:31, 4 April 2023 (UTC)

OK, I have had a go at it. Will be interesting to see if it sticks. — Cheers, Steelpillow (Talk) 06:51, 4 April 2023 (UTC)

Are you really sure it requires CSS? I found this discussion in this talk page’s archives, which does include an example of simple wiki markup to make headers sticky.Tvx1 00:44, 4 April 2023 (UTC)

The point is that the "wikitext" you refer to includes fragments of HTML+CSS, such as style="position:-webkit-sticky; position:sticky; top:-1px; left:-1px; z-index:1;" embedded in the markup. So yes, I am very sure that you need to understand what this CSS is doing if you want to use it effectively and/or debug your display. — Cheers, Steelpillow (Talk) 04:45, 4 April 2023 (UTC)

Tracked in Phabricator
Task T42763

Tvx1. That talk archive section you link to has this Phabricator task (look to the right):

It looks like they haven't solved the problem, and made a simple solution yet.

I updated and clarified the scrolling tables section of Help:Table. --Timeshifter (talk) 06:28, 4 April 2023 (UTC)

Data table under Economy of India is not updated

Hello,

The recently revised GDP data (released on 28th February) is not reflected in the table for the column GDP (real). you may want to change that. Else, I can do it if you can hep me understand how to edit the table.

Thanks, Kunalkumarkundu (talk) 08:19, 8 April 2023 (UTC)

Kunalkumarkundu. Welcome. I see that your post here is your first post on English Wikipedia with a user name.

Economy of India. Where exactly are you talking about? What section of the article? --Timeshifter (talk) 08:56, 8 April 2023 (UTC)

Rowspan making row disappear

I'm trying to merge two cells in the table at The Eras Tour#Venue records using the rowspan attribute but it's making the entire row disappear. The attribute works fine elsewhere in the same table. I've uploaded some images to Imgur to illustrate the problem. Can anyone help? Thanks. Shuipzv3 (talk) 13:36, 29 June 2023 (UTC)

@Shuipzv3: Looks like GustavoCza already fixed it? Issue may have been the "rowspan" on the preceding date cell. Jroberson108 (talk) 21:35, 29 June 2023 (UTC)

@Shuipzv3: Assuming that the portion in question is this

List of venue-based achievements, showing year, dates, venue, country and description

Year	Dates	Venue	Country	Description	Ref.
2024	February 16–18	Melbourne Cricket Ground	Australia	Biggest virtual queue in Australian history, with four million customers.
	February 23–26	Accor Stadium
				First act in history to schedule four shows on a single tour.
	March 2–4 and 7–9	Singapore National Stadium	Singapore	First solo act in history to schedule three, four, five, and six shows on a single tour.

the row hasn't disappeared, its vertical height has been reduced to the minimum necessary to display the cell contents. If you artificially constrain the width of the Description column to a smaller value, the cells will wrap and then the presence of that row becomes clear:

List of venue-based achievements, showing year, dates, venue, country and description

Year	Dates	Venue	Country	Description	Ref.
2024	February 16–18	Melbourne Cricket Ground	Australia	Biggest virtual queue in Australian history, with four million customers.
	February 23–26	Accor Stadium
				First act in history to schedule four shows on a single tour.
	March 2–4 and 7–9	Singapore National Stadium	Singapore	First solo act in history to schedule three, four, five, and six shows on a single tour.

Basically, browsers don't make a row any taller than it needs to be to hold its contents. --Redrose64 🌹 (talk) 22:10, 29 June 2023 (UTC)

@Redrose64: Thanks for your help. Shuipzv3 (talk) 00:36, 30 June 2023 (UTC)

@Redrose64: So the issue is that a number of cells with multiple rowspans is not appearing correctly, e.g. "Biggest virtual queue", "February 23–26", "Accor Stadium"; "Australia" should be 3 rowspans instead of 2 and "2024" should be 4 rowspans instead of 3. In other words, there should be a row that goes: "2024, February 23-26, Accor Stadium, Australia, Biggest virtual queue..." Because the vertical height has been reduced, this row is not appearing at all. It looks like "Biggest virtual queue..." only applies to Melbourne Cricket Ground only instead of that and Accor Stadium. Is changing the description the only way of forcing this to appear? Shuipzv3 (talk) 00:56, 30 June 2023 (UTC)