The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: rcrdortiz <rcrdortiz@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @rcrdortiz! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

Looks like you committed your personal .idea folder. You might want to consider gitexcluding that in your own global gitignore :)

Did you forget adding the fixes (the actual maxWidths...), I don't see it in the diff?

Did you forget adding the fixes (the actual maxWidths...), I don't see it in the diff?

It got deleted on my second commit, restored the actual fix.

Looks like you committed your personal .idea folder. You might want to consider gitexcluding that in your own global gitignore :)

Yup, thanks for the tip!

Let's add a dataviews CHANGELOG entry about this change. :)

If you check the "Templates" DataViews in the site editor, you'll notice the following:

• It has specific styles targeting .page-templates-description to apply something very similar to the generic fix being applied here. (this style should probably be removed)
• If you remove that specific style, the generic fix doesn't work properly all the time (see screenshot). I believe that's because there's not enough fields so the column is large anyway. I wonder if there's a better way to make this fix apply more generically (maybe by targeting the field wrappers rather than "td", at least for the "primary column" maybe if it's not possible for all fields)

What do you think ?

Here is a video with what the Table Layout looks like with the most recent changes:

maybe by targeting the field wrappers rather than "td",

I think this is worth a try. td doesn't respect min-width and max-width very accurately, which seems reasonably important if we want to optimise for legibility (50-75 chars per line including spaces). That's why we ended up with the template description approach.

I've just pushed some changes that remove the custom class and styles that the Templates DataView had. I still need to figure out what's making the Authors column that wide, but I think it's a step in the right direction. Here is a screenshot of the changes.

Okay, I've progressed more, but I'm trying to figure out what the best approach is now.

I can keep the nowrap for non-primary column cells. This approach looks best in most cases except when we have cells with really long text; in that case, the length of the cell will be the same as the length of the text. Here are some examples:

This here is the main issue with not wrapping text:

When we wrap text, large tables become somewhat easier to read, and are better suited (marginally) to the available screen's real estate without requiring scrolling as much, and we avoid having long cells. The problem is that wrapping kicks in soon once we have a few fields. Here are some examples:

I think I'm more inclined towards the nowrap approach, but we wouldn't be solving the main issue. If we have cells with large chunks of text, the table will look just as bad as it does now. I'm not sure if the changes I've made to the primary column are a good enough tradeoff.

What do you all think?

@rcrdortiz I noticed that the approach was not working properly for primary columns (templates example). The columns was still increasing width as the size of the screen increased. The issue was that max/min width don't work well on td, th. Instead I pushed an alternative approach where I applied the min/max widths to the divs within the cells instead. Let me know what you think.

Hey, there's some issue with the media field in this PR:

Trunk	This PR

Hey, there's some issue with the media field in this PR:

Trunk This PR

I'll have a look at @youknowriad changes and fix the issue.

Update: Fixed the issue by excluding the media part of the primary column from having a min-width.

IMHO, the max-width: 60ch doesn't look good in cases when there is a lot of space available. For example, the templates screen looks off:

90ch, on the other hand, makes the experience somewhat more pleasing:

I'll change the max-width from 60 to 90. @youknowriad @jameskoster, please let me know if you have any complaints about it.

I'll defer to @jameskoster about this, I've just used something that is closed to what we had before.

I'll defer to @jameskoster about this, I've just used something that is closed to what we had before.

Fair enough, feel free to merge the changes once we get confirmation from @jameskoster.

I agree the empty space isn't ideal at a glance, but when it comes to actually reading the text, the narrower version is more widely legible, and that is what we should optimise for imo. 50-75 characters per line is a rule of thumb though. WCAG guidelines are to avoid exceeding 80, so I'd be happy with 80 or below.