Trac needs more responsive styles

[sumitsingh]

Hi,

I have found desing the issue on Moto E4 plus in chrome browser in below mentioned link.

​https://core.trac.wordpress.org/ticket/48997

Thanks

[sumitsingh]

Bug screenshot

[sumitsingh]

Bug screenshot 2

[dd32]

Unfortunately Trac isn't designed for mobile usage and these are only two minor examples of where the styling breaks down.

Attachment Screenshot_20191217-232159.png​

I can't duplicate that on any mobile devices I have, but I can reproduce it on Chrome at screen resolutions <450px, unfortunately I can't find the CSS that's doing it.
Removing all instances of min-width: fixes it, but makes trac less usable on larger tablet resolutions. In this case, it's the presence of min-width that's breaking it, I can't explain why and I can't find any combination of styles that are colluding to make it happen.

Attachment Screenshot_20191218-091019.png

Reports in general aren't usable on mobile anyway.
The standard experience for reports is the header/intro being ~33% of the viewport due to the extra-wide ticket table below it.

IMHO this ticket is a wontfix unless anyone feels strong enough to redo quite a lot of CSS to make Trac usable on all mobile resolutions. The current experience of having to zoom on most pages is reasonably usable given the content being worked with. I'm marking this as needing a patch, and low priority due to the above.

[dd32]

#4967 was marked as a duplicate.

[MarcosAlexandre]

@dd32 I worked on a simple fix and got the result below:

Before:
​https://prnt.sc/tg3dmc

After:
​https://prnt.sc/tg3dde

I think this ticket should not be low priority, as it is related to accessibility. What do you think?

How can I send a patch with the fix?

In case someone wants to make the patch, the basic CSS I used is this:

@media (max-width:550px) {
	#ticket .ticket-star {
		font-size: 25px;
		width: 25px;
	}
	#ticket > h2 .trac-id {
		font-size: 100%;
	}
	#ticket table.properties > tbody > tr {
		border-bottom: none;
	}
	#ticket table.properties > tbody > tr > td {
		border-top: 1px dotted #eed;
		width: 42%;
		float: left;
	}
	#ticket table.properties > tbody > tr > th {
		border-top: 1px dotted #eed;
		width: 42%;
		float: left;
	}
	#ticket table.properties > tbody > tr > th#h_focuses {
		border-bottom: 1px dotted #eed;
	}
}

[vladytimy]

Replying to dd32:

IMHO this ticket is a wontfix unless anyone feels strong enough to redo quite a lot of CSS to make Trac usable on all mobile resolutions.

I partially agree for the Good First Bugs page - you don't go on that page from mobile. On the other hand, the single view of a ticket is more and more accessed from a mobile device - just wanting to check a ticket. So, IMHO, that needs a patch.

Explored solutions:

1. word-wrap: break-all; will result in ugly incomplete names & keywords
2. Creating 2 columns of properties + attributes instead of 4 is possible, but still looks crowdy on mobile and needs different HTML output, not only CSS rules.
3. Creating 1 column of properties + attributes looks elegant on mobile. (see 4917.patch)

@MarcosAlexandre I wasn't able to replicate your results with your proposed CSS snippet. If you have any suggestions about my proposed patch, please let me know.

Maybe step by step we'll make trac fully responsive, who knows!?

[vladytimy]

Patch for single ticket view - properties table

[vladytimy]

Before & After on a 360p width device

[vladytimy]

Before & After on a 549p width device

[vladytimy]

Before & After other examples on a 360p width device

[dd32]

Replying to vladytimy:

On the other hand, the single view of a ticket is more and more accessed from a mobile device - just wanting to check a ticket. So, IMHO, that needs a patch.

Agreed! The changes in 4917.patch​ seem straight forward enough, if it works like the screenshots here, that's a good step towards more usable Trac.

Explored solutions:

Thank you for explaining what you've tried! it makes it much easier to just trust the patch as-is without questioning the why's and how's of it, as long as the styles look reasonable on other sizes once applied I'll push it out today!

[vladytimy]

Replying to dd32:

as long as the styles look reasonable on other sizes once applied

4917.patch only addresses styles in @media (max-width: 360px) and @media (max-width: 550px).

There are 2 other styling issues on the single ticket view not introduced by this patch (see current design / screenshots):

• between 550px and 640px breakpoints both avatars float right (not ideal solution)
• between 640px and 770px breakpoints Reported by & Owned by: overlaps reporter's & owner's avatar (within this range, also the #modify .trac-properties table has styling issues)

Although IMO, these are less used sizes, since this ticket description is Trac needs more responsive styles I will propose an updated patch to address the above issues as well.

Thanks for making trac more responsive, even though most of the work here is not done on mobile.

[vladytimy]

Other current design issues on single ticket view (medium sizes screen)

[vladytimy]

Solutions for this comment:

between 550px and 640px breakpoints both avatars float right

Here I have a dilemma. CSS comment says: img.avatar {float: right; /* move it to the right to help prevent collisions */} but I can't reproduce any collisions without floating right even with longer names given that Reported by & Owned by are static length strings. (4917.2.patch removes floating - we either test it or let the floating right as it is currently)

between 640px and 770px breakpoints Reported by & Owned by: overlaps reporter's & owner's avatar

Explored solutions:

• Avatar floating right is not consistent with the design
• Changing margin-left from -60px to 0; moving rule from (max-width: 640px) to (max-width: 770px) (chosen approach)

between 640px and 770px breakpoints the #modify .trac-properties table has styling issues

Explored solutions:

• smaller width columns results in a crowded design and needs different HTML/selectors
• moving table rules from (max-width: 640px) to (max-width: 770px) creates one column, but intricates up Keywords and Focuses fields, making unclear what input is for what section. (see screenshot)
• reducing #focuses padding-right from 52px to 22px on this screen size - it aligns with above element. (chosen approach)

All these are small things, but make trac look better on medium screens.

[vladytimy]

A bad explored solution (see above comment)

[vladytimy]

4917.2.patch now addresses @media (max-width: 360px), @media (max-width: 550px), @media (max-width: 640px) and @media (max-width: 770px)

It definitely needs some testing. Thanks!

[dd32]

In 10678:

Trac: Improve the single ticket view on smaller screens.

Props vladytimy.
See #4917.

[dd32]

In 10679:

Trac: Bump styles cache after [10678].

See #4917.

[vladytimy]

Another mobile style breaking issue is when people (me included) use long attachments names or links.

.description and .summary already have word-break: break-word;
but .changes and .attachments don't.

Since we already use word-break (and not others such as: word-wrap or overflow-wrap), 4917.3.patch adds that rule to the above specified selectors. ( These rules don't need to be in a @media (max-width:550px) CSS block, since they take action only when needed on smaller screens. )

With this, we'll have a fully responsive (meaning "no major style issues") single view of a ticket, the most accessed template on here. Thanks, @dd32 for taking time to test and implement these small changes.

[dd32]

In 10705:

Trac: apply break-word to attachment names so that long filenames wrap on smaller screens.

Props vladytimy.
See #4917.

[vladytimy]

The next step with responsive styles on Trac would be responsive Report view, as requested in these tickets, other than this ticket:

• 3118
• 4554
• 3957 (the second screenshot)

As Dion said, Trac is not designed for mobile and many things can't be implemented by CSS styles only. My reasons for trying to implement responsive styles are:

• it doesn't affect those that use wider screens
• it gives a slightly better user experience for those (maybe a few) that use it on mobile
• it might increase Trac usage if it has a better mobile interface
• even if it's not perfect, it's better

The Reports patch for mobile devices is split in 4 smaller parts:

1. Overlapping report name with Max items per page
2. Styling report Filters (mobile)
3. Styling report Listing (mobile)
4. Better accessibility for report listing (mobile)

[vladytimy]

1. Fixes overlapping report name with Max items per page (4917.reports.1.patch)

• adds padding-top to #prefs
• no breaking point suggested, since the overlapping occurs for screens up to 900px (the patch doesn't break style for larger screens)

See before and after.

[vladytimy]

2. Styling report Filters (mobile) (4917.reports.2.patch)

• displays filters table as block
• corectly aligns labels
• increases size of labels
• adds padding between clauses
• breaking point: <640px ( wider screens can display current design )

See before and after.

[vladytimy]

3. Styling report Listing (Mobile) (4917.reports.3.patch)

• displays listing table as block
• keeps table header containing labels as a row
• adds label before every item listed
• .id and .ticket have the same label, because... Trac
• .date has Date label - see below why
• labels are bold, except Comments and Stars (not vital info)
• label Stars is, because not-logged users don't see the star icon
• Comments and Stars fields, in most cases, don't have their own row (space efficiency): they float right on the same row as the field they come before. (depends on the report field order)
• breaking point: 770px - see below why

Reasons

• Choosing a breaking point for reports mobile styling.

Different reports need different breaking points based on the number of fields in the default query. Not wanting to affect smaller desktop sizes (extreme example: meta/report/5 needs a breaking point at 1550px - mobile style at that width is a no), the breaking point that works for most reports is 770px. It is small enough not to affect any desktop views.

• Date label

The labels are inserted via CSS. eg: .summary::before { content: "Summary: ";}
The problem occurs with .date class that is used both for Modified and Created fields because... Trac.

Core: 42 reports use Modified field only, 1 uses Created field only and 2 use them both
Meta: _5 reports use Modified field only, 9 uses Created field only and 0 use them both

Also, it's not possible to determine, based on the field order only, if the output should be Created or Modified since there are 17 combination of the fields used in the core reports and 14 combinations used for the meta reports. ​see this sheet pulled from Trac

Conclusion: I suggest using a generic field for both of them: Date.
It may make some wonder: Created date or modified date? (the answer: the type of date specified in the report table header) but it doesn't misinform by displaying wrong label.

See before and after ( the after includes 4917.reports.4.patch )

Note: the patch is a development of this proposed CSS snippet

[vladytimy]

4. Better accessibility for report listing (mobile) ( 4917.reports.4.patch )

• in order to have more contrast and better see when a ticket ends/starts, this sets border color ( for .prio[3-6] and .color[3-6] ) to the same color of the text (in most cases).
• to be easier to read, this increase tickets attributes font size
• breaking point - same as 4917.reports.3.patch: 770px

See examples of various priorities.

[vladytimy]

reports 1,2,3,4 patches in one go for testing purposes

[vladytimy]

Reports 1,2,3,4 patches in one go for testing purposes

[vladytimy]

Ignore the above attachment - it's a duplicate.
TIA for testing these patches.