I get a horizontal scrollbar on this page. Can you upload a screenshot? (Use the button on the toolbar here.) What browser and operating system are you using?

hello,

both under Firefox and Edge Chromium OS Win10

I make an additional discovery at the same time Under Edge chromium in full screen mode, the horizontal scroll bar does not appear at the very end of the page. In contrast to firefox or it does not appear in the same situation. But for the 2 browsers in windowed mode, the scroll bar is displayed at the very end of the wikipedia page.

Oh, I see it now, the problem only occurs with the new Vector (which is enabled by default on fr.wp, I forgot that I disabled it).

Other examples are https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units and https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

Thanks @Akeosnhaoe.

It might be time to consider moving our responsive table handling in Minerva into core.

Other examples of "Featured Lists" from Enwiki that would perhaps benefit from having tables float-left(?) into the collapsed-sidebar's margin, include:

• https://en.wikipedia.org/wiki/List_of_current_monarchs_of_sovereign_states
• https://en.wikipedia.org/wiki/List_of_Knight%27s_Cross_of_the_Iron_Cross_with_Oak_Leaves_recipients_(1940%E2%80%931941)#Recipients_of_1941
• https://en.wikipedia.org/wiki/Member_states_of_the_Association_of_Southeast_Asian_Nations#ASEAN_member_states

Beyond the "Featured" quality lists, there are many examples in the "Comparison of" list type, e.g.

• https://en.wikipedia.org/wiki/Comparison_of_birth_control_methods#Effectiveness
• https://en.wikipedia.org/wiki/Comparative_army_enlisted_ranks_of_Asia
• https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
• https://en.wikipedia.org/wiki/Comparison_of_email_clients#Authentication_support
• https://en.wikipedia.org/wiki/Comparison_of_hub_gears

@alexhollender any thoughts on what we want to do with this one beyond adding horizontal scroll bars?

To clarify: @Scrameutache is the problem that you're not able to scroll the page sideways (i.e. horizontally), or that the horizontal/sideways scrollbars don't appear? My understanding is that your operating system controls the appearance of scrollbars. In all of the examples given I am able to scroll the page sideways and view all of the content of the tables:

In T267161#6974466, @Jdlrobson wrote:

@alexhollender any thoughts on what we want to do with this one beyond adding horizontal scroll bars?

I think ideally we would add a div that wraps the tables with a max-width and overflow-x: scroll. I've created a demo here: https://en.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox/table-demo

Additionally it would be great if we could add some kind of fade-out to the clipped edge of the table, e.g.

@alexhollender When I created the ticket, I could only scroll sideways on the page mentioned because this bar did not exist. This was the only page that could not move with the bar, I could scroll sideways by selecting the contents.

In T267161#6976765, @Scrameutache wrote:

@alexhollender at the time i created the ticket, i could only scroll sideways to the page mentioned. it was the only page that could not scroll

what is the current situation for you? Are you able to scroll both horizontally and vertically?

This page has been in order for some time and it is possible to scroll the page with the horizontal bar

@Jdlrobson as we've discussed in the past I'm not sure if this falls within the editor/template domain, or is something that we can address through MediaWiki platform. cc @ppelberg @Esanders

@alexhollender I would add to this demo that the titles and/or the first descriptive column of the table should be frozen in the vertical or horizontal scrolling, depending on the scrolling method, as it is possible with spreadsheets

In T267161#6977755, @Scrameutache wrote:

@alexhollender I would add to this demo that the titles and/or the first descriptive column of the table should be frozen in the vertical or horizontal scrolling, depending on the scrolling method, as it is possible with spreadsheets

That's a separate issue, but the main task for that is T42763: Implement repeated/fixed/floating/sticky table headers (and my search for it turned up a duplicate (T246587) and the related mobile-focused task (T166650)).
Personally, I use TheDJ's gadget (linked in that first task), and whilst it has a few quirks (e.g. on pages that have monstrous headers like https://en.wikipedia.org/wiki/Comparison_of_payment_systems ), and some erratic styling, it's generally really good.

In T267161#6976666, @alexhollender wrote:

I think ideally we would add a div that wraps the tables with a max-width and overflow-x: scroll.

I don't think that will work, because it means people cannot scroll a table sideways using a simple mouse, until they're looking at the very bottom of each table, and they would have to scroll separately for each table on any page.

Personally, I like the current New Vector styling of the table(s) expanding outside of the fixed-width, and the normal browser-scrollbar controlling it all.
My only wishlist improvement would be for the table to somehow float into the empty sidebar-area if there's enough room for it to do so (If and only if it's too big to fit on the page) so that tables which allllllmost fit within my browser-window size can do so automagically. E.g. This table just needs ~20 more pixels to fit!

Timeless does something similar to the 'wrapper' solution today (in Javascript). The original implementation was T179265: No scrollbars on mobile tables and T265785: Tableaux triables hors cadre / Sorting tables overflowing frame I think.

There are some issues with it that @Isarra has poked at, some closed and others not.

• T269912: New table scroll slight visual "tweaks"?
• T269913: Table scroll kills collapsing with mw-collapsible-content
  • Includes an appearance by TheDJ's sticky headers gadget
• T270050: Make overflowing table scrollbars sticky at bottom of screen

There was a fun suggestion about large tables on large screens she threw together for her own future work T269706: Pop large tables out of content column on desktop.

In T267161#6978373, @Quiddity wrote:

In T267161#6976666, @alexhollender wrote:

I think ideally we would add a div that wraps the tables with a max-width and overflow-x: scroll.

I don't think that will work, because it means people cannot scroll a table sideways using a simple mouse, until they're looking at the very bottom of each table, and they would have to scroll separately for each table on any page.

ah ha, great point about the mouse. One possible solution might be to limit the height of the table so it can never be taller than the viewport, then force the scrollbars to always show https://wide-tables.web.app:

This creates a sort of iframe feel. I think the main downside would be that the scrolling is more "manual", as in you can't scroll the table without putting your cursor over it.

just to log another possible idea here, we could try adding a "click to scroll" element to the entire clipped-edge of the table

@alexhollender I don't think there's anything that Editing or general template-behavior has to say about this. From our end we just wind up creating wikitext tables. The Parsing team could change the output generated from wikitext tables, but there's enough complex possible outputs from table markup that I'd be concerned about breaking edge cases or community templates.

Alternately, there's a social/community approach where we could make a new CSS class that could be added to tables, and encourage communities to deliberately add it to tables they know will be very wide.

It looks to me like the original problem in this task was already fixed.

In the screenshots I made in November 2020 (T267161#6604316), the horizontal scrollbar for the page was not visible until I scrolled to the bottom of the page:

Today, testing on the same page, this problem does not occur – the scrollbar is always visible when needed:
https://fr.wikipedia.org/w/index.php?title=Codes_OTAN_des_grades_des_sous-officiers_et_militaires_du_rang_des_armées_de_terre&useskinversion=2

In T267161#6985028, @matmarex wrote:

It looks to me like the original problem in this task was already fixed.

Agreed. The task is now more general, and is meant to be a discussion about possible improvements to wide tables.

Please note, the table must not have a maximum width or height even if it is included in a frame. the frame should automatically adapt to the content and to the browser window.

if the original problem was seen with a desktop browser. do not forget that if the frame has a defined size, you risk with your tablet or your telephone having a double scroll bar since the reading window is not the same.

@alexhollender I find those huge arrows kinda annoying, they reduce the visible space even further, and I think that restricting the width of a table on desktop is already a problematic concept (I mean when you have one of these huge tables that gets limited to 100em, with oceans of white to the side, it's just dumb).

These are screenshots from my 27" screen.

Where it does have to happen however (smaller size screens), I'm very much in favour of small shadows on the edges to indicate the there is MORE content, because especially on touch devices, the scrollbars are not visible until you drag the contents and that can be very undiscoverable.

I'me also still a fan of simply opening the table in the full viewport modal, so that you can scroll through it more easily without having to be bothered by the rest of the content on a page. A bit like opening up an google drive sheet on mobile.

Regarding fixed headers (with CSS).. This works best on Safari (targeting thead), and spotty in other browser. So if you can somehow make it specific to that browser (and even iOS completely, as chrome/firefox mobile embeds a safari view), that could work. The Chrome version of that is now implemented (finally) but awaits release of 'tables-ng' in Chrome and there is no plan on when to do that.

P.S. note that the second screenshot uses my floating headers gadget, which not only applies to thead, but also to tfoot

@TheDJ @alexhollender

why not apply auto-adjustment of the contents according to the size of the device?

note that for this page: https://en.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox/wide_tables, the horizontal scroll bar does not appear on my smartphone when it is in portrait and that the vertical bar is very thin. same for this thinness of the bars when my phone is in landscape

So the lack of scrollbars would be more of a problem when browsing on a non-touch pc.

The issue here is that unless you have a trackpad or a mouse with sideways scrolling abilities, you would only be able to scroll the table sideways from the bottom of the table (where the scrollbar is).

It's possibly worth noting that it's possible to scroll horizontally by holding Shift and scrolling with the scrollwheel, though obviously this only applies for desktop, isn't terribly accessible (requires two hands) or particularly discoverable (I only learned this myself some months ago when I read about it in a random comment somewhere else), and I have no idea how "standard" it is (it works for me in Firefox on Windows 10, but I haven't made any attempt to test it in other browsers/environments, and have no idea how long Firefox has supported it for).

@alexhollender do we have any actionable ideas here or should we put back in the backlog for more thought?

Perhaps moving the existing table handling code from Minerva into the Vector experience might be a start, but I don't know if that's enough here.

In T267161#7055502, @Jdlrobson wrote:

@alexhollender do we have any actionable ideas here or should we put back in the backlog for more thought?

Perhaps moving the existing table handling code from Minerva into the Vector experience might be a start, but I don't know if that's enough here.

@Jdlrobson I think we have some viable ideas. However I imagine implementation will be a substantial amount of work (i.e. might involve other teams, templates, the editing experience, etc.) so I don't think it's realistic for us to start on this now. Maybe it would make the most sense to add this to a backlog for now.

In T267161#7210607, @LGoto wrote:

This task was closed as part of backlog upkeep. If you believe it was closed in error, please respond on the ticket.

Procedural question: Do silent edits generate notifications to task subscribers and task author? If not, why was this backlog upkeep done with silent edits, making it significantly less likely that someone would react to it? And how many volunteer-created tasks were closed this way?

Procedural answer: No, they do not generate notifications (found declined tasks that I was subscribed to). I would like @LGoto to explain their actions, please.

In T267161#7210607, @LGoto wrote:

This task was closed as part of backlog upkeep. If you believe it was closed in error, please respond on the ticket.

Separately to stjn's question, how is what you did in keeping with the consensus at T248034: Decrease issues created many years ago with no recent activity (aka stale tickets) where we specifically agreed not to close tasks? CC @Aklapper

In T267161#7212762, @Aklapper wrote:

@Izno, open T248024 discusses a potential problem and some ideas and not a "consensus" that would imply a policy so I'm surprised to see it mentioned here. Teams, code stewards, maintainers need to be able to use Phabricator to plan what [not] to work on; that seems to be the case here.

Then I see this task as having value and will reopen according to the comment requesting feedback. I will assess all 58 task closes fairly. Does that sound agreeable? No?

Your reply should have "I'm sorry this got done silently, let me revert the changes and we can discuss the meta issue on the correct task", which has community opposition to anything that isn't "don't do that". I am fairly angry that wasn't the response.

I will assume that since you knew the meta task was open, you aren't the 1 of 6 people who approved the silent mass close. I am pretty sure it would be a tech spaces contribution policy violation otherwise.

In T267161#7212762, @Aklapper wrote:

@Izno, open T248024 discusses a potential problem and some ideas and not a "consensus" that would imply a policy so I'm surprised to see it mentioned here. Teams, code stewards, maintainers need to be able to use Phabricator to plan what [not] to work on; that seems to be the case here.

This is a task by a volunteer closed without an explanation (other than procedural) via a silent batch edit (leaving no way to notice this unless you happen to read it directly on Phab). It does not seem to be within what can be considered reasonable work planning. Usually, when the team plans their work on Phab, they do not close tasks unless they can provide reasoning for it, they simply remove stuff from their workboard. Also, T248034 is helpful to mention considering that there was no mention of doing silent batch edits for such actions there, even if they were considered consensual.

@Jdlrobson: will the other tasks be re-opened in batch? I did see some in a query made by AntiCompositeNumber that I am subscribed to (and still want them to be resolved with some type of action), hence why I ask.

If I may intrude a bit on this, it seems that this should be discussed separately.
There is no longer any connection with the original subject.

I agree that this topic should be closed unless there are elements on this initial topic, or related to it, that could advance the debate. but as it seems that the round of the question is done. should we continue the debate?