I'm using a 4k screen at 160% DPI, so I've got a 2560px wide browser technically when full screen, and I was surprised to find your change works fine as all panels I use are fine with it, it's really just the tables and the lists widening up more. 👍 from me.

Status: reviewed

@jkufner this has been asked before in the past and rejected because long line lengths destroy readability:

You say:

Since the profiler is meant for practical usage rather than beauty

We do that precisely for practical usage rather than beauty.

@curry684 you have a 4K 2560px wide screen ... but GitHub doesn't care about that when rendering text. Why? Because they know that long line lengths destroy readability:

I'm really sorry if you disagree with this decision, but please keep in mind that this is not -> "we are right and you are wrong". This is a universal design principle followed everywhere (on the Internet and out of it). Thanks for understanding it.

If you argument with Github, please take a look at another screenshot:

The max-width makes sense only for paragraphs of plain text. Not for tables, lists of class names, nor diagrams — and these are the majority (if not the only thing) of what Profiler shows. Now I took another look at the Profiler, and I found no plain text longer than two lines.

However, to address the optimal width problem, I added 50em max-width to paragraphs (and possibly other elements; see the new commit 3580e6e in my branch), so if there is a longer text somewhere, it gets wrapped to the comfortable width. If you know about another too wide element, I'm happy to add it too. This approach will allow everything else to use as much space as it can, just like Github does.

@javiereguiluz I've been running a webdesign company for 12 years, I know more than well the golden rule for readable text is 66-76 characters per line. The reasoning for this is that it requires exponentially more effort to find the beginning of the next line the farther you extend beyond that reach. It is therefore an extremely important rule to follow for long text-based content blocks.

Following the above the golden rule specifically does not apply to:

• Tables, which explicitly become easier to read and parse as more space is given to individual columns.
• Single lines of systematic text, such as logs, which explicitly become more readable to a developer if you stretch them, because it allows for easier optical comparison, and scanning for anomalies. Nobody reads a log like they read a book. Every sysadmin makes his terminal as wide as possible when grepping through logfiles.

The Symfony Web Profiler is not a book. It's not a content site. It does not contain discussions like the one we're having here on Github. It's a collection of tables and logs. It does not follow any single other golden guideline for designing content sites. It's weird it tries to apply to the single rule it shouln't be bothering with.

I checked every single page of the profiler on 2560px, and each one was just as usable as before, or provided far better quick overview, like the events tabs.

Or the cache panel, which currently does this:

@jkufner you showed the only GitHub page which is wide ... and it's wide because it's comparing two things side-by-side. About this:

The max-width makes sense only for paragraphs of plain text. Not for tables, lists of class names, nor diagrams [...]

I'm sorry but it's not correct. The line length design principle is not only "for books" or for "text paragraphs". It's for any element that displays texts (e.g. a table cell). You can see it in action everywhere on GitHub. For example, on tables:

@curry684 I disagree with you too because of the reason explained above. For example, this is how GitHub code looks on a 2560px screen. Even if there's plenty of space for the code, GitHub simply overflows it because of the line length limit (it would be better to display a soft wrap as in editors, but overflow is OK too):

The main problem of the table that you showed is that the cache information displayed like that is useless. Are you seriously going to read the long garbage-looking green strings? If that info is important, we should make it human-friendly.

@javiereguiluz Can you show me a page in the Web Profiler which looks bad or is hard to read because it is too wide, please? I will add a CSS class to it (or to the too wide element) to make it narrow again, but we can have other things wide if the container is not limited.

For example, the Performance page has a big diagram which is hard to read because they are too narrow. SQL queries in the Doctrine page look wierd when lines are wrapped at wrong places. The routing table is also hard to scan when paths are wrapped.

Moreover, the last picture above (the diff) is another example where a wide page is much better. The horizontal scrollbars and plenty of space on sides is just wrong. The source code is well formatted, and there is no point in hiding the ends of the lines. In fact, it just makes it harder to read.

Are you seriously going to read the long garbage-looking green strings?

When there is a bug and I need to find it? Yes. When the lines are not wrapped, I can quickly scan over all of them and notice they look almost the same. However, when they are wrapped, such a scan is much harder and slower, because the wrapped ends are in the way. The same situation is with logs.

@javiereguiluz it's fine to disagree, and yes I vehemently do disagree with you in this case, but then please do not lock the discussion by closing the PR based on your personal opinion. Keeping it open invites more insights.

I added another commit (branch) which removes width: 100% from tables. This change lets the tables shrink to their natural width, so their rows are only as wide as necessary, but still, the table can use the whole screen if required until line wraps occur.

This change addresses concerns about the readability of long lines, especially when there is a short text in a left column and one or two numbers far at right. However, inconsistent table widths make some pages slightly ugly — most notably on the Security page. Some min-width trick could make it better, I guess.

The main problem of the table that you showed is that the cache information displayed like that is useless. Are you seriously going to read the long garbage-looking green strings? If that info is important, we should make it human-friendly.

Sorry, but again I disagree. I'm at heart a programmer and a system engineer, a devops engineer if you like. I've been programming for 34 years, and way back on the Commodore 64 and the Amiga 500 I already spent tons of time reading garbage-looking strings, and I still do these days on my Debian servers and my Ubuntu VM. It's what programmers do - parse system output, be that HTTP request logs, call stacks, mail logs or debug dumps. They're all garbage-looking strings, just not all green. And in each and every single case of them I've preferred the widest possible view because it allows for far easier anomaly scanning.

Just a random example of an actual sploit attack on one of our webservers, with the logfiles wrapped and not wrapped: https://gist.github.com/curry684/5e0c5784647d4bb9d1ae9adcb5b20f30. Tell me which one you prefer to see when your server load is 160 and you need to know NOW who is doing what to your server. And how many craps you give about typography at that moment.

@javiereguiluz I again would like to urge you to reopen this issue. It was extremely prematurely closed based on false arguments. It was thoroughly explained why they are false, there are a bunch of +1's from respected Symfony contributors and ecosystem on those explanations, and you were highlighted both here and on Slack requesting an opportunity for other opinions to chime in.

I'll happily accept that you missed them, I know you are overloaded with Symfony communication channels, but right now we're neither appearing thankful and welcoming to @jkufner 's first contribution, nor displaying a proper open community attitude where opinions are heard and weighed properly.

I'm closing this pull request in favor of #27678, which provides this (and more) as a configurable option to not impose anyone ideas on each other. Thanks!