Page MenuHomePhabricator

Specific page on fr.wp shows oversized table without horizontal scroll bar in new Vector skin
Closed, ResolvedPublic

Description

Description

Currently wide tables (sort of) break the layout of the page. People are able to scroll the page horizontally to see the content, but it's a little bit awkward. Ideally we would wrap tables in some kind of container div and allow them to scroll in a more "neat" way.

current experience (link to page)
2021-04-06 11.05.23.gif (605×1 px, 3 MB)

Ideas

The first idea (which has been ruled out) was to add a div that wraps the tables with a max-width, overflow-x: auto, and some kind of :after element to render a fade-out (so that it's more obvious that additional content is clipped). 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).
Link: https://en.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox/wide_tables

2021-04-06 13.55.50.gif (636×1 px, 2 MB)

The second idea is to wrap the table in a div that has a max-height of ~94vh (or something similar) and force scrollbars to show. This way the horizontal scrollbar for the table is always visible. The issue this causes however is that the table has its own scrolling, such that in order to scroll it vertically you need to place your cursor over it. Unclear how big of a usability issue this would be.
Link: https://wide-tables.web.app:

2021-04-08 13.08.40.gif (816×1 px, 667 KB)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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?

image.png (2×3 px, 830 KB)

image.png (2×3 px, 868 KB)

hello,

wiki.JPG (357×1 px, 56 KB)

wiki 2.JPG (388×806 px, 47 KB)

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).

image.png (2×3 px, 771 KB)

image.png (2×3 px, 633 KB)

Aklapper renamed this task from https://fr.wikipedia.org/w/index.php?title=Codes_OTAN_des_grades_des_sous-officiers_et_militaires_du_rang_des_arm%C3%A9es_de_terre to Specific page on fr.wp shows oversized table without horizontal scroll bar in new Vector skin.Nov 5 2020, 11:15 AM
Aklapper updated the task description. (Show Details)

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.

@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:

2021-04-06 11.05.23.gif (605×1 px, 3 MB)
2021-04-06 11.06.43.gif (615×1 px, 2 MB)

@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

2021-04-06 11.47.48.gif (603×1 px, 1 MB)

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

Screen Shot 2021-04-06 at 11.43.52 AM.png (660×1 px, 145 KB)

@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.

@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

alexhollender_WMF renamed this task from Specific page on fr.wp shows oversized table without horizontal scroll bar in new Vector skin to Improvements to wide tables in new Vector.Apr 6 2021, 4:12 PM
alexhollender_WMF updated the task description. (Show Details)
alexhollender_WMF added a subscriber: ovasileva.
alexhollender_WMF added subscribers: ppelberg, Esanders.

@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

@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 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!

image.png (442×1 px, 99 KB)

But I cannot think of any way to do so, beyond removing the sidebar margin entirely for all body content.

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.

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#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:

2021-04-08 13.08.40.gif (816×1 px, 667 KB)

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

image.png (636×1 px, 199 KB)

@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:

image.png (2×3 px, 771 KB)
image.png (2×3 px, 633 KB)

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

image.png (2×3 px, 759 KB)
image.png (2×3 px, 652 KB)

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.

Screenshot 2021-04-12 at 11.15.21.png (896×1 px, 259 KB)

Screenshot 2021-04-12 at 11.16.17.png (895×1 px, 420 KB)

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.

@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.

LGoto added a subscriber: LGoto.

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

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.

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

@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.

@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.

@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.

Sorry for the confusion here @stjn @Izno . Several tasks were closed silently to avoid spamming certain users with notifications. An email to wikitech-l is planned for transparency but regretfully we haven't had time to coordinate/send this email due to the team member being out of office. That's definitely a lesson learned.

Myself and several others manually reviewed tasks in our backlog (mostly created by WMF staff) and closed out several old ones that no longer seemed valid or were not actionable by the team. This particular task is clearly a bug but this team doesn't have the capacity to address it so can be moved to tracking and left open.

@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?

matmarex claimed this task.

This issue has actually been resolved since before April 2021, as I noted in T267161#6985028, and should have been closed then.

At the time the Reading team asked to keep it open to discuss other improvements, but according to T267161#7210607 they're no longer interested.

Therefore I am closing it again (and restoring the older task title, which better reflects what was actually worked on).

matmarex renamed this task from Improvements to wide tables in new Vector to Specific page on fr.wp shows oversized table without horizontal scroll bar in new Vector skin.Aug 30 2021, 10:25 PM