Bug 219997 - Web Inspector: Font Details sidebar - Improve line wrapping of table row titles when space is available
Summary: Web Inspector: Font Details sidebar - Improve line wrapping of table row titl...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Patrick Angle
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-12-17 14:54 PST by Patrick Angle
Modified: 2021-01-15 12:22 PST (History)
5 users (show)

See Also:


Attachments
Screenshot of Issue (2.48 MB, image/png)
2020-12-17 14:54 PST, Patrick Angle
no flags Details
Patch v1.0 (2.12 KB, patch)
2021-01-15 08:56 PST, Patrick Angle
no flags Details | Formatted Diff | Diff
Screenshot of Patch 1.0 (1.92 MB, image/png)
2021-01-15 08:57 PST, Patrick Angle
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Angle 2020-12-17 14:54:18 PST
Created attachment 416473 [details]
Screenshot of Issue

As seen in the screenshot, some table row titles are wrapping before they need to despite horizontal space being available in every row. This makes the interface look less polished than it should.
Comment 1 Radar WebKit Bug Importer 2020-12-17 14:54:48 PST
<rdar://problem/72442294>
Comment 2 Patrick Angle 2021-01-08 12:02:05 PST
Someone correct me if I'm wrong, but there is no way for us to match the title column widths between sections currently? It appears we fix the title column to be 85px wide in `DetailsSection.css` It looks like each section is its own pseudo-table. Subgrid would be a long-term solution to this (but isn't done yet), but in the interim I'd like to make an adjustment (for the Font details sidebar only) to provide enough width for the the two longest common titles `Historical Forms` and `Optical Size (opsz)`. Historical Forms is always visible and Optical Size is the only registered variation axis that doesn't have a CSS property.
Comment 3 Patrick Angle 2021-01-15 08:56:05 PST
Created attachment 417705 [details]
Patch v1.0
Comment 4 Patrick Angle 2021-01-15 08:57:50 PST
Created attachment 417706 [details]
Screenshot of Patch 1.0
Comment 5 Devin Rousso 2021-01-15 10:10:14 PST
Comment on attachment 417705 [details]
Patch v1.0

r=me

(In reply to Patrick Angle from comment #2)
> Someone correct me if I'm wrong, but there is no way for us to match the title column widths between sections currently? It appears we fix the title column to be 85px wide in `DetailsSection.css`
Yeah we fix the label column to a certain width so that if we have long labels they don't take up more space than we have (`<table>` can be really tricky to work with when trying to do variable/dynamic sizing and have things within cells wrap).

> It looks like each section is its own pseudo-table. Subgrid would be a long-term solution to this (but isn't done yet),
Possibly, yeah.  As I mention above, the big quandary here is that we have a limited amount of space (the width of the sidebar) and want to avoid wrapping as much as possible (on both the label and the value) while also making sure that all the "cells" are horizontally aligned.  We may want to do things on a case-by-case basis (perhaps with grid too) like what you're doing here.

> but in the interim I'd like to make an adjustment (for the Font details sidebar only) to provide enough width for the the two longest common titles `Historical Forms` and `Optical Size (opsz)`. Historical Forms is always visible and Optical Size is the only registered variation axis that doesn't have a CSS property.
The big problem with this is that it's only true for English (and at default 100% zoom/font).  We've ran into many issues in the past (especially when dealing with fixed width non-wrapping text) where something is perfectly sized in English but overflows or "..."s in other languages.  As a result, we typically try to avoid situations where we have both a fixed width and disallow wrapping (I know that that's not the case with this, but just FYI).  And IMO it's better to have content look slightly more squished than to have way too much empty space.  I think Ideally we'd want something like "if this long string is shown and it's still long in the current language then expand the width" (but even this has issues where if the developer changes nodes and the font on the new node doesn't have this long string then the entire left column would suddenly jump).
Comment 6 EWS 2021-01-15 12:22:46 PST
Committed r271528: <https://trac.webkit.org/changeset/271528>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 417705 [details].