Don't limit blocks table width #4199
Conversation
|
Personally I'm happy with this but as far as I can see there's no precedent for it so I'd like to hear what @gravitystorm thinks before I merge it given it is kind of breaking with the existing site design. |
|
There are pages that are more narrow: |
|
Yes, this would definitely break with the existing site design! I also think that it's not a good result, from a design point of view. Extra-wide content, even a table, becomes increasingly hard to read, so most designs have some kind of upper bound to the width. Usually the extra width on wide screens is used for additional columns, rather than making the central content column ever wider. My own screen is not particularly wide (1920px) but it becomes hard to e.g. look at both sides of the table, or move the mouse along one line to click the show button. There is also a strong argument that if something needs more than 960px for a single piece of content (e.g. a table with lots of columns) then it's going to need a more major redesign, in order to work on narrower screens too. Not everyone has extra-wide screens, particularly on mobile devices, so there needs to be some amount of responsive design to accommodate e.g. 960px wide screens anyway. I can see the desire behind having a wider layout than 960px, but that desire should be to pick a larger width, and otherwise behave the same way as now (i.e. 100% up to a breakpoint, then fixed width), rather than just being completely unlimited. Bootstrap has containers, which have similar breakpoints to our current custom css. We're using the equivalent width of It would be nice to ditch our custom css for layouts, and use bootstrap for this. It would take some experimentation though, since there's not a 1:1 mapping between our current behaviour and that of the bootstrap containers. We would need a class that says "up to the So in summary, I would decline this PR, and (if even necessary) approach this in a different manner. But I'm not yet convinced that any individual content panel should be over 960px anyway. |
|
Wide tables might be harder to read, but truncated content is impossible to read at all. Reason for block column can't have any meaningful amount of text in it. Now you see "Please contact OSM's Data W...", "Temporary account block - p..." or something like "Hello , ...", but you already can see the username in another column. I wanted to use https://getbootstrap.com/docs/5.1/helpers/text-truncation/ in this column. You can always make the browser window smaller, and get a narrower table. But you can't do the opposite thing. See also #1656 (comment)
Does this table need show buttons? You can have a link from Reason to the block page. Maybe the edit and revoke buttons can also be removed and/or placed on individual block pages. Maybe the username column can also be truncated.
Is it a statement about the existing design, which doesn't work well even with 960px in case there's a long username? What I want to add in #4200 doesn't require more space. Except for trying to make the Reason column to grow, but that is not included in #4200. What if column are reordered and Reason is the last column and it grows to full browser window width, revealing more text? Would you still say that truncating it is better? |
Sure, these are good ideas for this specific table.
No, it's not related to long user names. What I mean is that our site has to be responsive, i.e. work at every width of screen. So the contents need to be appropriate for 400px wide screens, 800px wide screens, 1200px wide screens etc. When you are looking at content on a page, you need to think "does this also work at medium and narrow screens". Now there are lots of ways to achieve this, e.g. removing columns (or hiding low-priority ones on narrow screens?) from a table, ensuring wrapping works, splitting content into different sections and laying them out differently (e.g. see the user dashboard page) - it's a case-by-case thing, depending on the content. And in most cases I suspect by the time you've optimised the content for medium and narrow screens, it'll work just fine on large screens and you probably don't care so much about super-wide screens at that point anyway. It's important to follow a "mobile-first" (or more accurately, a "narrow-screen first") approach. i.e. make it work on narrow screens, make it work on medium screens, make it work on large screens. In this case, if it's not working on a large screen, and you want to fix this by making it wider, I bet it's not working on medium screens either. Making the content wider therefore isn't the right solution, it's just a workaround. If, however, it works well on narrow, medium and large, but there's also a way to make it work even better on xl screens (by including more information, or showing things side-by-side, or whatever) then that could be a good reason to add more width. |
|
Example of https://antonkhorev.github.io/osm-note-viewer/ with mobile phone settings, with line breaks disabled to conserve vertical spacing:
I go even further here: the table is wider than the screen. Note that the comment column is the last one. If you are not interested in reading the entire comment, just don't scroll horizontally. But you have the opportunity to do it. If 100%-wide tables are not working just because of their width, this example is super not working. Of course I disagree with that. |
|
Thanks for the additional explanations and example website. However, I still don't think this PR is a good idea to merge, mostly for the reasons I described in my original comment. So I'm going to decline this proposed change. |
I'll just comment on the last one of those reasons:
The main page of this site is 100% width and no one even questions that. |
https://www.openstreetmap.org/user_blocks contains a lot of information. It's more technical than a usual page here. Therefore it doesn't have to be limited to 960px like the most of non-map pages.