Formatting on canned trac reports

[pbiron]

The canned trac reports (e.g., ​Next Major Release) seem to not be formatting correctly.

In particular, the h2.report-results, div.paging, table.listing.tickets go full page width, whereas everything above them in constrained to have max-width: 940px; margin-left: auto; margin-right: auto.

I don't remember those things being that wide in the past...maybe they have been.

However, even if those 3 selectors are added to the CSS rule on line 219 of ​https://s.w.org/style/trac/wp-trac.css?118, the table still blows beyond the 940px.

Even if the table is supposed to be full width, it actually breaks on mobile (see screenshots to be added shortly).

[pbiron]

this in Chrome's "mobile preview" in the inspector.

[SergeyBiryukov]

Even if the table is supposed to be full width, it actually breaks on mobile (see screenshots to be added shortly).

IIRC, the table is indeed supposed to be full width. We could try to improve the mobile styling though.

[tellyworth]

Even if we fix the styling, there's too much info on that page for it to ever really be mobile friendly. Is there anything we can do here that has enough benefit to be worth spending time on it?

[dd32]

Is there anything we can do here that has enough benefit to be worth spending time on it?

After a very quick look, I can't see anything obvious we can do here.

I don't think removing the mobile-width of the header/footer would be a wise move here either, as at least users can zoom to the left hand side to get a proper view, and then scroll for the rest.

I would suggest that this is probably a wontfix until we reskin (again) or more likely switch to a non-Trac system.

[SergeyBiryukov]

Related: #3118

[vladytimy]

There is a proposal here (3rd item) for responsive Trac reports:

https://meta.trac.wordpress.org/ticket/4917#comment:17

This is a 4 part patch that tries to bring better responsiveness for Trac reports.
Your feedback and testing would be much appreciated. Thank you!

[dd32]

This might be improved with [11610], but regardless, I'm going to close this as a duplicate of #4917