[wp-meta] [Making WordPress.org] #4917: Trac needs more responsive styles

[Making WordPress.org]

#4917: Trac needs more responsive styles
-------------------------------------------------+-------------------------
 Reporter:  sumitsingh                           |       Owner:  (none)
     Type:  defect                               |      Status:  new
 Priority:  normal                               |   Milestone:
Component:  Trac                                 |  Resolution:
 Keywords:  needs-design-feedback has-patch      |
  has-screenshots                                |
-------------------------------------------------+-------------------------

Comment (by vladytimy):

 3. **Styling report Listing (Mobile)**
 ([https://meta.trac.wordpress.org/attachment/ticket/4917/4917.reports.3.patch
 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: [https://meta.trac.wordpress.org/report/5 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. [https://docs.google.com/spreadsheets/d
 /1EciVtvu_CFlN76hiTlgLjcG0V_-Zmbw7M0fTw-hdcpE/edit?usp=sharing 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
 [https://meta.trac.wordpress.org/attachment/ticket/4917/4917.reports.3_bef_after.jpg
 before and after] ''( the after includes
 [https://meta.trac.wordpress.org/attachment/ticket/4917/4917.reports.4.patch
 4917.reports.4.patch] )''

 Note: the patch is a development of
 [https://meta.trac.wordpress.org/ticket/3118#comment:5 this proposed CSS
 snippet]

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/4917#comment:20>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org